iphone-dataprotection
iphone-dataprotection copied to clipboard
Published
20 hours ago •
nabla-c0d3
nabla-c0d3
Two consecutive acquisitions resulted in two different SHA-1 values
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 [email protected] on 15 Feb 2013 at 8:52
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 [email protected] on 15 Feb 2013 at 9:48
- Changed state: Accepted
Attachments:
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 [email protected] on 15 Feb 2013 at 3:32
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 [email protected] on 15 Feb 2013 at 4:21
Attachments:
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 [email protected] on 15 Feb 2013 at 5:05
I tested it and the two acquisitions got the same hash values.
Thank you very much for fixing this!
Original comment by [email protected] on 18 Feb 2013 at 4:25
closing old issues
Original comment by [email protected] on 11 Feb 2014 at 10:38
- Changed state: Done
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 [email protected] on 14 Feb 2014 at 7:01
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 [email protected] on 19 Feb 2014 at 6:09
- Changed state: Accepted
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 [email protected] on 21 Feb 2014 at 10:21
Issue 129 has been merged into this issue.
Original comment by [email protected] on 23 Feb 2014 at 10:55
@jimmyvluv4u you can post here, thanks.
Original comment by [email protected] on 23 Feb 2014 at 10:56
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 [email protected] on 23 Feb 2014 at 2:49
Attachments:
@jimmyvluv4u sorry for the delay, here is a patch that should fix the issue.
thanks.
Original comment by [email protected] on 24 Mar 2014 at 6:31
Attachments:
This issue was updated by revision 54aa3bb349bf.
add missing change from previous commit
Original comment by [email protected] on 2 Apr 2014 at 4:24