HDD GURU FORUMS http://forum.hddguru.com/ |
|
Chip Off jobs on encrypted Android Phones http://forum.hddguru.com/viewtopic.php?f=10&t=36802 |
Page 2 of 3 |
Author: | ddrecovery [ May 30th, 2018, 20:31 ] |
Post subject: | Re: Chip Off jobs on encrypted Android Phones |
Thank you both. I have set this up several times over the past few weeks and probably got a little sloppy (or frustrated) when I was setting this up this last time. I will redo the terminal access and report back. Many thanks. |
Author: | fzabkar [ May 30th, 2018, 20:36 ] |
Post subject: | Re: Chip Off jobs on encrypted Android Phones |
AIUI, /dev/disk0s1s2 is the partition that contains the user's data. Either it is not being mounted correctly, or the partition is damaged. I see some Internet references which suggest mounting /dev/disk0s1s2 to /mnt1/var rather than /mnt2. That should at least tell us whether there is something wrong with the mount point, or so I think. If the partition is damaged, I would be looking for a way to "dd" the raw partition data to another storage medium. Perhaps there is such a tool in the OS? |
Author: | rogfanther [ May 30th, 2018, 20:58 ] |
Post subject: | Re: Chip Off jobs on encrypted Android Phones |
Please, can you post the contents of mount.sh Also, maybe trying to issue a comand of dd --help to see if it is present. If not present, maybe it could be compiled in other place then transferred to the phone. |
Author: | fzabkar [ May 30th, 2018, 21:02 ] |
Post subject: | Re: Chip Off jobs on encrypted Android Phones |
I'm wondering if the data on the second partition are encrypted, and whether the partition needs to be mounted by the OS before the OS can decrypt it. If so, then a raw image may not be useful. |
Author: | rogfanther [ May 30th, 2018, 21:24 ] |
Post subject: | Re: Chip Off jobs on encrypted Android Phones |
Maybe. The commands in the mount script may show some light in this. Also, depending on how/where/by who the partition is encrypted ( if it is ) a raw dump of it could be decrypted outside of the device. But lets first take a look at that script. Maybe a simple command is missing in it. |
Author: | ddrecovery [ May 31st, 2018, 14:08 ] |
Post subject: | Re: Chip Off jobs on encrypted Android Phones |
I have copied a new terminal outputs below. A general one and the dd --help. I am not sure how to complete some of the steps you have detailed. How do I run 'commands in mount script'? mount.sh does see both partitions, but errors at mounting the HFS partition. How do I mount /dev/disk0s1s2 to /mnt1/var rather than /mnt2? The initial part of the terminal log is after entering 'device_infos', that part id what makes me thing the user data area might be encryted. Code: ssh -p 2022 root@localhost root@localhost's password: Permission denied, please try again. root@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# 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 /mnt1/User/ ls: cannot access /mnt1/User/: 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/Library/MobileSubstrate/ DynamicLibraries MobileSubstrate.dylib -sh-4.0# ls /mnt1/Library/MobileSubstrate/DynamicLibraries/ Activator.dylib PreferenceLoader.dylib TetherMeCC.dylib Activator.plist PreferenceLoader.plist TetherMeCC.plist EDGEEditPermit.dylib SBSettings.dylib TetherMeMIS.dylib EDGEEditPermit.plist SBSettings.plist TetherMeMIS.plist MobileSafety.dylib TetherMeBT.dylib libhide.dylib MobileSafety.plist TetherMeBT.plist libhide.plist -sh-4.0# ls /mnt1/var/ -sh-4.0# Code: sh-4.0# dd --help
Usage: dd [OPERAND]... or: dd OPTION Copy a file, converting and formatting according to the operands. bs=BYTES read and write up to BYTES bytes at a time cbs=BYTES convert BYTES bytes at a time conv=CONVS convert the file as per the comma separated symbol list count=BLOCKS copy only BLOCKS input blocks ibs=BYTES read up to BYTES bytes at a time (default: 512) if=FILE read from FILE instead of stdin iflag=FLAGS read as per the comma separated symbol list obs=BYTES write BYTES bytes at a time (default: 512) of=FILE write to FILE instead of stdout oflag=FLAGS write as per the comma separated symbol list seek=BLOCKS skip BLOCKS obs-sized blocks at start of output skip=BLOCKS skip BLOCKS ibs-sized blocks at start of input status=noxfer suppress transfer statistics BLOCKS and BYTES may be followed by the following multiplicative suffixes: c =1, w =2, b =512, kB =1000, K =1024, MB =1000*1000, M =1024*1024, xM =M GB =1000*1000*1000, G =1024*1024*1024, and so on for T, P, E, Z, Y. Each CONV symbol may be: ascii from EBCDIC to ASCII ebcdic from ASCII to EBCDIC ibm from ASCII to alternate EBCDIC block pad newline-terminated records with spaces to cbs-size unblock replace trailing spaces in cbs-size records with newline lcase change upper case to lower case ucase change lower case to upper case swab swap every pair of input bytes sync pad every input block with NULs to ibs-size; when used with block or unblock, pad with spaces rather than NULs excl fail if the output file already exists nocreat do not create the output file notrunc do not truncate the output file noerror continue after read errors fdatasync physically write output file data before finishing fsync likewise, but also write metadata Each FLAG symbol may be: append append mode (makes sense only for output; conv=notrunc suggested) directory fail unless a directory sync likewise, but also for metadata fullblock accumulate full blocks of input (iflag only) nonblock use non-blocking I/O noctty do not assign controlling terminal from file nofollow do not follow symlinks Sending a INFO signal to a running `dd' process makes it print I/O statistics to standard error and then resume copying. $ dd if=/dev/zero of=/dev/null& pid=$! $ kill -INFO $pid; sleep 1; kill $pid 18335302+0 records in 18335302+0 records out 9387674624 bytes (9.4 GB) copied, 34.6279 seconds, 271 MB/s Options are: --help display this help and exit --version output version information and exit Report dd bugs to bug-coreutils@gnu.org GNU coreutils home page: <http://www.gnu.org/software/coreutils/> General help using GNU software: <http://www.gnu.org/gethelp/> Report dd translation bugs to <http://translationproject.org/team/> For complete documentation, run: info coreutils 'dd invocation' -sh-4.0# |
Author: | ddrecovery [ May 31st, 2018, 14:33 ] |
Post subject: | Re: Chip Off jobs on encrypted Android Phones |
Forgot to mention. This is what I have been following. http://msftguy.blogspot.com/2012/01/aut ... mentPage=2 |
Author: | fzabkar [ June 1st, 2018, 16:09 ] |
Post subject: | Re: Chip Off jobs on encrypted Android Phones |
The following command should display the contents of mount.sh:
This command should list all the devices:
Would it be possible to add a storage device (eg SD card) to the iPhone and then dd the raw, broken (?) partition to the card? |
Author: | ddrecovery [ June 2nd, 2018, 19:11 ] |
Post subject: | Re: Chip Off jobs on encrypted Android Phones |
The latest terminal output is below. Hope that helps. These old phones do not take SD Cards unfortunately, but it is connected to a Mac to get terminal access so might be possible to use that? Code: -sh-4.0# cat /bin/mount.sh
#!/bin/sh # Script to mount the volumes.. MOUNTS=$(mount) while read LINE do set $LINE if [ $3 == "/mnt1" ] then MNT1=$1 else if [ $3 == "/mnt2" ] then MNT2=$1 fi fi done <<< "$MOUNTS" if [ -z $MNT1 ] then if [ -b /dev/disk0s1s1 ] then # iOS5 echo "Mounting /dev/disk0s1s1 on /mnt1 .." mount_hfs /dev/disk0s1s1 /mnt1 else if [ -b /dev/disk0s1 ] then echo "Checking /dev/disk0s1 .." fsck_hfs /dev/disk0s1 echo "Mounting /dev/disk0s1 on /mnt1 .." mount_hfs /dev/disk0s1 /mnt1 else echo "Could not mount system volume; retry later or file a bug." fi fi else echo "$MNT1 already mounted on /mnt1" fi if [ -z $MNT2 ] then if [ -b /dev/disk0s1s2 ] then # iOS5 echo "Mounting /dev/disk0s1s2 on /mnt2 .." mount_hfs /dev/disk0s1s2 /mnt2 else if [ -b /dev/disk0s2s1 ] then # iOS 4 echo "Mounting /dev/disk0s2s1 on /mnt2 .." mount_hfs /dev/disk0s2s1 /mnt2 else if [ -b /dev/disk0s2 ] then # iOS3 .. maybe? echo "Checking /dev/disk0s2 .." fsck_hfs /dev/disk0s2 echo "Mounting /dev/disk0s2 on /mnt2 .." mount_hfs /dev/disk0s2 /mnt2 else echo "Could not mount user data volume; retry later or file a bug." fi fi fi else echo "$MNT2 already mounted on /mnt2" -sh-4.0# ls /dev aes_0 klog random ttyp8 bpf0 md0 rdisk0 ttyp9 bpf1 mux.spi-baseband rdisk0s1 ttypa bpf2 null rdisk0s1s1 ttypb bpf3 pf rdisk0s1s2 ttypc btreset ptmx rmd0 ttypd btwake ptyp0 tty ttype console ptyp1 tty.bluetooth ttypf cu.bluetooth ptyp2 tty.debug ttys000 cu.debug ptyp3 tty.gas-gauge ttys001 cu.gas-gauge ptyp4 tty.gps uart.bluetooth cu.gps ptyp5 tty.highland-park uart.debug cu.highland-park ptyp6 tty.iap uart.gas-gauge cu.iap ptyp7 tty.umts uart.gps cu.umts ptyp8 ttyp0 uart.highland-park disk0 ptyp9 ttyp1 uart.iap disk0s1 ptypa ttyp2 uart.umts disk0s1s1 ptypb ttyp3 urandom disk0s1s2 ptypc ttyp4 vn0 fsevents ptypd ttyp5 vn1 io8log ptype ttyp6 zero io8logmt ptypf ttyp7 -sh-4.0# |
Author: | fzabkar [ June 2nd, 2018, 23:28 ] |
Post subject: | Re: Chip Off jobs on encrypted Android Phones |
ISTM that, in the absence of arguments, the mount.sh script executes the following commands:
mount_hfs /dev/disk0s1s1 /mnt1 echo "Mounting /dev/disk0s1s2 on /mnt2 .." mount_hfs /dev/disk0s1s2 /mnt2 Obviously the second mount operation fails, probably because of a damaged HFS partition. It would be tempting to run fsck against the second partition but it's probably not a good idea (fsck is the Unix equivalent of CHKDSK). I don't know which commands are available to you, but I would try to view the first sector of the damaged partition in hex mode.
dd if=/dev/disk0s1s2 bs=512 count=1 | hexdump -C dd if=/dev/disk0s1s2 bs=512 count=1 | file The echo command tests whether the hexdump command exists and whether it is able to display hex data. The first dd command reads the first sector of the partition and pipes it to hexdump. The next dd command reads the first sector of the partition and analyses it. Edit: You could use fsck_hfs with the -n switch ("Never attempt to repair any damage that is found"). I would confirm that the next line has the correct syntax before running it.
https://man.cx/fsck_hfs(8) |
Author: | fzabkar [ June 2nd, 2018, 23:46 ] |
Post subject: | Re: Chip Off jobs on encrypted Android Phones |
fzabkar wrote:
Maybe this would be better:
|
Author: | rogfanther [ June 4th, 2018, 19:55 ] |
Post subject: | Re: Chip Off jobs on encrypted Android Phones |
You can chain cat, dd and the ssh commands ( or netcat, if the platforms involved support it ) to transfer the dump of the partition to a computer. |
Author: | fzabkar [ June 4th, 2018, 20:02 ] |
Post subject: | Re: Chip Off jobs on encrypted Android Phones |
rogfanther wrote: You can chain cat, dd and the ssh commands ( or netcat, if the platforms involved support it ) to transfer the dump of the partition to a computer. This was my private suggestion to the OP: fzabkar wrote: What is the size of the damaged partition? What is the size of the RAM disk (rdisk)? Would it be feasible to dd your data to the RAM disk as an image file, and then use SFTP to transfer this image file to your Windows PC? You may need to dd the partition as multiple sections. http://osxdaily.com/2011/08/04/ssh-to-iphone/ What do you think? I only have a very rudimentary understanding (?) of *nix. |
Author: | dnkta [ May 20th, 2019, 2:48 ] |
Post subject: | Re: Chip Off jobs on encrypted Android Phones |
Hello guys, I didn't want to start a new thread so i'm replying to this one. I have an Essential Phone with UFS 2.1 chip which has died and I have some important data on it. It's encrypted by default (Android 9). I still have the PIN used on the device to decrypt. Theoretically is there a way to dump the RAW data from the chip and then decrypt it on PC? I also read online of people that have managed to swap the ufs chip from one device to another and were able to boot the device even with encryption. What would be the best way to do this and any services that you know who can provide a solution? Thanks |
Author: | fzabkar [ May 20th, 2019, 3:45 ] |
Post subject: | Re: Chip Off jobs on encrypted Android Phones |
I wasn't able to find an adapter, but here is a bridge chip that looks promising: JMS901 USB 3.1 Gen 1 to UFS/UHS-1 Bridge: http://www.jmicron.com/PDF/brief/jms901.pdf Quote: The JMS901 is an innovative and cost-effective USB 3.1 Gen1 to UFS 2.1 and UHS-I bridge controller. @dnkta, have you investigated the possibility of getting your phone repaired? |
Author: | dnkta [ May 20th, 2019, 3:50 ] |
Post subject: | Re: Chip Off jobs on encrypted Android Phones |
Thanks. I will check it out. Yes, i'm thinking to try to repair it first, if it doesn't work I have to try different route. |
Author: | fzabkar [ May 20th, 2019, 4:20 ] |
Post subject: | Re: Chip Off jobs on encrypted Android Phones |
I could help you locate the voltage test points, but I would need hi-res images of the PCB(s). |
Author: | underdeath21 [ May 21st, 2019, 12:03 ] |
Post subject: | Re: Chip Off jobs on encrypted Android Phones |
seriously i dont understand why manufacturers encrypt chips first place?and why cant manufacturers provide remove encryption somewhere inside phone menu to turn off if you dont want it.. like warning text if you turn off encryption off your data will be no longer protected and anybody can read it,do you want proceed yes or no. why cant users have option turn off encryption if they dont want it.. |
Author: | HaQue [ May 21st, 2019, 18:17 ] |
Post subject: | Re: Chip Off jobs on encrypted Android Phones |
They are trying to protect you from yourself. |
Author: | Ronald111 [ January 13th, 2020, 2:39 ] |
Post subject: | Re: Chip Off jobs on encrypted Android Phones |
Have this eMMC from Huawei MediaPad M5 H26M62002JPR 32GB eMMC5.1 1znm 128Gb 11.5x13x0.8 153ball FBGA It is Android 9 and encrypted, but it is not the case. eMMC is from a working device, and was taken off properly (100% no damage to it). But it cannot be seen in any reader/any computer/any OS. Seems like broken but it is not, 100%. Found the same working device→chip-off→the same situation. Has Huawei blocked anyhow the chip thus preventing any chip-off tryouts? Have anyone heard anything? |
Page 2 of 3 | All times are UTC - 5 hours [ DST ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |