search

fre4kyC0de / iphone-dataprotection

Automatically exported from code.google.com/p/iphone-dataprotection
0 stars 1 forks source link

HFSExplorer is not decrpyting the dmg files #91

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. dd both partitions (system & media)
2. confirm plist is present
3. launch HFSExplorer and load image

What is the expected output? What do you see instead?
I expect to be able to read the contents of the images. They are 7.9 GB (8 GB 
model) in size so I am confident that both partitions have been successfully 
received. The keychain database and keys plist files are present in the image 
directory.

What version of the product are you using? On what operating system?
OS X version : 10.8 was used to create the ramdisk, jailbreak the device, and 
perform the dd process. 

Windows Vista was used to read the images in HFSExplorer, which was downloaded 
from 
https://code.google.com/p/iphone-dataprotection/downloads/detail?name=hfsexplore
r_iphoneEMF_d4ea02bd3fc3.zip&can=2&q=

XCode version : 4.5

Tools revision : e57806d960f7

Original issue reported on code.google.com by denisele...@gmail.com on 8 Feb 2013 at 5:04

GoogleCodeExporter commented 9 years ago 
When you extract or open files through HFSExplorer they are decrypted 
incorrectly and contain garbage ?
This is probably due to a bug in the computation of the "dataVolumeOffset" 
parameter in the plist file. There is a workaround here :
http://code.google.com/p/iphone-dataprotection/issues/detail?id=76#c9
Following those instructions should allow you to fix the dataVolumeOffset 
parameter to the correct value.

Could you also post the HFSExplorer log output (File->Debug console) ? Thanks.

Original comment by jean.sig...@gmail.com on 10 Feb 2013 at 12:03

GoogleCodeExporter commented 9 years ago 
Sorry, I meant to state that I had reviewed the related issues. I followed 
those instructions, but without access to systembag.kb (and the file structure 
it is stored in) those attempts failed.

The dd image is missing several key directories, the most important (for 
decrypting) being the keybags directory which contains the systembag.kb file. I 
realize that running emf_decrypter.py relies upon this file and the keys plist 
to properly decrypt the filesystem, so I had hoped that HFSExplorer would see 
both partitions and be able to decrypt the filesystem on the fly. 

Links to the Applications and User directories are broken as well. I've 
attached the debug data as well as a screen shot of what HFSExplorer reports is 
available at the start of the file system. 

What am I doing wrong?

Is there a way to modify emf_decrypter.py so that I can provide it with 
systembag.kb as a third argument? This does not address the problem, but it 
will allow me to read the data while we figure this out.

Thanks for your help!

Original comment by denisele...@gmail.com on 11 Feb 2013 at 11:19

Attachments:

GoogleCodeExporter commented 9 years ago 
What dd command line did you use ? the screenshot shows the system partition, 
do you have an image for the data partition as well or did you image the whole 
/dev/disk0 device ? in that case its normal that it doesnt work, you need an 
image of the data partition only (see dump_data_partition.sh).

also, HFSExplorer does not support compressed HFS files (size 0) that are 
present on the system partition, but this is not related to the encryption.

Original comment by jean.sig...@gmail.com on 11 Feb 2013 at 12:39

GoogleCodeExporter commented 9 years ago 
I used the dump_data_partition.sh script and modified the dd line so that it 
would extract both partitions; I could have told it to pull rdisk0 instead 
though. I guess I should try that next.

#original
#ssh $SSHOPTS root@localhost "dd if=/dev/rdisk0s2s1  bs=8192 || dd 
if=/dev/rdisk0s1s2  bs=8192" > $OUT

#mine
ssh $SSHOPTS root@localhost "dd if=/dev/rdisk0s2s1  bs=8192 && dd 
if=/dev/rdisk0s1s2  bs=8192" >> $OUT 

The size of the resulting image leads me to believe that the data partition was 
obtained--the system partition should be around 1GB.

Original comment by denisele...@gmail.com on 11 Feb 2013 at 1:32

GoogleCodeExporter commented 9 years ago 
Ha ok, basically your modified command concatenates both partitions into one 
output file (btw are you sure you did not change rdisk0s2s1 to rdisk0s1s2, does 
not makes sense with the screenshot otherwise). when you open it, hfsexplorer 
only sees the first (system).
to fix this, either reacquire the data partition using the unmodified script, 
or split your image file in two (multiply the blockSize and totalBlocks fields 
of the system partition HFS header to get the offset of the data partition in 
the file).

Original comment by jean.sig...@gmail.com on 11 Feb 2013 at 1:43

GoogleCodeExporter commented 9 years ago 
Yes, that was intentional as I wanted both partitions in a single image. I 
mistyped the rdisk0s2s1 here (good catch); the script that was actually run had 
rdisk0s1s1 and rdisk0s1s2. I did not realize that HFSExplorer only reads and 
displays one partition at a time. 

When I mount the same image on my Mac, I get the same result. I guess it sees 
only the first system as well. I will try your second option first and let you 
know what happens.

Original comment by denisele...@gmail.com on 11 Feb 2013 at 1:59

GoogleCodeExporter commented 9 years ago 
I ended up running the dump script two more times. In the first attempt, I used 
the following parameters:

ssh $SSHOPTS root@localhost "dd if=/dev/rdisk0 bs=8192" > $OUT

This resulted in a 8 GB file, as expected. I was unable to mount it (I received 
the following error: no mountable filesystems).

I then changed the script to contain the following: 

ssh $SSHOPTS root@localhost "dd if=/dev/rdisk0s1s2  bs=8192" > $OUT 

so that I would extract only the data partition and this worked like a champ. 
Your emf decrypter tool decrypted the file system without any issues.

I will keep the "full disk" images and use the Sleuth Kit to examine them. 

Thanks for looking into it.

Original comment by denisele...@gmail.com on 11 Feb 2013 at 5:48