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

Artifact Info Structure Update #568

Open
JamesHabben opened this issue Oct 16, 2023 · 15 comments
Open

Artifact Info Structure Update #568

JamesHabben opened this issue Oct 16, 2023 · 15 comments

Comments

@JamesHabben
Copy link
Collaborator

JamesHabben commented Oct 16, 2023 •
edited
Loading

As I have learned more about the structure of this project and how the modules are being developed, I think another update to the artifact structure might help to better organize and document information about the modules and all the individual artifacts they parse. I noticed that most of these modules are 1:1 in the items they add to the report, but there are a few that add multiple items to the report.

Example: Viber Module

In the code, it produces a potential of 4 items in the report based on the existence of certain data, but the artifact structure of the script doesn't give any indication of that since it has only 1 function entry of get_viber in the dictionary.
https://github.com/abrignoni/iLEAPP/blob/ceff9fb87c7f4b675c989eeb74c0dbda250fbbcd/scripts/artifacts/viber.py

Artifact v2 of Viber Module

__artifacts_v2__ = {
    "viber": {
        "name": "Viber Artifacts",
        "description": "Get Viber settings, contacts, recent calls and messages information. This script queries "
					   "Settings.data and Contacts.data Viber dbs and creates a report of findings including KML "
					   "geolocation data. Settings hold the user's personal data and configurations. Contacts hold "
					   "contacts, calls, messages and more.",
        "author": "Evangelos Dragonas (@theAtropos4n6)",
        "version": "0.0.2",
        "date": "2022-03-15",
        "requirements": "",
        "category": "Viber",
        "notes": "The code is divided into 4 queries-artifacts blocks. The 1st parses settings db, extracts and "
				 "reports on user's available information regarding Viber configuration. The 2nd parses contacts db, "
				 "extracts and reports on user's contacts. Be advised that a contact may not participate in a chat ("
				 "therefore a contact is not a chat 'member') and vice versa. A chat 'member' may not be registered as "
				 "a Viber contact. The 3rd parses contacts db, extracts and reports on user's "
				 "recent calls that have no corresponding message (ZVIBERMESSAGE) entry, indicating these messages "
				 "have been deleted. The 4th parses contacts db, extracts and reports on user's chats, including extra "
				 "columns with each chat's grouped participants and phone numbers. More information is stored within "
				 "the above databases, and this artifact assists in parsing the most out of it. ",
        "paths": (
            '**/com.viber/settings/Settings.data',
            '**/com.viber/database/Contacts.data',
            '**/Containers/Data/Application/*/Documents/Attachments/*.*',
            '**/com.viber/ViberIcons/*.*'
        ),
        "function": "get_viber"
    }
}

Artifacts

Search for ArtifactHtmlReport( and you find 4 hits for the 4 items it adds to the report, but no other way to programmatically determine that in current form.

Update

With an updated artifact structure ( maybe __artifact_v3__ ?), the structure could take on a 1 module to many artifact relationship. What I have in mind would require a little restructuring of the code that runs the artifacts though as the framework currently allows for an author to add as many items to the report within an artifact as they feel. Rather, if the report addition in tied to the artifact function and the artifact function is only allowed one instance of a report object, it forces compliance to the information structure.

see https://github.com/abrignoni/iLEAPP/blob/lava-output/admin/docs/artifact_info_block.md for definition

Thoughts?
@JamesHabben
Copy link
Collaborator Author

I've been in javascript too much lately. I suppose the pythonic naming convention is artifact_name rather than artifactName

@abrignoni
Copy link
Owner

abrignoni commented Oct 16, 2023 •
edited
Loading

Your proposal makes absolute sense, it is efficient and well thought out.

My main concern is people power. Any changes will have to be ported to ALEAPP, VLEAPP, & RLEAPP as well.
Currently I am making all artifacts in the LEAPPs timezone aware and it is taking/will take an insane amount of time (months.)

Do you mind giving it a look and gauge the level of difficulty to implement? I'm all for it but if implementing requires a lot of refactoring then I propose we look into implementing it after the timezone offset thing is done.

@JamesHabben
Copy link
Collaborator Author

Ya, I can put some time on it. Is the architecture between these version similar enough to be able to do something like a pull request across repos?

@JamesHabben
Copy link
Collaborator Author

a quick check says its not quite in line.

iLEAPP: 135 lines
https://github.com/abrignoni/iLEAPP/blob/main/scripts/artifact_report.py

aLEAPP: 361 lines
https://github.com/abrignoni/ALEAPP/blob/main/scripts/artifact_report.py

@JamesHabben
Copy link
Collaborator Author

Which tool is your primary? Looks like aLEAPP report code above has additional image, timeline, chat functions that iLEAPP doesn't.

@abrignoni
Copy link
Owner

abrignoni commented Oct 17, 2023 via email

@JamesHabben
Copy link
Collaborator Author

JamesHabben commented Oct 18, 2023 •
edited
Loading

updated to python naming and added report-icon as an option. with that we can reduce (maybe eliminate) the need for that big icon list object in reports.py file by letting plugins set it right here. could be useful in the gui when displaying available modules, although i havent explored the gui much yet.

@abrignoni
Copy link
Owner

As stuff is merged please send some PRs to RLEAPP & VLEAPP as well so they can benefit too. There is no way I can go back and try to port it over myself.

@JamesHabben
Copy link
Collaborator Author

ya i am working my way towards that before getting this new artifact structure in anywhere. need to set a baseline first.

@abrignoni
Copy link
Owner

Please add yourself to all the LEAPPs in the developer section.
thank you so much for this. It is such a leapp forward. I'll walk myself out...

@JamesHabben
Copy link
Collaborator Author

another update to the structure above.

  • changed name to module_name for clarity
  • added app_name to capture name of app this is parsing data from
  • added category_icon to allow for a default icon indication
  • changed report_icon in artifacts to artifact_icon for clarity

@JamesHabben
Copy link
Collaborator Author

added report_warning to the artifact structure. this can be used to automatically display (if it exists) in a colored panel to provide caution to the examiner about the interpretation of any of the data below.

@JamesHabben
Copy link
Collaborator Author

i think we could benefit from having a field that declares if this module is parsing an artifact from a filesystem dump or itunes backup. can certainly better inform users of what they can expect to extract using the module, but it could help in improving processing speed in allowing the script to skip a module or artifact of module if its not processing a data source that it can even extract data from. unsure if this would be better applied at the module or report artifact level.

@abrignoni
Copy link
Owner

abrignoni commented Nov 5, 2023 via email

@JamesHabben
Copy link
Collaborator Author

yup. understood and agree. on the civilian side of this world, we deal almost exclusively with backups or non-FFS extractions. my testing with iLEAPP so far has been with a few icloud or itunes backups and i'm happy to see that many of the modules are finding data to process. i haven't fully thought out what adding a 'data source' type of field in the info structure would look like, but it would certainly help potential users (selfishly, me lol) to know if a module can parse data from a backup or if a FFS is required.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@JamesHabben @abrignoni