Open GoogleCodeExporter opened 8 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
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:
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
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
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
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
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
Original issue reported on code.google.com by
denisele...@gmail.com
on 8 Feb 2013 at 5:04