Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

GUI and iTunes Backup Assumption #638

Open
JamesHabben opened this issue Dec 20, 2023 · 12 comments
Open

GUI and iTunes Backup Assumption #638

JamesHabben opened this issue Dec 20, 2023 · 12 comments
Labels
enhancement New feature or request

Comments

@JamesHabben
Copy link
Collaborator

iLEAPP/ileappGUI.py

Lines 110 to 113 in c052c92

elif os.path.isdir(i_path) and os.path.exists(os.path.join(i_path, "Manifest.db")):
ext_type = 'itunes'
elif os.path.isdir(i_path):
ext_type = 'fs'

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
Copy link
Owner

abrignoni commented Dec 20, 2023 via email

@JamesHabben
Copy link
Collaborator Author

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?
image

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
Copy link
Collaborator

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
Copy link
Owner

abrignoni commented Dec 20, 2023 via email

@JamesHabben
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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:
image

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
Copy link
Collaborator Author

@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
Copy link
Collaborator

@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
Copy link
Collaborator Author

@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
Copy link
Owner

abrignoni commented Dec 21, 2023 via email

@JamesHabben
Copy link
Collaborator Author

@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
Copy link
Owner

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.

@JamesHabben JamesHabben added the enhancement New feature or request label Jan 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@JamesHabben @Johann-PLW @abrignoni @stark4n6