All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 33 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Chip Off jobs on encrypted Android Phones
PostPosted: May 11th, 2018, 8:18 
Offline

Joined: May 28th, 2016, 9:16
Posts: 127
Location: Karlsruhe / Germany
Hey Guys,

can some one tell me, if there is a list with Android phones, that are encrypted by default?
And how does the encryption of the device work? Afaik the Android devices doesn't have something like the "Secure Enclave" of iPhones, so the key must be some where. Or is there no way to get the data, if the device is encrypted?


Top
 Profile  
 
 Post subject: Re: Chip Off jobs on encrypted Android Phones
PostPosted: May 11th, 2018, 11:13 
Offline

Joined: November 9th, 2006, 15:15
Posts: 2966
Anything with base OS of 6.1 or higher will have mandatory encryption, unless the encryption affects the performance of the handset (as with some cheaper handsets). Key is not stored as a static key, it is generated during startup processes so is not possible to extract easily.


Top
 Profile  
 
 Post subject: Re: Chip Off jobs on encrypted Android Phones
PostPosted: May 11th, 2018, 11:27 
Offline

Joined: May 28th, 2016, 9:16
Posts: 127
Location: Karlsruhe / Germany
So it's not worth to invest into Chip Off DR Tools for Smartphones?


Top
 Profile  
 
 Post subject: Re: Chip Off jobs on encrypted Android Phones
PostPosted: May 12th, 2018, 6:04 
Offline

Joined: September 16th, 2015, 9:06
Posts: 48
Location: Poland
Since Android 6.0 not anymore in my opinion.

_________________
Odzyskiwanie danych


Top
 Profile  
 
 Post subject: Re: Chip Off jobs on encrypted Android Phones
PostPosted: May 13th, 2018, 12:59 
Offline

Joined: June 11th, 2013, 17:01
Posts: 962
Location: USA
melvin wrote:
Since Android 6.0 not anymore in my opinion.

Agreed. It can be an expensive game to get into as well and as the market is shrinking might not be worth it. While some older phones have eMMC chips which can be easily read, there are UFS chips and the eMCP529 chip like in the Note 4. They both need special readers.

_________________
Hard Drive and RAID Data Recovery


Top
 Profile  
 
 Post subject: Re: Chip Off jobs on encrypted Android Phones
PostPosted: May 13th, 2018, 16:34 
Offline
User avatar

Joined: August 15th, 2006, 3:01
Posts: 2528
Location: CDRLabs @ Chandigarh [ India ]
ddrecovery wrote:
melvin wrote:
Since Android 6.0 not anymore in my opinion.

Agreed. It can be an expensive game to get into as well and as the market is shrinking might not be worth it. While some older phones have eMMC chips which can be easily read, there are UFS chips and the eMCP529 chip like in the Note 4. They both need special readers.


Well,
Nothing is Special About those Readers ,As You Have eMMC Reader WE Have UFS Readers Like Nuprog -> https://multi-com.eu/,details,id_pr,217 ... tools.html example taken from our friend bolos website. But i Wonder Why They Are Making Chipoff So Hard What Will They Achieve With This ,Google Should Have Some Consideration for Data Recovery Too .

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com


Top
 Profile  
 
 Post subject: Re: Chip Off jobs on encrypted Android Phones
PostPosted: May 13th, 2018, 18:43 
Offline

Joined: June 11th, 2013, 17:01
Posts: 962
Location: USA
It wasn't the fact that the readers are 'special', just that the cost may make it prohibitive to someone just entering the market.

_________________
Hard Drive and RAID Data Recovery


Top
 Profile  
 
 Post subject: Re: Chip Off jobs on encrypted Android Phones
PostPosted: May 14th, 2018, 10:48 
Offline
User avatar

Joined: August 15th, 2006, 3:01
Posts: 2528
Location: CDRLabs @ Chandigarh [ India ]
ddrecovery wrote:
It wasn't the fact that the readers are 'special', just that the cost may make it prohibitive to someone just entering the market.



Lol,
Seriously Mr Tim Homer Considering That Its The High End Phones And People Using Them PAYYYYYYYY Its Not a Issue Getting The Device .Reader Pricing Can Be Recovered in 4 To 6 Jobs ,So Please Reserve Your Comments Please .A Guy Entering DR Field Know The Costing Of Equipment

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com


Top
 Profile  
 
 Post subject: Re: Chip Off jobs on encrypted Android Phones
PostPosted: May 14th, 2018, 11:39 
Offline

Joined: June 11th, 2013, 17:01
Posts: 962
Location: USA
Amarbir[CDR-Labs] wrote:
ddrecovery wrote:
It wasn't the fact that the readers are 'special', just that the cost may make it prohibitive to someone just entering the market.

Lol,
Seriously Mr Tim Homer Considering That Its The High End Phones And People Using Them PAYYYYYYYY Its Not a Issue Getting The Device .Reader Pricing Can Be Recovered in 4 To 6 Jobs ,So Please Reserve Your Comments Please .A Guy Entering DR Field Know The Costing Of Equipment

LOL. As usual you totally miss the point of what the OP was asking.

_________________
Hard Drive and RAID Data Recovery


Top
 Profile  
 
 Post subject: Re: Chip Off jobs on encrypted Android Phones
PostPosted: May 16th, 2018, 6:04 
Offline

Joined: November 9th, 2006, 15:15
Posts: 2966
Only a small amount of non-encrypted handsets will use these UFS chips, so for most people it is not as essential as readers for traditional eMMC .

I think for the most part, not many people are working with recovery of android devices through choice - they are a pain in the A$$ :lol:


Top
 Profile  
 
 Post subject: Re: Chip Off jobs on encrypted Android Phones
PostPosted: May 16th, 2018, 8:25 
Offline
User avatar

Joined: May 13th, 2010, 11:17
Posts: 2340
Location: Kuwait
D_R wrote:
So it's not worth to invest into Chip Off DR Tools for Smartphones?


It worth if you know exactly what you are doing...

There is a big Diff. between repairing the phone and getting whats inside the phone..

and i think you will need a Little from both but its not gonna be easy once you get started.

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein


Top
 Profile  
 
 Post subject: Re: Chip Off jobs on encrypted Android Phones
PostPosted: May 28th, 2018, 18:16 
Offline

Joined: May 15th, 2018, 18:46
Posts: 25
Location: Toronto
hddguy knows what he is talking about. All Androids 6.0+ by default are encrypted by the manufacturers. You will on the other hand be able to take the chip off and even read it by the NAND reader, but will you be able to reconstruct the data? No.

_________________
Yevgeniy. No, NOT Malkin.
Ambassador at ADRS®


Top
 Profile  
 
 Post subject: Re: Chip Off jobs on encrypted Android Phones
PostPosted: May 29th, 2018, 10:05 
Offline

Joined: July 2nd, 2014, 8:05
Posts: 161
MasterHDD wrote:
All Androids 6.0+ by default are encrypted by the manufacturers

Wrong assumption.

Image


MasterHDD wrote:
will you be able to reconstruct the data?


Yes. Not always though since part of devices is really encrypted.

_________________
VISUAL NAND RECONSTRUCTOR. A big revolution in chip-off data recovery


Top
 Profile  
 
 Post subject: Re: Chip Off jobs on encrypted Android Phones
PostPosted: May 29th, 2018, 10:26 
Offline

Joined: November 9th, 2006, 15:15
Posts: 2966
This J5 has a base OS of 6.0.1 so it should really have been encrypted unless it was never configured with a lock screen

Quote:
If the device implementation supports a secure lock screen… then the device MUST support fulldisk encryption [Resources, 1 32] of the application private data (/data partition), as well as the application shared storage partition (/sdcard partition) if it is a permanent, non-removable part of the device.

For device implementations supporting full-disk encryption and with Advanced Encryption Standard (AES) crypto performance above 50MiB/sec, the full-disk encryption MUST be enabled by default at the time the user has completed the out-of-box setup experience. If a device implementation is already launched on an earlier Android version with full-disk encryption disabled by default, such a device cannot meet the requirement through a system software update and thus MAY be exempted.

Encryption MUST use AES with a key of 1 28-bits (or greater) and a mode designed for storage (for example, AES-XTS, AES-CBC-ESSIV). The encryption key MUST NOT be written to storage at any time without being encrypted.


I did see some cases without it, but on brand like Samsung with base OS of 6.0.1 or higher, I do not recall any that did not have encryption. It is useful to know that not 100% of devices are crypted, but if a device is 'dead' then it will always be a risk to remove chip and in most cases will result in encrypted partition


Top
 Profile  
 
 Post subject: Re: Chip Off jobs on encrypted Android Phones
PostPosted: May 29th, 2018, 15:49 
Offline
User avatar

Joined: December 29th, 2016, 18:13
Posts: 43
Location: Poland
@hddguy: J5 so J510 or J510FN was released with Android 5.1.1 Lollipop and all future updates are OTA... this is a reason that was not encrypted by default. In such phone it's not even necessary to make chip off to get full physical RAW an I'm not talking about ISP because for this phone it's not available if we mean simple connection (CMD line goes in layer 2 directly to CPU according to Xray).

You got right - chip off right now is really last resort in case where working on case for LE since we don't know if it's encrypted or not - even if it's not encrypted by default most of devices got right now such CPU power that encryption will not slow it done so many users encrypt their phone and then cry...... but there are totally different approach to get physical dump (for data recovery) from encrypted phone. We are able to perform such on many phones including Samsung (S7 as example which uses UFS and are encrypted out of box), many Xiaomi models which is also encrypted so chip off/BL/ISP are not a choice, ZTE, Alcatel etc. series.

P.S
Regarding to thread answer: In case of 5.x even if you will get encrypted contest you can still crack it since masterkey is located in footer with is accessible, in case of FDE in 6.x there is also a way but first need to unlock a phone so crack Gatekeepr mechanism for Pattern/PIN... really problem begins on 7.x where there is file based encryption. Overally: think twice before you will do chip off and in most of new devices as for example Huawei starting from P9 better is to repair them - otherwise you will end with purchasing a new board and replace CPU/eMMC from your death device to donor

_________________
Best regards,
Boguslaw Rzepka,
Multi-COM Ltd., Poland


Top
 Profile  
 
 Post subject: Re: Chip Off jobs on encrypted Android Phones
PostPosted: May 29th, 2018, 20:24 
Offline

Joined: June 11th, 2013, 17:01
Posts: 962
Location: USA
@Bolo: I have a question which is slightly related. I have an iPhone 4 GSM in for recovery. We cannot get access to the phone either through hardware or software fixes. I have been experimenting with a ramdisk technique developed by msftguy several years ago by accessing the iPhone through js and ssh. I can get access to the file system (see pic) but I cannot access user data. I am not sure if this is because the user partition is encrypted of that I cannot access mnt2 (but I can access mnt1). User appears to be just a shortcut. Work stopped on this project a while ago so I have no where else to turn. if you can offer some advice I would appreciate it. Pic of the file system and terminal output is attached.

Any help you can give would be appreciated.

Code:
oot@localhost's password:
Use mount.sh script to mount the partitions
Use reboot_bak to reboot
Use 'device_infos' to dump EMF keys (when imaging user volume)
-sh-4.0# device_infos
iphone data protection tools: http://code.google.com/p/iphone-dataprotection
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
   <key>DKey</key>
   <string>8caf31327c741978cd6654c2615b835d8687d83ab866b93d4b766eda61158979</string>
   <key>ECID</key>
   <integer>3429012415310</integer>
   <key>EMF</key>
   <string>c94261c13c39df3b49fc0d8a7975aded7bfa4906013e591fb12f8ab814babfd6</string>
   <key>btMac</key>
   <string>40:a6:d9:ca:ad:a2</string>
   <key>dataVolumeOffset</key>
   <integer>147456</integer>
   <key>dataVolumeUUID</key>
   <string>9b6b1598feca7c07</string>
   <key>hwModel</key>
   <string>N90AP</string>
   <key>imei</key>
   <string>012535008910292</string>
   <key>kern.bootargs</key>
   <string>rd=md0 nand-enable-reformat=1 -progress </string>
   <key>key835</key>
   <string>8259eb872d6e03fc3da08494d81c1772</string>
   <key>key89A</key>
   <string>d651c9460d733bc4400874314b139018</string>
   <key>key89B</key>
   <string>640937cad3eb10f61f13adce58caf36b</string>
   <key>lockers</key>
   <data>
   a0w0ADFHQUIxR0FCUt7SirXKiHEzkEbk5ar41dN8fxOxePt6RSXMk6ceAE2mvyKdl2M0
   74UbxppuYncga0xQAE1Wd0zxqAUadTiv6wB4N2IHFzwgnlOFQEUtg0V4F+Z9wpp0xPgW
   Pa88aB93uqJlECeCyT7ZXj3BK/DAMLSs8Dsq5AtJEs2t1a5mK+sTcKpIIFBd/2tMKAB5
   ZWvEhKwQGMoDxTDuRoFSmXx0yFRWVXo66arp3tmf8WFn1xkfI7ZS00lhqmtMAABFTk9E
   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   </data>
   <key>nand</key>
   <dict>
      <key>#block-pages</key>
      <integer>128</integer>
      <key>#bootloader-bytes</key>
      <integer>1536</integer>
      <key>#ce</key>
      <integer>4</integer>
      <key>#ce-blocks</key>
      <integer>4100</integer>
      <key>#page-bytes</key>
      <integer>8192</integer>
      <key>#spare-bytes</key>
      <integer>448</integer>
      <key>banks-per-ce</key>
      <integer>2</integer>
      <key>bbt-format</key>
      <integer>1</integer>
      <key>boot-from-nand</key>
      <data>
      AQAAAA==
      </data>
      <key>device-readid</key>
      <integer>848619416</integer>
      <key>dumpedPageSize</key>
      <integer>8212</integer>
      <key>is-bfn-partitioned</key>
      <true/>
      <key>meta-per-logical-page</key>
      <integer>12</integer>
      <key>metadata-whitening</key>
      <data>
      AQAAAA==
      </data>
      <key>name</key>
      <data>
      ZGlzawA=
      </data>
      <key>partitions</key>
      <dict>
         <key>Boot Block</key>
         <dict>
            <key>Block Count</key>
            <integer>1</integer>
            <key>Block Offset</key>
            <integer>0</integer>
         </dict>
         <key>Effaceable</key>
         <dict>
            <key>Block Count</key>
            <integer>1</integer>
            <key>Block Offset</key>
            <integer>1</integer>
         </dict>
         <key>Filesystem</key>
         <dict>
            <key>Block Count</key>
            <integer>4084</integer>
            <key>Block Offset</key>
            <integer>16</integer>
         </dict>
         <key>Firmware</key>
         <dict>
            <key>Block Count</key>
            <integer>8</integer>
            <key>Block Offset</key>
            <integer>8</integer>
         </dict>
         <key>NVRAM</key>
         <dict>
            <key>Block Count</key>
            <integer>6</integer>
            <key>Block Offset</key>
            <integer>2</integer>
         </dict>
      </dict>
      <key>ppn-device</key>
      <false/>
      <key>use-4k-aes-chain</key>
      <data>
      AQAAAA==
      </data>
      <key>valid-meta-per-logical-page</key>
      <integer>10</integer>
      <key>vendor-type</key>
      <integer>1376273</integer>
   </dict>
   <key>ramdisk compile time</key>
   <string>Jul  9 2012 23:31:09</string>
   <key>ramdisk revision</key>
   <string>8c6b79b04374</string>
   <key>serialNumber</key>
   <string>88049GK9A4S</string>
   <key>udid</key>
   <string>4f734d8fd9960c0ecff1d7fd85ebc1c0719ae093</string>
   <key>wifiMac</key>
   <string>40:a6:d9:ca:ad:a3</string>
</dict>
</plist>
-sh-4.0# ls
-sh-4.0# ls /
System   bin  dev  etc  mktar.sh  mnt1  mnt2  private  sbin  usr  var
-sh-4.0# mount
/dev/md0 on / (hfs, local, noatime)
devfs on /dev (devfs, local, nobrowse)
-sh-4.0# mount.sh
Mounting /dev/disk0s1s1 on /mnt1 ..
Mounting /dev/disk0s1s2 on /mnt2 ..
mount_hfs: Invalid argument
-sh-4.0# mount.sh
/dev/disk0s1s1 already mounted on /mnt1
Mounting /dev/disk0s1s2 on /mnt2 ..
mount_hfs: Invalid argument
-sh-4.0# ls /mnt2/
-sh-4.0# ls /mnt1/
Applications  Library  User  boot   dev  lib  private  tmp  var
Developer     System   bin   cores  etc  mnt  sbin     usr
-sh-4.0# ls /mnt2/Users/
ls: cannot access /mnt2/Users/: No such file or directory
-sh-4.0# ls /mnt1/Users/
ls: cannot access /mnt1/Users/: No such file or directory
-sh-4.0# ls /mnt1/Librarty/
ls: cannot access /mnt1/Librarty/: No such file or directory
-sh-4.0# ls /mnt1/Library/
Activator        Frameworks      Managed Preferences  Printers
Application Support  Internet Plug-Ins   MobileDevice        Ringtones
Audio           Keychains      MobileSubstrate      Updates
Caches           LaunchAgents   PreferenceBundles    Wallpaper
Dictionaries        LaunchDaemons   PreferenceLoader
Filesystems        Logs      Preferences
-sh-4.0# ls /mnt1/MobileDevice/
ls: cannot access /mnt1/MobileDevice/: No such file or directory
-sh-4.0# ls /mnt1/Library/MobileDevice
/mnt1/Library/MobileDevice
-sh-4.0# ls /mnt1/Library/MobileDevice/Media
ls: cannot access /mnt1/Library/MobileDevice/Media: No such file or directory
-sh-4.0# ls /mnt1/Users/
ls: cannot access /mnt1/Users/: No such file or directory
-sh-4.0#


Attachments:
Terminal Grab iPhone 4.png
Terminal Grab iPhone 4.png [ 179.62 KiB | Viewed 4326 times ]

_________________
Hard Drive and RAID Data Recovery
Top
 Profile  
 
 Post subject: Re: Chip Off jobs on encrypted Android Phones
PostPosted: May 30th, 2018, 6:59 
Offline
User avatar

Joined: December 29th, 2016, 18:13
Posts: 43
Location: Poland
@ddrecovery: Im able to make full physical dump of A1332 without chipoff.... you will need to send phone to me to perform this

_________________
Best regards,
Boguslaw Rzepka,
Multi-COM Ltd., Poland


Top
 Profile  
 
 Post subject: Re: Chip Off jobs on encrypted Android Phones
PostPosted: May 30th, 2018, 9:16 
Offline

Joined: June 11th, 2013, 17:01
Posts: 962
Location: USA
Many thanks, but we don't have the budget with this one to mail to another country. I will keep trying. Thanks for the offer.

_________________
Hard Drive and RAID Data Recovery


Top
 Profile  
 
 Post subject: Re: Chip Off jobs on encrypted Android Phones
PostPosted: May 30th, 2018, 20:14 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 10614
Location: Australia
FWIW, you keep trying to access Users instead of User ...

    ls /mnt1/User

Could we see the contents of mount.sh? That file/script appears to be the source of the "invalid argument".

    cat mount.sh

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Chip Off jobs on encrypted Android Phones
PostPosted: May 30th, 2018, 20:26 
Offline

Joined: October 16th, 2013, 13:21
Posts: 717
Location: Brazil
mnt2 is not mounted ( mount.sh throws an error about this ) . So, the ls commands to paths initiated in /mnt2 will not work.

Along with the Users think @fzakbar mentioned, you also tried a lot of paths that are not present in the /mnt1 filesystem. The first ls ( ls /mnt1 ) showed the dirs it found.

Were those other ls commands just following some tutorial ?

Maybe some part of path is missing ? From your picture, I guess the thing called MobileDevice would be in a path /mnt1/Library/MobileSubstrate/MobileDevice ( note the /Library/MobileSubstrate/ in the middle )


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 33 posts ]  Go to page 1, 2  Next

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: agent007 and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group