sefischer / iphone-dataprotection

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

Two consecutive acquisitions resulted in two different SHA-1 values #93

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Follow the readme from the beginning till "nand_dump"
2. Without rebooting the iPhone, run another "nand_dump"
3. Compare the SHA-1 of the two dumps

What is the expected output? What do you see instead?
"nand-disable=1" flag was used, I expected there would be no change on the NAND 
flash after the first acquisition and the two SHA-1 values would be identical. 
It turned out they are different: 
SHA1 of 1st dump: a21ce0a3e48a2303b1433679de1fdd8fa02c5bc6
SHA1 of 2nd dump: 8e6d44c3691f270bf9f60fd828140e51cf04ba6b

Comparing the two .bin files, I got 203 differences:
 D15281C:   00  01
 10214E84:  00  01
 1D97D358:  00  01
 3C219D90:  01  00
 479903B8:  01  00
 4F1F74D0:  01  00
 532E5C8C:  01  00
 60A07EA4:  01  00
 62FD37AC:  01  00
 637DE7E8:  00  01
 7AF40898:  00  01
 7AFFF004:  01  00
 7B131BF8:  00  01
 85EBDF38:  01  00
 897D1898:  01  00
 8A398E18:  00  01
 8C920478:  00  01
 8CEB3C18:  01  00
 9D925E10:  00  01
 A0DFCD2C:  01  00
 A1B00F04:  00  01
 A8D2A1D8:  01  00
 A91F91D0:  01  00
 B365F9D0:  00  01
 BE92512C:  01  00
 BFF1EC64:  01  00
 C4E60304:  00  01
 C5425C98:  01  00
 C7143F10:  01  00
 C8413AB8:  00  01
 D313DA24:  01  00
 DB4C3A2C:  00  01
 DD2C4578:  00  01
 E51372E0:  00  01
 F63FC7E4:  00  01
 F72073F8:  00  01
 F86A4198:  01  00
 FEB14B8C:  00  01
 FF7CCA6C:  01  00
101BB90C8:  00  01
104FBF7C4:  01  00
10667FAB8:  00  01
1070F6318:  00  01
10AE8A964:  01  00
1195A8AF0:  01  00
11A25696C:  01  00
122D0B118:  01  00
125866198:  01  00
12A201FE4:  00  01
12F99C9CC:  00  01
1306B0C44:  01  00
131A4CFE4:  01  00
137E1B384:  00  01
13D499254:  00  01
144C0B9E4:  01  00
14BE26C2C:  00  01
14C0521D0:  01  00
1618E8F50:  00  01
165874938:  01  00
169791ED4:  01  00
16D7B3E98:  00  01
170D756D8:  00  01
17373B790:  00  01
17C386F18:  00  01
17F4F7C4C:  00  01
18193E62C:  00  01
1828B6078:  00  01
183499710:  01  00
184205CF8:  01  00
1854CF864:  00  01
186B518EC:  00  01
18D0FEF38:  01  00
18E028678:  00  01
193C3DD10:  00  01
1944B91AC:  00  01
195300018:  01  00
19B01A0D8:  01  00
1A8E44918:  01  00
1AB1BAAD8:  01  00
1AB7D87DC:  00  01
1AF715EB8:  01  00
1B02F1500:  01  00
1C54ADE24:  01  00
1C76F5418:  01  00
1CC073138:  01  00
1DA6D2B58:  00  01
1DB74AFA4:  01  00
1DC060A44:  01  00
1DFB3954C:  01  00
1E13A28D0:  01  00
1E93AA600:  00  01
1EB9DA2F0:  00  01
1ECCB5F10:  01  00
1EDBAF470:  01  00
1F29F2124:  01  00
1FB11A56C:  00  01
204BAAB4C:  01  00
209C3CF0C:  00  01
20DE6630C:  00  01
2128E4A2C:  00  01
213D314AC:  00  01
218371174:  01  00
218D332CC:  00  01
21A5CC830:  01  00
21B6AD08C:  00  01
21BB2FD8C:  00  01
21C8741E4:  00  01
21F5D2678:  00  01
2237BB7F8:  01  00
2277A558C:  01  00
2295C21F0:  01  00
229C7C50C:  01  00
22C6E2C04:  00  01
22C801730:  01  00
231930108:  01  00
231EDD9AC:  01  00
2373604B8:  00  01
2406A61DC:  01  00
2414308F0:  00  01
242D724E4:  00  01
24B87AFD8:  01  00
24DE56980:  01  00
25598D6A4:  01  00
256DB9FE4:  00  01
2590E1E98:  01  00
25B5B8E18:  01  00
261753BC4:  00  01
2664F824C:  00  01
268E29D3C:  00  01
269749840:  01  00
26B548378:  00  01
26D0B34FC:  00  01
271CF8DD8:  01  00
2773EB130:  00  01
27930E7D0:  00  01
284D56A18:  01  00
29122D5B0:  01  00
2987163F0:  01  00
29E677B6C:  01  00
29F361C40:  01  00
2A19C7B4C:  01  00
2A9446140:  00  01
2AB6CD9B4:  00  01
2ACFB7238:  01  00
2BB73F7E8:  01  00
2BE314D2C:  00  01
2BF49DC18:  00  01
2C3AB7764:  00  01
2C5046E78:  00  01
2CA008A18:  00  01
2CBB77BC4:  00  01
2CD80D8EC:  00  01
2CDB0D6D8:  01  00
2CEAB932C:  01  00
2DAE8D4B0:  01  00
2DBCCC2CC:  01  00
2E4929B08:  01  00
2E70AA518:  01  00
2EE07A07C:  01  00
2F148A7DC:  01  00
2F3502BC4:  00  01
2F5FF180C:  01  00
2F9B467EC:  00  01
2FC67F718:  00  01
2FCA31BF8:  01  00
2FE7CC348:  00  01
300437ECC:  00  01
304A318D8:  00  01
3050A3924:  01  00
312C206AC:  00  01
313DB9638:  00  01
317E0F804:  01  00
31BF9C5EC:  00  01
31FBF8008:  00  01
321CB66AC:  00  01
32E6C464C:  00  01
33B323D0C:  01  00
34965D7C4:  01  00
35484E6D8:  01  00
35D435A78:  00  01
369E7DC5C:  01  00
36A5DE5F4:  00  01
371C60424:  01  00
3726285B8:  01  00
3788E3EA4:  01  00
37FAEB024:  00  01
3817ED184:  00  01
384E2EEC4:  00  01
3921E6ECC:  01  00
39494D7D8:  01  00
398F57284:  00  01
39C4D07F4:  00  01
3A013E2C4:  01  00
3A5777EEC:  00  01
3A7EFE938:  00  01
3AC53C5EC:  01  00
3B800AD70:  01  00
3BBEF6118:  00  01
3BC707190:  00  01
3C4370AA8:  00  01
3C71E19F0:  01  00
3C7C5A264:  01  00
3D9F7DAB0:  01  00

What version of the product are you using? On what operating system?
OS X version : 10.7.4
XCode version : 4.3
Tools revision : e57806d960f7+ tip

I would be very grateful if you can look into this matter. 
Thank you very much.

Original issue reported on code.google.com by kay...@gmail.com on 15 Feb 2013 at 8:52

GoogleCodeExporter commented 9 years ago
ok, now i remember this issue. the differences are in the return codes from the 
nand driver that are stored after each page in the dump. each page is written 
in the following format :
page data (usually 8192 bytes) + spare area (12 bytes) + iokit return code (4 
bytes) + other return code (4 bytes)

i assume the "dumpedPageSize" in your plist file is set to 8212 (8192+12+8). 
with that assumption i verified that each of the offsets you posted are in fact 
the offsets of the first byte of the "other return code" value.

When we read a page through the kernel driver, there are two return codes : the 
first one is a standard iokit return code, that can be used to check if a page 
is blank or not (kIOReturnUnformattedMedia). To be honest i don't know yet what 
the second return code is for, but i now remember that i encountered the same 
issue as you when testing. Maybe it indicates the "number of errors corrected 
while reading the page" but i have to clear this out. 

So i guess it was a bad idea to include this in the dump, because even if there 
is no difference in the actual data (page data + spare), the second return code 
seems to change from one acquisition to another. I'll probably change the dump 
format in a future update to remove this.

Thanks a lot for reporting this.

Original comment by jean.sig...@gmail.com on 15 Feb 2013 at 9:48

Attachments:

GoogleCodeExporter commented 9 years ago
Thanks a lot for your prompt reply and detailed explanation!

I need this new version (getting identical dumps every time) for a task.
Is it difficult to change the dump format? I'm not familiar with python,
do you think I can try making the change myself? Grateful if you can give
me some hints.

Thanks for your help again.

Original comment by kay...@gmail.com on 15 Feb 2013 at 3:32

GoogleCodeExporter commented 9 years ago
ok, i just rechecked and this is indeed the "bitflip count", the number of bits 
that were corrected when reading.
Attached is a patch for the dumper that clears this value before returning the 
page data to the host. You'll need to recompile and rebuild the ramdisk with 
the patched version. Let me know if this gives the expected result.
Thanks.

Original comment by jean.sig...@gmail.com on 15 Feb 2013 at 4:21

Attachments:

GoogleCodeExporter commented 9 years ago
Wonderful!!

The phone is not with me this weekend. Will try it out on Monday and let you 
know the result. A big THANK YOU!

Original comment by kay...@gmail.com on 15 Feb 2013 at 5:05

GoogleCodeExporter commented 9 years ago
I tested it and the two acquisitions got the same hash values. 
Thank you very much for fixing this!

Original comment by kay...@gmail.com on 18 Feb 2013 at 4:25

GoogleCodeExporter commented 9 years ago
closing old issues

Original comment by jean.sig...@gmail.com on 11 Feb 2014 at 10:38

GoogleCodeExporter commented 9 years ago
Sorry to raise an old issue, but I have an iPhone4 that I absolutely cannot get 
to give me NAND dumps with matching hashes.  It does report a significant 
number of pages (8%) with errors, could that be why?  Most of the errors look 
like they were near the beginning and end of the dump.

Original comment by jimmyvlu...@gmail.com on 14 Feb 2014 at 7:01

GoogleCodeExporter commented 9 years ago
i assume you used the latest version and did not reboot between the 
acquisitions ?
could you post a hexdump of the first spot that differs in the images, along 
with the <nand> section of the plist file ? thanks

Original comment by jean.sig...@gmail.com on 19 Feb 2014 at 6:09

GoogleCodeExporter commented 9 years ago
Sorry, I did not see your response to this bug and just posted a new one. Would 
you rather I post in this one or the new one I opened?

Original comment by jimmyvlu...@gmail.com on 21 Feb 2014 at 10:21

GoogleCodeExporter commented 9 years ago
Issue 129 has been merged into this issue.

Original comment by jean.sig...@gmail.com on 23 Feb 2014 at 10:55

GoogleCodeExporter commented 9 years ago
@jimmyvluv4u you can post here, thanks.

Original comment by jean.sig...@gmail.com on 23 Feb 2014 at 10:56

GoogleCodeExporter commented 9 years ago
I attached the first 8K of each dump and the NAND section of the plist.  As you 
will see, starting at 0x600, one of them is (almost) all 0's, while the other 
is random-looking data.  Scanning the entire dumps, there are many other areas 
that match this pattern.  

As another experiment, I tried to open these dumps with ios_examiner and was 
successful.  I then dd-d images out of them and the SHA1 hashes of these images 
matched.  

Original comment by jimmyvlu...@gmail.com on 23 Feb 2014 at 2:49

Attachments:

GoogleCodeExporter commented 9 years ago
@jimmyvluv4u sorry for the delay, here is a patch that should fix the issue. 
thanks.

Original comment by jean.sig...@gmail.com on 24 Mar 2014 at 6:31

Attachments:

GoogleCodeExporter commented 9 years ago
This issue was updated by revision 54aa3bb349bf.

add missing change from previous commit

Original comment by jean.sig...@gmail.com on 2 Apr 2014 at 4:24