undelete recovering 0 out of 500 small text files that were just deleted

[GoogleCodeExporter]

I wouldn't call this a bug "per se", mostly an annoyance: I am trying to delete 
files and have ios_examiner undelete them for me, however it finds none of 
those files. It does undelete things, just not the ones I'm looking for. Look 
below...

What steps will reproduce the problem?
1. Generate a bunch of small text files in the data partition (say for instance 
in the user's home directory, /var/mobile); I used this script in a Mac to 
generate 500 text files (4KB each) and transfered the files to the iOS device 
afterwards using scp: for i in $( seq -w 000 999 ); do for j in $( seq -w 000 
499 ); do echo "FILE$i"; done > FILE_$i.txt ; done
2. Reboot the device to ensure the files are written to disk.
3. Delete the files in the device, for instance using "rm" through a console or 
SSH session.
4. Turn the device off.
5. Boot your custom ramdisk; use ios_examiner's nand_dump to obtain a NAND 
image (having issued a "bruteforce" first to find the passcode, which in fact 
is blank).
6. Re-run ios_examiner over the image, and run undelete to try to recover the 
files.

What is the expected output? What do you see instead?
None of the newly created text files is recovered. After many tests and 
hundreds of files, I would expect some of them to be recovered correctly! I am 
not saying that the tool doesn't work - it does, because in facts it recovers 
stuff. But I am annoyed that none of the 500 files that were just deleted, were 
recovered.

I've had similarly disappointing results with sets of 20-to-100 PDF files as 
well  (50-200 KB in size each).

Can you think of any details about iOS data protection that could be causing 
this behaviour?

What version of the product are you using? On what operating system?
OS X version : 10.8.4
XCode version : 4.6.3 (4H1503)
Tools revision : d67884c68fec+ tip

Original issue reported on code.google.com by p...@lgomez.es on 1 Jul 2013 at 6:17

[GoogleCodeExporter]

currently the undelete algorithm uses a rather limited list of magics to check 
if it has decrypted correctly a deleted file : 
https://code.google.com/p/iphone-dataprotection/source/browse/python_scripts/hfs
/journal.py#58

you can try this modification to improve the results :
http://books.google.fr/books?id=2D50GNA1ULsC&lpg=PA143&ots=YPUQ6yJhvF&dq=isDecry
ptedCorrectly&hl=fr&pg=PA143#v=onepage&q=isDecryptedCorrectly&f=false

Original comment by jean.sig...@gmail.com on 1 Jul 2013 at 7:10

• Changed state: Accepted
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

You're my hero! :D

Thank you Mr. Sigwald, you totally made my day. I had only come across the 
knownExtensions stuff in carver.py (useless for this purpose), but missed this.

I'll probably add the file signatures I need by hand, although Zdziarski's way 
is nice too. And now, I must play with your code :)

Thx again!

Original comment by p...@lgomez.es on 2 Jul 2013 at 5:11

• Added labels: ****
• Removed labels: ****