View Single Post
Old 11-11-2014, 03:33 PM   #109
ShellShock
Wizard
ShellShock ought to be getting tired of karma fortunes by now.ShellShock ought to be getting tired of karma fortunes by now.ShellShock ought to be getting tired of karma fortunes by now.ShellShock ought to be getting tired of karma fortunes by now.ShellShock ought to be getting tired of karma fortunes by now.ShellShock ought to be getting tired of karma fortunes by now.ShellShock ought to be getting tired of karma fortunes by now.ShellShock ought to be getting tired of karma fortunes by now.ShellShock ought to be getting tired of karma fortunes by now.ShellShock ought to be getting tired of karma fortunes by now.ShellShock ought to be getting tired of karma fortunes by now.
 
ShellShock's Avatar
 
Posts: 1,178
Karma: 2431850
Join Date: Sep 2008
Device: IPad Mini 2 Retina
Actually, I think I have just proven #3:
  1. I used iMazing to copy a known good Marvin database from the device to my PC.
  2. Then used SQLLite expert to add 10000 records to the Books table in the PC copy of the database.
  3. Then used IMazing to copy the bulk database back to the device with a different file name. This database will not be touched by Marvin, as it does not have the normal Marvin database file name.
  4. Then used IMazing to copy the bulk database from the device back to the PC.
  5. Used WinMerge to compare 2 to 4. Files are identical. This proves I can rely on IMazing to copy the binary file.
  6. I hacked the IOS reader plugin to download my bulk database as well as the normal Marvin database.
  7. Compared 4 to 6 - files are different.
  8. Opened 6 in Sql Lite expert and tried to execute select on Books table - database disk image is malformed error!

Conclusion: there is a bug in the download of the database file so that it is not producing an accurate copy. I suspect the libimobiledevice library which I am supporting. Now I can repro the bug at will, I have a much better chance of fixing it.

Edit: I can see from the log that libimobiledevice is only reading the first 4194304 bytes, which is 400000 in hex. What a nice round number that is! The rest of the file (up to the original size of the remote file) is null bytes. Ouch.

Edit2: I think I know exactly where the bug is now, and have a pretty good idea how to fix it. But this will have to wait until tomorrow...

Last edited by ShellShock; 11-11-2014 at 05:32 PM.
ShellShock is offline   Reply With Quote