View topic - Chip Off jobs on encrypted Android Phones

Main » Forums home » Flash storage, SSD

All times are UTC - 5 hours [ DST ]

Chip Off jobs on encrypted Android Phones

Page 1 of 3

[ 44 posts ]

Go to page 1, 2, 3 Next

Print view

Previous topic | Next topic

Author

Message

D_R

Post subject: Chip Off jobs on encrypted Android Phones

Posted: May 11th, 2018, 8:18

Joined: May 28th, 2016, 9:16
Posts: 151
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

hddguy

Post subject: Re: Chip Off jobs on encrypted Android Phones

Posted: May 11th, 2018, 11:13

Joined: November 9th, 2006, 15:15
Posts: 2983

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

D_R

Post subject: Re: Chip Off jobs on encrypted Android Phones

Posted: May 11th, 2018, 11:27

Joined: May 28th, 2016, 9:16
Posts: 151
Location: Karlsruhe / Germany

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

Top

melvin

Post subject: Re: Chip Off jobs on encrypted Android Phones

Posted: May 12th, 2018, 6:04

Joined: September 16th, 2015, 9:06
Posts: 297
Location: Poland

Since Android 6.0 not anymore in my opinion.

_________________
odzyskiwanie danych

Top

ddrecovery

Post subject: Re: Chip Off jobs on encrypted Android Phones

Posted: May 13th, 2018, 12:59

Joined: June 11th, 2013, 17:01
Posts: 1732
Location: Phoenix, AZ 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.

_________________
HDD, SSD, Flash and RAID Data Recovery
Founder of The Data Recovery Professionals Group

Top

Amarbir[CDR-Labs]

Post subject: Re: Chip Off jobs on encrypted Android Phones

Posted: May 13th, 2018, 16:34

Joined: August 15th, 2006, 3:01
Posts: 3488
Location: CDRLabs @ Chandigarh [ India ]

ddrecovery wrote:

melvin wrote:

Since Android 6.0 not anymore in my opinion.

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 [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

Top

ddrecovery

Post subject: Re: Chip Off jobs on encrypted Android Phones

Posted: May 13th, 2018, 18:43

Joined: June 11th, 2013, 17:01
Posts: 1732
Location: Phoenix, AZ 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.

_________________
HDD, SSD, Flash and RAID Data Recovery
Founder of The Data Recovery Professionals Group

Top

Amarbir[CDR-Labs]

Post subject: Re: Chip Off jobs on encrypted Android Phones

Posted: May 14th, 2018, 10:48

Joined: August 15th, 2006, 3:01
Posts: 3488
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 [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

Top

ddrecovery

Post subject: Re: Chip Off jobs on encrypted Android Phones

Posted: May 14th, 2018, 11:39

Joined: June 11th, 2013, 17:01
Posts: 1732
Location: Phoenix, AZ 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. As usual you totally miss the point of what the OP was asking.

_________________
HDD, SSD, Flash and RAID Data Recovery
Founder of The Data Recovery Professionals Group

Top

hddguy

Post subject: Re: Chip Off jobs on encrypted Android Phones

Posted: May 16th, 2018, 6:04

Joined: November 9th, 2006, 15:15
Posts: 2983

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

einstein9

Post subject: Re: Chip Off jobs on encrypted Android Phones

Posted: May 16th, 2018, 8:25

Joined: May 13th, 2010, 11:17
Posts: 2815
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

MasterHDD

Post subject: Re: Chip Off jobs on encrypted Android Phones

Posted: May 28th, 2018, 18:16

Joined: May 15th, 2018, 18:46
Posts: 26
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

Sasha Sheremetov

Post subject: Re: Chip Off jobs on encrypted Android Phones

Posted: May 29th, 2018, 10:05

Joined: July 2nd, 2014, 8:05
Posts: 210

MasterHDD wrote:

All Androids 6.0+ by default are encrypted by the manufacturers

Wrong assumption.

MasterHDD wrote:

will you be able to reconstruct the data?

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

_________________
VISUAL NAND RECONSTRUCTOR. Since 2014.

Top

hddguy

Post subject: Re: Chip Off jobs on encrypted Android Phones

Posted: May 29th, 2018, 10:26

Joined: November 9th, 2006, 15:15
Posts: 2983

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

Bolo

Post subject: Re: Chip Off jobs on encrypted Android Phones

Posted: May 29th, 2018, 15:49

Joined: December 29th, 2016, 18:13
Posts: 143
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

ddrecovery

Post subject: Re: Chip Off jobs on encrypted Android Phones

Posted: May 29th, 2018, 20:24

Joined: June 11th, 2013, 17:01
Posts: 1732
Location: Phoenix, AZ 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 [ 179.62 KiB | Viewed 26542 times ]

_________________
HDD, SSD, Flash and RAID Data Recovery
Founder of The Data Recovery Professionals Group

Top

Bolo

Post subject: Re: Chip Off jobs on encrypted Android Phones

Posted: May 30th, 2018, 6:59

Joined: December 29th, 2016, 18:13
Posts: 143
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

ddrecovery

Post subject: Re: Chip Off jobs on encrypted Android Phones

Posted: May 30th, 2018, 9:16

Joined: June 11th, 2013, 17:01
Posts: 1732
Location: Phoenix, AZ 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.

_________________
HDD, SSD, Flash and RAID Data Recovery
Founder of The Data Recovery Professionals Group

Top

fzabkar

Post subject: Re: Chip Off jobs on encrypted Android Phones

Posted: May 30th, 2018, 20:14

Joined: September 8th, 2009, 18:21
Posts: 15989
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

rogfanther

Post subject: Re: Chip Off jobs on encrypted Android Phones

Posted: May 30th, 2018, 20:26

Joined: October 16th, 2013, 13:21
Posts: 713
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

Page 1 of 3

[ 44 posts ]

Go to page 1, 2, 3 Next

Main » Forums home » Flash storage, SSD

All times are UTC - 5 hours [ DST ]

Who is online

Users browsing this forum: csava and 3 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