Chip Off jobs on encrypted Android Phones

[D_R]

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?

[hddguy]

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.

[D_R]

So it's not worth to invest into Chip Off DR Tools for Smartphones?

[melvin]

Since Android 6.0 not anymore in my opinion.

[ddrecovery]

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.

[Amarbir[CDR-Labs]]

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 .

[ddrecovery]

It wasn't the fact that the readers are 'special', just that the cost may make it prohibitive to someone just entering the market.

[Amarbir[CDR-Labs]]

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

[ddrecovery]

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.

[hddguy]

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$$

[einstein9]

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.

[MasterHDD]

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.

[Sasha Sheremetov]

All Androids 6.0+ by default are encrypted by the manufacturers

Wrong assumption.

will you be able to reconstruct the data?

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

[hddguy]

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

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

[Bolo]

@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

[ddrecovery]

@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

[Bolo]

@ddrecovery: Im able to make full physical dump of A1332 without chipoff.... you will need to send phone to me to perform this

[ddrecovery]

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.

[fzabkar]

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

[rogfanther]

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 )