hackappcom / iloot

OpenSource tool for iCloud backup extraction
https://hackapp.com/
637 stars 201 forks source link

chunk decryption failed - session timeout #35

Open iainmeikle opened 9 years ago

iainmeikle commented 9 years ago

With particularly large backups running on slow hardware the error "chunk decryption failed" arises after around an hour. This is due to the fact that the URI used at iloot:289 (container.host_info.uri) contains session timeout attributes (se and st). When the session times out that data passed to decrypt_chunk is XML session error information which obviously will not decrypt. The session timeout seems to be one hour. As decryption is interspersed within download, both download and decryption must complete within one hour. This might be averted if data was first downloaded and then decrypted afterwards. Obviously the likelihood that this will be achieved on limited spec hardware or using slow connections is significant. I am running using an old laptop with ~1GHz single core processor and 2GB RAM. Backup size of ~5GB.

danzek commented 9 years ago

I have encountered this same issue with a 10GB backup.

danjng commented 9 years ago

Any ideas on this one yet? The script is pretty much non-functional for me.

I have a 16GB backup and it's dying after an hour. Suggestions? Is there a way we can manually set or disable the timeout?

danjng commented 9 years ago

I'm getting a lot of chunk decryption failures. Does that typically mean the entire backup is hosed and I should start over?

I tried setting an individual HTTPS timeout of 5 minutes to see if that would make any difference. Any insight on what the default timeout typically is?

danjng commented 9 years ago

So 5 minutes did nothing; will try 'None' to see what happens.

I'm getting this at the end just after a whole mess of chunk description failures:

chunk decryption Failed Traceback (most recent call last): File "iloot.py", line 649, in download_backup(args.apple_id, args.password, args.output, args.item_types, args.snapshot, args.combined, args.itunes_style, args.domain, args.threads) File "iloot.py", line 610, in download_backup client.download(UDID, types) File "iloot.py", line 491, in download self.write_manifest_mbdb(snapshot) File "iloot.py", line 548, in write_manifest_mbdb mbdb_file.write( file.RelativePath ) UnicodeEncodeError: 'ascii' codec can't encode characters in position 72-73: ordinal not in range(128)

Is this the same as what everyone else gets? Or is this a result of the failed chunk decryption?

iainmeikle commented 9 years ago

It is possible to work around the issue temporarily by modifying the code to start at a particular index. Hard code the initial value to zero, increment the index for each chunk as expected, print the index each time. When the script fails, change the hard coded start index to the index on which the script failed. Run the script again until it fails. Repeat until you have managed to complete everything. Laborious but a possible workaround. I might consider fixing this at some point depending on the licensing conditions but I am tight for time presently. With luck someone else with time will do it.

danjng commented 9 years ago

That's definitely good to know. Although I'm not sure how good it would do since all of the errors don't just come at the end and bomb out or something. They happen seemingly randomly.

So just to update anyone who cares, setting that timeout=None doesn't seem to do much. I still get a ton of the decryption failure messages.

For some reason when I modified the types to only pull photos and videos, it actually completed a run (but with decryption errors). Compared to before, I got a lot more files, but did notice that there were some missing, that I was able to pull from a previous failed run. It doesn't seem like these failures are very consistent.