Artifact Info Structure Update

[abrignoni]

Artifact Info Structure Update

[JamesHabben]

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

[abrignoni]

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]

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

[abrignoni]

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]

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]

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]

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

[abrignoni]

All have timeline, KML, & tsv functions. Some of the differences between the projects is due to android vs ios quirks and the stuff folks contribute to one project but not used on another.

…

On Tue, Oct 17, 2023, 1:25 PM James Habben ***@***.***> wrote: Which tool is your primary? Looks like aLEAPP report code above has additional image, timeline, chat functions that iLEAPP doesn't. — Reply to this email directly, view it on GitHub <#568 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG3DPC66J7DDMC27QWKB3QLX725RZAVCNFSM6AAAAAA6C26332VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRWHA2TONZRG4> . You are receiving this because you commented.Message ID: ***@***.***>

[JamesHabben]

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]

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]

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]

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]

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]

The tooling was originally designed for full file system parsing. We added iTunes backup as an option for folks to develop specific artifacts for these. Since the backups have so little useful data in comparison to a full file system I have received little to none backup specific artifacts. I think it is a good idea but I'm not sure how much benefit will it provide in the sense that almost all use cases involve full file systems and not backups. As a mater of fact many of the artifacts that find stuff in a backup do so accidentally since the report comes from an artifact originally designed for a full file system. For example some of these FFS artifacts would get more hits on a backup if the paths were fully qualified instead of using the backup domains. Long story short backups haven't been our focus per user population tool usage but I am happy to merge anything that helps any user case as long as the overhead is manageable and does not impacts creating an artifact. It has to be a really necessary change (like making all timestamps datetime objects for your html solution to work) in order to require an artifact creator to abide by a particular rule beyond the current ones. Hope that makes sense.

…

On Sat, Nov 4, 2023, 6:03 PM James Habben ***@***.***> wrote: 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. — Reply to this email directly, view it on GitHub <#568 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG3DPCYAYOPQCWBI4YEB2DDYC23RVAVCNFSM6AAAAAA6C26332VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJTGU3DKNJQGM> . You are receiving this because you commented.Message ID: ***@***.***>

[JamesHabben]

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.