Issue with irestore stopping after the same file name.

dunhamsteve / ios

Utility to extract files and keychain information from iOS backups

Other

123 stars 28 forks source link

Issue with irestore stopping after the same file name. #18

Open jkerschner opened 2 years ago

jkerschner commented 2 years ago

It appears irestore stops after it reaches a certain point. I've looked at limits and they are set to unlimited. Here is my config:

Ubuntu 22.04.1 16GB ram 1TB filesystem

Please let me know if you need more information.

Thanks in advance!

dunhamsteve commented 2 years ago

Was there any sort of error message? Did it write out the last file that it listed, and if not was there anything weird about the name? My best guess is that there was something weird about the file it was trying to write and it bailed. (Either the data or the file name.) I would hope I'm reporting all errors, but that might not be the case.

jkerschner commented 2 years ago

Thanks for the fast response!

There are several errors while it's running a restore of the CameraRollDomain. I'm trying to get all of the pictures and videos from this encrypted backup. I'm going to attach all of the output with the password changed to xx. Also, it did write the last file and the name of the file is the last line of the text file. Restore CameraRollDomain.txt

dunhamsteve commented 2 years ago

I see a lot of errors about files missing from the backup. I'm on a mac and don't have a recent enough libimobiledevice to test further. So I'm not sure why. A few possibilities:

The backup was copied from another machine and files were left out.
The backup was incremental and assumed those files were already there. (If you still have the device, it looks like idevicebackup2 has a --full option that would help with this. I believe the phone keeps track of what has changed since the last backup and only sends those files.)
Some bug in idevicebackup2 is leaving out files.

One example is: Library/Application Support/MobileSync/Backup/68cd52465e04fd7d307c11d8afa6e18594a8815d/e7/e75599ab8ad3db2d4fed5499dc1d48a21157d9ac

These are files that the backup manifest says should be there, but weren't found on the filesystem.

jkerschner commented 2 years ago

This was a full itunes encrypted backup performed by a Windows 10 OS. I used filezilla to transfer it to my Ububtu machine., because I couldn't unlock the backup. So I used Hashcat to confirm the password was what I thought it was.

When I performed the copy, if filezilla using sftp didn't copy a file or directory over it would have shown in the failed tab. I also just verified the file and directory count between windows and Ubuntu and both are the same.

Sadly, I no longer have the device I only have the backup from it.

One other note. I tried the restore all via "restore '*'" and it stops on the last file as the CameraRollDomain.

dunhamsteve commented 2 years ago

Do you have a file named b2e391f21b59b910524ac3b5b0ca720eb4556ccb and what size is it?

I don't have a repro of a crash (with no error), but the program does wedge if there is a zero length file. If that is the case, removing the zero length files should fix the issue. The encrypted files are never zero length, but it is a bug that irestore doesn't handle them gracefully.

jkerschner commented 2 years ago

I searched for that file and it doesn't exist. I also searched for zero length files and there are none. So I'm at a loss why the backup is reporting these files existed.