GUI and iTunes Backup Assumption

[JamesHabben]

https://github.com/abrignoni/iLEAPP/blob/c052c9255d44f90606eafdd5aa0b330d82c0b833/ileappGUI.py#L110-L113

Tried to run this against an iCloud backup pulled with Elcomsoft Phone Breaker's download backup function. I think it used to provide the files in the hashed structure, but lately its been renaming them to their normal file path. The problem is that it still drops the manifest.db file into the root folder like a normal iTunes backup, and this GUI logic is making everything fail because it can't find the files based on the hash folders and name. Any thoughts on how to adjust this? Maybe a check of the folder in the GUI that then allows a toggle to process as fs or itunes?

[abrignoni]

If you take the manifest.db out does it work?

I'm not sure if it is worthwhile to use limited GUI space for what could be an edge case that could be solved by the user just removing the file from the directory it is in. Thoughts?

On Wed, Dec 20, 2023 at 12:21 PM James Habben @.***> wrote:

https://github.com/abrignoni/iLEAPP/blob/c052c9255d44f90606eafdd5aa0b330d82c0b833/ileappGUI.py#L110-L113

Tried to run this against an iCloud backup pulled with Elcomsoft Phone Breaker's download backup function. I think it used to provide the files in the hashed structure, but lately its been renaming them to their normal file path. The problem is that it still drops the manifest.db file into the root folder like a normal iTunes backup, and this GUI logic is making everything fail because it can't find the files based on the hash folders and name. Any thoughts on how to adjust this? Maybe a check of the folder in the GUI that then allows a toggle to process as fs or itunes?

— Reply to this email directly, view it on GitHub https://github.com/abrignoni/iLEAPP/issues/638, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG3DPC46YOSEOZX4DGD4O7LYKMNDJAVCNFSM6AAAAABA5FJROGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA2TAOJXGU4DQMQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[JamesHabben]

From past discussions, it sounds like most users don't use this against iTunes backups. Maybe its a separate prompt if iTunes backup is detected to ask the user if they want to process as iTunes or files. Otherwise, I wonder if there is a file that is always in the iTunes backup that this could check in addition to the manifest to do an auto switch. Check that path and if it doesn't exist then process as files. Should do something though, because there isn't much sign that this is happening.

Maybe one of these?

I will try rename/delete/move of the manifest.db file to see if that works. I hadn't thought of that yet.

[Johann-PLW]

I did not have the opportunity to have an iCloud backup so I do not know its structure. To answer @JamesHabben's question, in each iTunes backup, you always have these four files: Manifest.db, Manifest.plist, Info.plist and Status.plist We always have the same issue if a user tries to parse an advanced logical extraction performed with UFED touch/4PC. This is mainly an iTunes Backup but encapsulated in a zip archive and iLEAPP tries to parse it as if it was a full file system extraction. I do not wow if @abrignoni has received questions/remarks/complaints about that ... If this is indeed the case, perhaps we could reconsider how to detect the type of extraction provided as input

[abrignoni]

To be honest the artifacts themselves don't support iTunes backups since they have so little useful data compared to full file system extractions. The majority of the user base deals with full file system extractions hence most artifacts have been developed for such.

On Wed, Dec 20, 2023, 3:35 PM Johann POLEWCZYK @.***> wrote:

I did not have the opportunity to have an iCloud backup so I do not know its structure. To answer @JamesHabben https://github.com/JamesHabben's question, in each iTunes backup, you always have these four files: Manifest.db, Manifest.plist, Info.plist and Status.plist We always have the same issue if a user tries to parse an advanced logical extraction performed with UFED touch/4PC. This is mainly an iTunes Backup but encapsulated in a zip archive and iLEAPP tries to parse it as if it was a full file system extraction. I do not wow if @abrignoni https://github.com/abrignoni has received questions/remarks/complaints about that ... If this is indeed the case, perhaps we could reconsider how to detect the type of extraction provided as input

— Reply to this email directly, view it on GitHub https://github.com/abrignoni/iLEAPP/issues/638#issuecomment-1865104388, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG3DPCZW5I5YC3BPFZ5SRQ3YKNDYDAVCNFSM6AAAAABA5FJROGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRVGEYDIMZYHA . You are receiving this because you were mentioned.Message ID: @.***>

[JamesHabben]

To be honest the artifacts themselves don't support iTunes backups since they have so little useful data compared to full file system extractions. The majority of the user base deals with full file system extractions hence most artifacts have been developed for such.

Many of the artifacts do in fact support iTunes backups, and I have been able to extract quite a bit from backups. I think we can actually increase the number of artifacts that support backups with a simple adjustment to the file search patterns. For example, WhatsApp modules target a very specific path to FFS extractions and the current pattern it uses does not locate the same file even though it's there in an iTunes backup collection. With an adjustment or additional search pattern, the WhatsApp modules will easily apply to backups, though I haven't tested that yet.

This can really help to increase the usefulness of the tool and the userbase.

[JamesHabben]

in each iTunes backup, you always have these four files: Manifest.db, Manifest.plist, Info.plist and Status.plist We always have the same issue if a user tries to parse an advanced logical extraction performed with UFED touch/4PC. This is mainly an iTunes Backup but encapsulated in a zip archive and iLEAPP tries to parse it as if it was a full file system extraction.

The standard iTunes backup is unencrypted and contains less useful information than a standard encrypted iTunes backup. The output formats are the same with every file being named as a SHA1 hash of its path. They are all in folders that have 2 characters of the first part of each filename, and the filenames with those characters are contained inside that folder.

The other format that I have seen iTunes/iCloud backups show up in, is where each domain is a folder, and then all the files are written with their actual paths as they would be inside each domain folder on the device. Some of these paths match the path of how they would be extracted in a FFS operation, but will differ in the upper parent level folders from backup to FFS.

The backup I realized this problem with was downloaded from iCloud with the device owners consent using Elcomsoft Phone Breaker. This format has the 4 standard iTunes backup files and includes many of the protected files that normally only come through with an 'encrypted' iTunes backup. Screen shot here:

UFED does an identical extraction to the standard iTunes encrypted backup, with an automatic 1234 password applied. It then captures that collection into their modified ZIP file. iLEAPP will not be able to parse the UFED collection file since the collection files will be encrypted. You would need to extract them and run though one of the iTunes backup decryptor tools.

[JamesHabben]

@abrignoni If you take the manifest.db out does it work? I'm not sure if it is worthwhile to use limited GUI space for what could be an edge case that could be solved by the user just removing the file from the directory it is in. Thoughts?

This worked to bypass the forcing into FFS parsing, and the SMS module I needed to run parsed. I ended getting a good amount of error on the attachment, but I had over 10,000 that were properly extracted. I haven't dug into why some failed and others did not fail. It seems that all the messages were successfully parsed.

[stark4n6]

@JamesHabben have had success with decryption using Jack Farley's script in the past, I know his page hasn't been maintained much the past few years though https://github.com/jfarley248/iTunes_Backup_Reader

[JamesHabben]

@stark4n6 ya I think I have used that one in the past too. Does anyone know him personally? looks like a few PRs to resolve known issues waiting. If not, maybe @abrignoni wants to make a new fork? :)

[abrignoni]

Should I? To be honest I have no idea about anything in the code. Have used it but not read it. LOL!

On Thu, Dec 21, 2023 at 12:45 PM James Habben @.***> wrote:

@stark4n6 https://github.com/stark4n6 ya I think I have used that one in the past too. Does anyone know him personally? looks like a few PRs to resolve known issues waiting. If not, maybe @abrignoni https://github.com/abrignoni wants to make a new fork? :)

— Reply to this email directly, view it on GitHub https://github.com/abrignoni/iLEAPP/issues/638#issuecomment-1866703778, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG3DPCZUMFOSMZ6YYU4JA73YKRYTVAVCNFSM6AAAAABA5FJROGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRWG4YDGNZXHA . You are receiving this because you were mentioned.Message ID: @.***>

[JamesHabben]

@abrignoni Should I? To be honest I have no idea about anything in the code. Have used it but not read it. LOL!

I don't think you need to have a thorough understanding to pick up a fork. You are good at supporting your projects and reviewing pull requests. You could even add other at the collaborator level to help with some of the admin on these projects.

I did a quick search for him, and it seems he stopped (paused?) his open source work when he started at Mandiant/Google.

[abrignoni]

Makes sense. A lot of community contributors lack time when they land a demanding job not directly related to what they put out publically. Totally understandable.