Page 2 of 3
Re: Chip Off jobs on encrypted Android Phones
Posted: May 30th, 2018, 20:31
by ddrecovery
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.
Re: Chip Off jobs on encrypted Android Phones
Posted: May 30th, 2018, 20:36
by fzabkar
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?
Re: Chip Off jobs on encrypted Android Phones
Posted: May 30th, 2018, 20:58
by rogfanther
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.
Re: Chip Off jobs on encrypted Android Phones
Posted: May 30th, 2018, 21:02
by fzabkar
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.
Re: Chip Off jobs on encrypted Android Phones
Posted: May 30th, 2018, 21:24
by rogfanther
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.
Re: Chip Off jobs on encrypted Android Phones
Posted: May 31st, 2018, 14:08
by ddrecovery
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#
Re: Chip Off jobs on encrypted Android Phones
Posted: May 31st, 2018, 14:33
by ddrecovery
Forgot to mention. This is what I have been following.
http://msftguy.blogspot.com/2012/01/aut ... mentPage=2
Re: Chip Off jobs on encrypted Android Phones
Posted: June 1st, 2018, 16:09
by fzabkar
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?
Re: Chip Off jobs on encrypted Android Phones
Posted: June 2nd, 2018, 19:11
by ddrecovery
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#
Re: Chip Off jobs on encrypted Android Phones
Posted: June 2nd, 2018, 23:28
by fzabkar
ISTM that, in the absence of arguments, the mount.sh script executes the following commands:
echo "Mounting /dev/disk0s1s1 on /mnt1 .."
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.
echo "ABCD" | hexdump -C
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.
fsck_hfs /dev/disk0s1s2 -n
https://man.cx/fsck_hfs(8)
Re: Chip Off jobs on encrypted Android Phones
Posted: June 2nd, 2018, 23:46
by fzabkar
fzabkar wrote:fsck_hfs /dev/disk0s1s2 -n
Maybe this would be better:
fsck_hfs -n /dev/disk0s1s2
Re: Chip Off jobs on encrypted Android Phones
Posted: June 4th, 2018, 19:55
by rogfanther
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.
Re: Chip Off jobs on encrypted Android Phones
Posted: June 4th, 2018, 20:02
by fzabkar
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.
Re: Chip Off jobs on encrypted Android Phones
Posted: May 20th, 2019, 2:48
by dnkta
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
Re: Chip Off jobs on encrypted Android Phones
Posted: May 20th, 2019, 3:45
by fzabkar
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.pdfThe 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?
Re: Chip Off jobs on encrypted Android Phones
Posted: May 20th, 2019, 3:50
by dnkta
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.
Re: Chip Off jobs on encrypted Android Phones
Posted: May 20th, 2019, 4:20
by fzabkar
I could help you locate the voltage test points, but I would need hi-res images of the PCB(s).
Re: Chip Off jobs on encrypted Android Phones
Posted: May 21st, 2019, 12:03
by underdeath21
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..
Re: Chip Off jobs on encrypted Android Phones
Posted: May 21st, 2019, 18:17
by HaQue
They are trying to protect you from yourself.
Re: Chip Off jobs on encrypted Android Phones
Posted: January 13th, 2020, 2:39
by Ronald111
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?