IPED
IPED copied to clipboard
User interface to configure options and start processing
A lot of third parties have developed user interfaces to configure and start processing. We have heard about 7 of them, at least. So this is a needed feature, very important for non tech users. It will be needed when additional/post processing is implemented.
Hello, Ifnassif I am taking the IPOG course on computer forence in Porto Alegre, I would like to contribute to this issue, I have been working with Java development since 2001, I had IPED in 2019.
I have a suggestion. Today, if I remember correctly, the application entrypoint calls itself again to load the classpaths, which can be a little confusing. My suggestion is to split this start process in 3: the default one would load the additional classpaths and call the second one, which would create a configuration instance and pass this to the third which would then really start the application. If the only point where the configuration files are read is in the Configuration creation, then this would be done only in the second step, allowing the application to work without the need to access configuration files. This is important to build unit tests in the future because they would create a customized configuration instance and pass it to the third step.
Debug would be easier too.
Hi @JohnAndersonDuarte, thank you very much for your interest in contributing, you will be welcomed! I will talk to 2 third parties that developed UI independently and ask if they are willing to contribute their code, so we do not need to reinvent the wheel and just improve it. I will notice it here.
Hi @atilaromero , yes, that reentrant entry point is confusing and makes debugging difficult. Do you think only 2 steps/entry points would be ok? One for classloading and other for the remaining? I completely agree with loading configuration files just in one place and making unit tests easier to implement. Patrick Bernardina implemented a configuration module refactoring and it could be used for that. Take a look at Configurable and ConfigurationManager classes and tell me what do you think
Oh, I am a little out of date. Yes, that should solve it.
Sent email to 3 UI config authors, waiting response.
Hello, I was a little out of activities.
Great, let's wait, anyway I will download the project and start understanding the source, so I can suggest useful things.
Hi Nassif, i built a UI to configure and launch IPED. It is a JAVA application (you know, it will work on both Windows and Linux, maybe OSX) that currently works with the latest IPED release withou any code modifications. I'm finishing the last tests to release to final users for free, maybe it can help on this topic. If it interest to you, i can show and explain the tool.
Hi @thiagofuer, thank you very much for your interest in contributing! Sure, I would like to take a look at the application and its source, is it available somewhere?
For a possible future integration in 4.0, the configuration files, classes and profiles were refactored a lot, see #18, #120 and #555. We would also need to make the UI localization ready for other languages, not sure if you prepared the UI for this.
Hi everybody, I sent some messages about this feature in our internal Teams channel, please take a look. I would appreciate a lot some feedbacks about an upcoming outside collaboration by @thiagofuer
Hi folks, we are working on a user interface to configure options and start processing. You can check our progress accessing the navigable prototype on Figma. We would appreciate some suggestions. Please leave your's and contribute.
Thank you very much @thiagofuer for helping with this. I would also appreciate a lot opinions from other devs and users before we can proceed with the implementation.
Just to share them with others, my last private suggestions to @thiagofuer were to move the open case/multicase options to first window and to create another 4th left tab to display the important console messages while the processing is going on.
PS: Figma stopped to work in my Chrome installation, but it works in Firefox.
I has made the following layout adjustment on prototype: 1 - Main page: 1.1 - Add a "Open case" button 1.2 - Changed some icons 2 - Process start page: Now the app will display "IPED-SearchApp.exe" right after he be opened 3 - Process finished page: Removed "open multiple case" button (he was moved to maing page)
thats`s all for now
@thiagofuer, just to let you know, regripper and mplayer are being moved to iped/tools folder, so their related params in LocalConfig.txt are being removed, see #331 and #1320
hi folks, how's going? I'm spending some time studying how properly save configuration files changes. The first thing i have saw is about the correctly class to read and manage this config files. The LocalConfigFile.txt is loaded by "Configuration" class as "UTF8Propertie" and also on "ConfigurationManager" class as a "Configurable". So i have some concerns about it, the first is to manage the file propertie change in all his instances. The second is about the store() method of UTF8Propertie class, he save the file change using the "java.util.Properties" class, and that class do not preserve the original file structure. So after store it, all LocalFileConfig Comments are losted.. I`m creating a class to save these files without change his structure, but the questions is.. where to place this code? on UTF8Properties as a new store() method? or should i use this new class code only on the ConfigPanel class, in the "save" action listener method? I think that some refactoring is welcome, but it could take a lot of time, special for me who do not know all system code..
Sorry, I replied on #1341, I'm copying my answers here:
The first thing i have saw is about the correctly class to read and manage this config files. The LocalConfigFile.txt is loaded by "Configuration" class as "UTF8Propertie" and also on "ConfigurationManager" class as a "Configurable". So i have some concerns about it, the first is to manage the file propertie change in all his instances
Maybe some Configurables, like the one used to load LocalConfig.txt, could be singleton instances, not sure...
I`m creating a class to save these files without change his structure, but the questions is.. where to place this code? on UTF8Properties as a new store() method? or should i use this new class code only on the ConfigPanel class, in the "save" action listener method?
I think we can reuse the existing iped.utils.UTF8Properties
class and override its store()
method. Another thing to keep in mind is that we should support comments translation to display in the new UI.
Hi guys. I made a commit on my #23_ui_4_config_proc branch I finished to develop the config options panel and i'll appreciate a review of implementations made by me. The first point i'd like yours reviews is the changes mades on LocalConfig, LocaleConfig, PluginConfig, UTF8Properties and AbstractPropertiesConfigurable files. The second one, is the implementation made on "iped.app.home.config.ConfigPanel" class, because it will orient-me on implementations on taks panel. Other questions: 1 - We will add tooltips on forms components? if yes, we'll get it on txt file or we'll add manually on messages files? If we get from txt file we lost the possibilites of translation.. 2 - We'll change home panel logo to match the new splassh screen logo? if yes, could you send me the image without the blue backscreen color ?
Thank you @thiagofuer! Currently I'm on vaccation until December 18th, if @patrickdalla couldn't review before me, I can when I return.
- Yes. Maybe we can implement a mixed approach: get from config files if language is english or get from localization files otherwise.
- Yes. I'm not sure if it exists (@tc-wleite?) and maybe we need to edit it.
- Yes. I'm not sure if it exists (@tc-wleite?) and maybe we need to edit it.
I wrote a small piece of code to draw the logo used in the splash screen. I can generate versions of it with transparent background, or something else you guys have in mind. I will post an initial version here.
Four options with transparent background.
Just let me know what you would like to change, and I can generate other images.
Thank you @tc-wleite!
Four options with transparent background. Just let me know what you would like to change, and I can generate other images.
![]()
![]()
![]()
Thanks @tc-wleite !!
I put theses 4 options on code. What do you prefer?
Model 1:
Model 2:
Model 3:
Model 4:
i put the model number one on the code. if choose another, let me know!!
Hi folks, i'm adding a "Save and Load Case data" buttons to the case info tab. When the user push on "save case data" button it will create a json file containing all informed case data. I think we can export this file to the case output folder, then the json file can be used to populate the HTML report and also on "open case" feature, so before to open an existing case the user can see all details about him. What do you think?
What do you think about these options:
i think to show these option when user select a existent case output folder. So he could select between append, continue or restart!!
What do you think?
Hi folks, i'm adding a "Save and Load Case data" buttons to the case info tab. When the user push on "save case data" button it will create a json file containing all informed case data. I think we can export this file to the case output folder, then the json file can be used to populate the HTML report and also on "open case" feature, so before to open an existing case the user can see all details about him. What do you think?
Sorry for the delay, I'm on vacation until December 18th. Saving on case folder is fine. We already have a json format documented at the end of the manual on the Wiki for report generation, I think it should be reused and extended. The ReportInfo class, used to load/save that json, could be reused and extended too (and maybe renamed to CaseInfo).
What do you think about these options: i think to show these option when user select a existent case output folder. So he could select between append, continue or restart!! What do you think?
Agreed. Case not finished state (iped/data/processing_finished file absence) could be checked before enabling the --continue option.
Sorry for the delay, I'm on vacation until December 18th. Saving on case folder is fine. We already have a json format documented at the end of the manual on the Wiki for report generation, I think it should be reused and extended. The ReportInfo class, used to load/save that json, could be reused and extended too (and maybe renamed to CaseInfo).
No prob!! yes i saw the ReportInfo class and the json report documentation but the new Case Info Tab has different data, for that reason i do not extended the ReportInfo Class but is not difficult change the code, i can do that if you wish. Firtst wee need get to decide some points: 1-Will we maintains the asap file? He has different data. 2-Case info json and the ReportInfo json has differente case info data. Who will we choose? or will we maintan the boths? 3-Will case data json file be used to create the report html content? If yes i need to study how to do that because maybe he will conflict with the HTMLReportConfig.txt.
Agreed. Case not finished state (iped/data/processing_finished file absence) could be checked before enabling the --continue option.
So if a case already exists on output folder the user can only choose between "--append" and "--restart". If the output case isn't on "finished state" he canc choose the previous options and also the "--continue". Is it?
Hi folks
i'm making some progress on the user interface and i'm getting better little by little.
Now we get a first usable version (the implementation it's not finished yet) to test user interaction.
I'm putting a gif below to show a basic interface uses.
So please run my fork implementation and send'me a review...
By now the last functionality to be implemented is the main panel "open case" button.
i still not test on linux, i will do that when i finish the first version..