Open GoogleCodeExporter opened 8 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:
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
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:
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
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
closing old issues
Original comment by jean.sig...@gmail.com
on 11 Feb 2014 at 10:38
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
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
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
Issue 129 has been merged into this issue.
Original comment by jean.sig...@gmail.com
on 23 Feb 2014 at 10:55
@jimmyvluv4u you can post here, thanks.
Original comment by jean.sig...@gmail.com
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 jimmyvlu...@gmail.com
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 jean.sig...@gmail.com
on 24 Mar 2014 at 6:31
Attachments:
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
Original issue reported on code.google.com by
kay...@gmail.com
on 15 Feb 2013 at 8:52