Dynamic Report Data Types

[JamesHabben]

Dynamic Report Data Types

[abrignoni]

Those are features folks been asking about for a long while. Color me fully convinced.

[JamesHabben]

added a search filter to the menu sidebar

so @abrignoni are you convinced of moving to react now? :)

[JamesHabben]

added distance and location to consider.

[JamesHabben]

could be a dynamic type to parse json strings into tree structure. this came from the apple wallet in josh's public image

[JamesHabben]

option for duration that takes some time based input and converts to 1h 23m 45s with a popover of other breakdowns. this is from biomeIntents

[JamesHabben]

@Johann-PLW I see you adding some cool stuff to a few modules in a similar line to this. specifically caught an openmaps link going in calendarAll. check this out and let me know your thoughts.

the code is all in my fork on a branch called dynamicreporttimestamps and you can see it here: https://github.com/JamesHabben/iLEAPP/tree/dynamicreporttimestamps

i created a sub branch (not published yet) to work the large data set adjustments back into this dynamic reports branch.

[Johann-PLW]

The work you did with the HTML report is awesome.
I like the settings button that allow to select the date and time format and the timezone that dynamically change the HTML content on the fly. The drop down list in GUI was cool but difficult to choose the correct timezone if we do not know the device settings.
It would be cool if we could generate a tooltip with an openstreetmap thumbnail for gps coordinates as you did for timestamps.
Awesome work.

[JamesHabben]

I am thinking that a location piece of information could feed in from various formats and all feed into a popover that displays various conversions, such as address to lat/long and the opposite.

Here are some formats we can include:

1.	Degrees: 38.8977° N, 77.0365° W
2.	Degrees, Minutes, Seconds (DMS): 38° 53’ 52’’ N, 77° 2’ 11.4’’ W
3.	Degrees, Minutes (DM): 38° 53.862’ N, 77° 2.19’ W
4.	UTM (Universal Transverse Mercator): 18S UJ 22816 43134
5.	MGRS (Military Grid Reference System): 18SUJ2281643134
6.	Maidenhead Locator System: FM18lw
7.	What3Words: ///flags.lawn.chair
8.	Open Location Code (Plus Code): 87C4VX7Q+V8
9.	Elevation: Approximately 16 meters above sea level
10.	Time Zone: Eastern Standard Time (EST)
11.	Postal Address: 1600 Pennsylvania Ave NW, Washington, DC 20500, USA

This would all populate in a popover from an info icon. Then an additional icon can appear next to a designated location that can popover a map preview.

I am pretty sure these will require internet access to convert and the map preview definitely will. We will have to be careful to have graceful degradation for users without internet.

[JamesHabben]

For the timezone list, do you have thoughts or suggestions to make it easier? @Johann-PLW

[Johann-PLW]

@JamesHabben
In the HTML Report, it's perfect as you can obtain the device settings in the HTML report, choose the correct timezone and you don't have to process the extraction again to convert from UTC to the chosen one. I also appreciate that you can type some letters and the list reduces to only display the related timezones.
From the GUI, I think when we click the process button, we would need to execute a dedicated parser as iLEAPP already does for iTunes backup with iTunesBackupInfo and for FFS with lastBuildsInfo to get the iOS version. Then, when we get the timezone setting of the device, we could provide the info to the user and let them choose the correct one before to process the extraction.

[JamesHabben]

Ah, I haven't worked in the GUI side yet. Really, with this change on the reporting side there isn't a need to collect timezone information prior to processing. Do you disagree?

During Python processing, we could have a module extract the timezone information and write it as a value in the report settings somewhere. Then on the report display settings page we could provide a quick tap for 3 options of the timezone: 1) UTC 2) device 3) local to user browser. If user wants to use a different timezone than those 3, then use the long dropdown list.

@Johann-PLW

[Johann-PLW]

@JamesHabben
I agree with you. Il we can adjust the timezone into the settings of the HTML report, we don't need to collect it before processing the data.
Your idea to write it as a value somewhere in the report settings and the quick tap for 3 timezone options are great.

@abrignoni
Do you plan to remove the timezone offset from the GUI?

[JamesHabben]

Just had another thought regarding the TSV output. Currently Python is creating it during processing. With the shift of timezone adjustment moving to the report display, the TSV in my fork has gone to dropping dates in UTC only. Without prompting the user prior to processing, we have to make an assumption or a choice. I think we could have JavaScript generate the TSV file and give it to the user as a "download" from the report. With this approach, we could actually give the user some options prior to prepping the TSV download, such as timezone to apply, column list, all records or only shown from the filter, and anything else you can think of. Could even drop in 2 columns for every date object: "col name (UTC)" and "col data (adjusted)".

Of course, we can leave a checkbox/param in Python to output all module TSV for any users who have that as a part of their normal flow. We don't need to remove features 😀

I will do some testing on this to see if it's a reasonable thing to accomplish in the browser. I'm most concerned with the large data sets we are discussing in the other issue thread. The small data sets wouldn't be a problem to take this approach.

[abrignoni]

If the HTML report datetime solution works it can take the place of the current implementation. I am all for whatever makes the tool easier and better for everyone. Thank you both for thinking through these issues. It is really good stuff.

…

On Wed, Nov 15, 2023, 12:34 PM Johann POLEWCZYK ***@***.***> wrote: @JamesHabben <https://github.com/JamesHabben> I agree with you. Il we can adjust the timezone into the settings of the HTML report, we don't need to collect it before processing the data. Your idea to write it as a value somewhere in the report settings and the quick tap for 3 timezone options are great. @abrignoni <https://github.com/abrignoni> Do you plan to remove the timezone offset from the GUI? — Reply to this email directly, view it on GitHub <#587 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG3DPC4C2KCAUN2ZDRHKOXLYET4KHAVCNFSM6AAAAAA6WIHQL6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJSHE3TCMZZGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[abrignoni]

I think @JamesHabben is on point. If the Javascript can solve the TSV (heck let's make it a proper CVS while we are at it) issue then great. If not keep the current time offset system (or some form of it) for the TSVs.

[JamesHabben]

The more we are talking through these things, the more I am convincing myself that we would really benefit from building this report out as a static/local web app. React is a JavaScript component library that would make this user experience a ton better. It's what I used for my 4n6 app finder project. This shifts the duties around some and would make the Python portion a lot easier to build and manage as well. Essentially, Python would be focused on processing the artifacts into data output files. Then the react app would read in the data files written by Python. Python would no longer need to assemble any html files, manage html or JavaScript code, or patch it all together.

Python:

• Copy over react app, similar to current elements copy
• write initial data details json file. Think about things like file path of data source and such.
• pop open react app before running modules
• update json file as each module finishes with report category, navigation item name, data file path, etc
• update json when all finished to show processing is complete

React:

• Read data json and determine if python is processing or not. Display status.
• Get list of finished modules to build left side nav panel
• Continue checking for processing status. Don't think we can get to monitoring the console output or log file, but could be a cool feature to pop that open in the browser.
• Populate new modules to nav bar for user to view while Python continues processing in the background

Im pretty sure we can make this shift without impacting how any of the artifact modules are coded since the html work is all done in xLEAPP lib code. Basically we just dump out TSV type data in json and skip the html output. Let react read it in and populate.

This would really improve developing reporting features since it would essentially be a standalone app that just reads in data. React also has a ton of component libraries to make the user experience even better. It also gives the ability for a module dev to easily (if they know react) build a display component specifically for their module output, such as charts, graphs or other visualizations. The Ant library has some components that could make the app layout screens look pretty nice. Might be able to build in better searching and filtering as well. I'm thinking something like a global keyword search could be pretty cool.

Thoughts? @abrignoni @Johann-PLW maybe @stark4n6

[JamesHabben]

The more we are talking through these things, the more I am convincing myself that we would really benefit from building this report out as a static/local web app. React is a JavaScript component library that would make this user experience a ton better. It's what I used for my 4n6 app finder project. This shifts the duties around some and would make the Python portion a lot easier to build and manage as well. Essentially, Python would be focused on processing the artifacts into data output files. Then the react app would read in the data files written by Python. Python would no longer need to assemble any html files, manage html or JavaScript code, or patch it all together.

Python:

• Copy over react app, similar to current elements copy
• write initial data details json file. Think about things like file path of data source and such.
• pop open react app before running modules
• update json file as each module finishes with report category, navigation item name, data file path, etc
• update json when all finished to show processing is complete

React:

• Read data json and determine if python is processing or not. Display status.
• Get list of finished modules to build left side nav panel
• Continue checking for processing status. Don't think we can get to monitoring the console output or log file, but could be a cool feature to pop that open in the browser.
• Populate new modules to nav bar for user to view while Python continues processing in the background

Im pretty sure we can make this shift without impacting how any of the artifact modules are coded since the html work is all done in xLEAPP lib code. Basically we just dump out TSV type data in json and skip the html output. Let react read it in and populate.

This would really improve developing reporting features since it would essentially be a standalone app that just reads in data. React also has a ton of component libraries to make the user experience even better. It also gives the ability for a module dev to easily (if they know react) build a display component specifically for their module output, such as charts, graphs or other visualizations. The Ant library has some components that could make the app layout screens look pretty nice. Might be able to build in better searching and filtering as well. I'm thinking something like a global keyword search could be pretty cool.

Thoughts? @abrignoni @Johann-PLW maybe @stark4n6

[stark4n6]

The more we are talking through these things, the more I am convincing myself that we would really benefit from building this report out as a static/local web app. React is a JavaScript component library that would make this user experience a ton better. It's what I used for my 4n6 app finder project. This shifts the duties around some and would make the Python portion a lot easier to build and manage as well. Essentially, Python would be focused on processing the artifacts into data output files. Then the react app would read in the data files written by Python. Python would no longer need to assemble any html files, manage html or JavaScript code, or patch it all together.

Python:

• Copy over react app, similar to current elements copy
• write initial data details json file. Think about things like file path of data source and such.
• pop open react app before running modules
• update json file as each module finishes with report category, navigation item name, data file path, etc
• update json when all finished to show processing is complete

React:

• Read data json and determine if python is processing or not. Display status.
• Get list of finished modules to build left side nav panel
• Continue checking for processing status. Don't think we can get to monitoring the console output or log file, but could be a cool feature to pop that open in the browser.
• Populate new modules to nav bar for user to view while Python continues processing in the background

Im pretty sure we can make this shift without impacting how any of the artifact modules are coded since the html work is all done in xLEAPP lib code. Basically we just dump out TSV type data in json and skip the html output. Let react read it in and populate.

This would really improve developing reporting features since it would essentially be a standalone app that just reads in data. React also has a ton of component libraries to make the user experience even better. It also gives the ability for a module dev to easily (if they know react) build a display component specifically for their module output, such as charts, graphs or other visualizations. The Ant library has some components that could make the app layout screens look pretty nice. Might be able to build in better searching and filtering as well. I'm thinking something like a global keyword search could be pretty cool.

Thoughts? @abrignoni @Johann-PLW maybe @stark4n6

I like the idea of this all, I just don't know a single thing about React at this point so I don't think I'd be able to help much. But I'm open to testing and whatever I can do to help progress the tools.

[abrignoni]

I'll be honest, I know no Javascript and have no idea how react works. If we move this way I think my ignorance would not make me a good steward of the project at that point. Since I don't know react I have no idea how much or how less complexity it would add to the project in regards to how the users would go about running it or me trying to maintain it. The main reasons for xLEAPPs are: - Make it easier for a beginner to code their own artifacts using them. - Handle basic reporting for these begginer to medium experienced coders. - Be mostly python based since it is the defacto coding language for the Digital Forensics field. - The moto is keep it simple. Don't get me wrong, conceptually the changes sound great and I like them. I am all for adding these improvements. I'm worried my ignorance will stall the project when knowledgeable folks like yourselves move on to other projects or responsibilities as life tends to do to us all. Thoughts?

…

On Wed, Nov 15, 2023, 1:44 PM James Habben ***@***.***> wrote: The more we are talking through these things, the more I am convincing myself that we would really benefit from building this report out as a static/local web app. React is a JavaScript component library that would make this user experience a ton better. It's what I used for my 4n6 app finder project. This shifts the duties around some and would make the Python portion a lot easier to build and manage as well. Essentially, Python would be focused on processing the artifacts into data output files. Then the react app would read in the data files written by Python. Python would no longer need to assemble any html files, manage html or JavaScript code, or patch it all together. Python: - Copy over react app, similar to current elements copy - write initial data details json file. Think about things like file path of data source and such. - pop open react app before running modules - update json file as each module finishes with report category, navigation item name, data file path, etc - update json when all finished to show processing is complete React: - Read data json and determine if python is processing or not. Display status. - Get list of finished modules to build left side nav panel - Continue checking for processing status. Don't think we can get to monitoring the console output or log file, but could be a cool feature to pop that open in the browser. - Populate new modules to nav bar for user to view while Python continues processing in the background Im pretty sure we can make this shift without impacting how any of the artifact modules are coded since the html work is all done in xLEAPP lib code. Basically we just dump out TSV type data in json and skip the html output. Let react read it in and populate. This would really improve developing reporting features since it would essentially be a standalone app that just reads in data. React also has a ton of component libraries to make the user experience even better. It also gives the ability for a module dev to easily (if they know react) build a display component specifically for their module output, such as charts, graphs or other visualizations. The Ant library has some components that could make the app layout screens look pretty nice. Might be able to build in better searching and filtering as well. I'm thinking something like a global keyword search could be pretty cool. Thoughts? @abrignoni <https://github.com/abrignoni> @Johann-PLW <https://github.com/Johann-PLW> maybe @stark4n6 <https://github.com/stark4n6> — Reply to this email directly, view it on GitHub <#587 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG3DPC76OJ5HHGUNV2TBPKLYEUEPHAVCNFSM6AAAAAA6WIHQL6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJTGA3TGMBZG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[JamesHabben]

@abrignoni I absolutely understand and agree with your concerns. I don't plan to abandon this project as it's a great mission and it's fun getting my old dusty dev fingers back into coding. But as you said life happens, and none of us can control that.

React is built with JavaScript, so it's pretty familiar when looking at react code, though react has some complexities in structuring the code that can be an initial put off. It took me a longer time than I really liked to get over the hump of learning react. Interesting thing though, is that it takes a more modular approach than JavaScript alone typically structures, so in a way you might find react easier to read and maintain as it feels more like Python than it does JavaScript. It puts an abstraction layer between the functional code and the mechanical levers of interactions in the browser.

[abrignoni]

@JamesHabben Thanks for the explanations. Super useful. Also thank you for your interest in continuing supporting these projects. If you want to take lead on exploring this React alternative please do. As you move forward I will start looking into learning Javascript. If you have any resources I could reference please let me know. But lets finish the date time stuff first. LOL!

@Johann-PLW Thanks for all the cool stuff you are adding to iLEAPP. Think you could port some that are applicable to the other LEAPPs? (ALEAPP, VLEAPP, RLEAPP)

[JamesHabben]

rough first pass, and it loads super quick on even the heart rate module.

took a bit more work than i initially expected, but still not all that much.

this is using the Ant Design library for layout and components. lots of cool options to play with.
https://ant.design/components/table

[abrignoni]

The drop-downs are such a useful and sick addition. And the search option by column are magnificent. This is wild. It easily competes with 3rd party tool reporting. Wow.

[Johann-PLW]

Waouw.
@JamesHabben you did an amazing job. The new report features look like amazing.
I had already put React on my list of development skills to learn but I need to move it in the top position.
I look forward testing this new features, especially with my large Health records dataset.

[abrignoni]

@JamesHabben @Johann-PLW
If you all have some favorite resources to learn Javascript and React send them my way. 😁

[Johann-PLW]

I have already bought this course I haven’t started yet:

• React - The Complete Guide 2023 (incl. React Router & Redux) from Academind available on Udemy
  But maybe @JamesHabben has better to share.

[JamesHabben]

unfortunately, i have known javascript for what feels like forever and dont have any resources other than google, stack overflow, and chatgpt. i struggled with react because all the tutorials i found were doing too basic of stuff and i had grander ideas in my mind, so kinda back to the same google, stack overflow, and chatgpt.

by the way, got a date range custom filter on marked datetime or date columns

filtering is still struggling a bit with the larger data sets, so i have to work through some more options there.

[stark4n6]

This looks so slick

[stark4n6]

Are we still using Feather Icons for the React version of reporting? If so maybe we should look at Lucide which appears to be a bit more supported going forward, I know they have React capabilities but I don't know how tough it would be to make the switch.

https://github.com/lucide-icons/lucide

I had brought it up to @abrignoni yesterday.

[JamesHabben]

@stark4n6 @abrignoni the formatting and layout library i have been building with (AntD) has its own icons, but it's not as broad as feather. feather has a react component though, and i have it integrated for some parts already on my in progress version. havent been able to get as much time lately, but will get the feather icons onto the reports - unless you think lucide is the better route?

[abrignoni]

@stark4n6 @JamesHabben I'm all for whatever icon set has the most assuming it is not a pain to implement.

@JamesHabben I have been studying javascript for the last few weeks. I'm no expert but i know enough to understand what I am reading. If you want to move forward (as time permits) with the new reporting format let me know. I'm starting a React book next week. :-)

[Johann-PLW]

@abrignoni Do you plan to create a DFIR JS/React Study Group on YouTube as you did for Python in 2020? :-)

[abrignoni]

😂 😂 😂 Not yet by a lot. 😂 🤣 😂

…

On Thu, Dec 14, 2023, 3:20 AM Johann POLEWCZYK ***@***.***> wrote: @abrignoni <https://github.com/abrignoni> Do you plan to create a DFIR JS/React Study Group on YouTube as you did for Python in 2020? :-) — Reply to this email directly, view it on GitHub <#587 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG3DPCYSEI35JM43LUHSCXLYJKZGNAVCNFSM6AAAAAA6WIHQL6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJVGM4DIOBYGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>