User interface to configure options and start processing about iped HOT 46 OPEN

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.

from iped.

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

from iped.

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:

from iped.

i put the model number one on the code. if choose another, let me know!!

from iped.

Hi @lfcnassif

Thank you very much @thiagofuer for helping with this! I'll probably have time to test it in the second week of January, since today I'm traveling on vacation again...

On january 10th is my time to travel, i'll be back on january 18th.. dont forget, i have sent you (to patrick and wladimir also) an invite to access my fork and make any change if you wish..

Just one quick suggestion, I think it is important to have a 4th tab on the left always displaying the Console messages while the processing is going on since they are very important and must be seen by the user if any are printed. They contain info about enabled but misconfigured modules, possible encryption detected, etc.

when the user press the "start processing" button a "IPED is processing" page is displayed and in the botton of the image (the socket plug) has a textarea where the console mesage is displayed before to change to the "Process finished succefully" page . on the demo vido above, the process has no error messages, only the "Iped finished. check log file.." message.
when the application move to the "Process finished succefully" page, he also has a button called "show terminal log" so if the user click on it, the complete console log is displayed on a pop up panel.

I was thinking on a 4th tab to show user extra options like "download internet data, portable, no gui, etc..." there is no option to do that yet..

One point I would like to ask to other devs is if processing should be called by fork and exec (current approach right?) or in the same process of the configuration interface, I'm not sure what is the best approach...

Yes it's a good point.. by now i start the iped.jar process calling "Runtime.getRuntime().exec(iped java command)" over a new thread.

from iped.

I need some help on Tasks tab.
I will leave as is until you may do some analysis on the code..
I will continue developing the open case options!!

from iped.

I have a suggestion. Case queue management for automatic processing could be implemented. Similar to the photo below

Thanks @gfd2020. Unfortunately the project is with very few human resources at the moment, so that might be implemented for a future version > 4.2, unless someone from the community volunteer to help us with it...

from iped.

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.

from iped.

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.

from iped.

Debug would be easier too.

from iped.

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

from iped.

Oh, I am a little out of date. Yes, that should solve it.

from iped.

Sent email to 3 UI config authors, waiting response.

from iped.

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.

from iped.

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.

from iped.

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.

from iped.

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

from iped.

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.

from iped.

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.

from iped.

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.

from iped.

@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

from iped.

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..

from iped.

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.

from iped.

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 ?

from iped.

Thank you @thiagofuer! Currently I'm on vaccation until December 18th, if @patrickdalla couldn't review before me, I can when I return.

1. Yes. Maybe we can implement a mixed approach: get from config files if language is english or get from localization files otherwise.
2. Yes. I'm not sure if it exists (@tc-wleite?) and maybe we need to edit it.

from iped.

2. 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.

from iped.

Four options with transparent background.
Just let me know what you would like to change, and I can generate other images.

from iped.

Thank you @tc-wleite!

from iped.

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?

from iped.

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?

from iped.

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.

from iped.

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?

from iped.

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..

from iped.

Thank you very much @thiagofuer for helping with this! I'll probably have time to test it in the second week of January, since today I'm traveling on vacation again...

Just one quick suggestion, I think it is important to have a 4th tab on the left always displaying the Console messages while the processing is going on since they are very important and must be seen by the user if any are printed. They contain info about enabled but misconfigured modules, possible encryption detected, etc.

One point I would like to ask to other devs is if processing should be called by fork and exec (current approach right?) or in the same process of the configuration interface, I'm not sure what is the best approach...

from iped.

when the user press the "start processing" button a "IPED is processing" page is displayed and in the botton of the image (the socket plug) has a textarea where the console mesage is displayed before to change to the "Process finished succefully" page . on the demo vido above, the process has no error messages, only the "Iped finished. check log file.." message.

Ah OK now I saw it, good!

from iped.

dont forget, i have sent you (to patrick and wladimir also) an invite to access my fork and make any change if you wish..

I don't, thanks. I haven't accepted intentionally to test if I can push directly to your fork without an explicity permission like I did before with other forks. @patrickdalla couldn't, so maybe it's because I'm the project admin, not sure...

from iped.

Hi folks, i need some help..
I`m fixsing some problems on the tasks table. I'm writing a code to detect enable/disable tasks states from ipedconfig.txt
i'm doing that using the iped.configuration.EnabledInterface.isEnabled() method
and any task has your own "isEnabled" implementation...
i'm facing some problems when i call isEnabled method from "QRCodeTask " and "DuplicateTask"
all they appears to don't have a config file, so on getConfigurables() all they uses the same EnableTaskProperty (see the code below) instance and then the same propertyName value is used on all they..
On my test the DuplicatedTask getConfigurables() is called first, so EnableTaskProperty(ENABLE_PARAM) instance will receive "ignoreDuplicates" as propertyName value. Then when i call QRCodeTask getConfigurables() he will receive the same EnableTaskProperty and the propertyName will be "ignoreDuplicates" and not "enableQRCode".

What should i do?
in the meantime i'm forcing QRCodeTask to always return a new EnableTaskProperty instance...

public class DuplicateTask extends AbstractTask {  
    public List<Configurable<?>> getConfigurables() {
        EnableTaskProperty result = ConfigurationManager.get().findObject(EnableTaskProperty.class);
        if(result == null) {
            result = new EnableTaskProperty(ENABLE_PARAM);
        }
        return Arrays.asList(result);
    }  
}

public class QRCodeTask extends AbstractTask {  
    public List<Configurable<?>> getConfigurables() {
        EnableTaskProperty result = ConfigurationManager.get().findObject(EnableTaskProperty.class);
        if(result == null) {
            result = new EnableTaskProperty(ENABLE_PARAM);
        }
        return Arrays.asList(result);
   }  
}  

from iped.

on my opinion, tasks without activation option in ipedconfig.txt should not be available on tasks table because the user has no option to enable/disable (some exception like TempFileTask is enabled by localconfig file on main menu config option, but SkipCommitedTask dos not)
or they could appear as unselectble mode on task table

from iped.

I'm sorry for the delay, I'm on vacation again...

i'm facing some problems when i call isEnabled method from "QRCodeTask " and "DuplicateTask"
all they appears to don't have a config file, so on getConfigurables() all they uses the same EnableTaskProperty (see the code below) instance and then the same propertyName value is used on all they..
On my test the DuplicatedTask getConfigurables() is called first, so EnableTaskProperty(ENABLE_PARAM) instance will receive "ignoreDuplicates" as propertyName value. Then when i call QRCodeTask getConfigurables() he will receive the same EnableTaskProperty and the propertyName will be "ignoreDuplicates" and not "enableQRCode".

This is a wrong result. A new configurable object used to be returned before. I think @patrickdalla changed the logic to reuse previous instances to avoid creating new instances and I thought that a good idea. But in the case of EnableTaskProperty, its ENABLE_PARAM should be checked before to be sure it refers to the same Task, this should be fixed. I think ConfigurationManager has a method to get the configurable object based on the ENABLE_PARAM property instead of its class.

I'll be able to take a closer look at this after I return in January 9th and after the 4.1 version is released.

from iped.

on my opinion, tasks without activation option in ipedconfig.txt should not be available on tasks table because the user has no option to enable/disable (some exception like TempFileTask is enabled by localconfig file on main menu config option, but SkipCommitedTask dos not)
or they could appear as unselectble mode on task table

I agree, not sure what is better. I also think a enable/disable option may be implemented for some of them, like TempFileTask, giving the user more control about processing optimization.

from iped.

I agree, not sure what is better. I also think a enable/disable option may be implemented for some of them, like TempFileTask, giving the user more control about processing optimization.

If i not mistake, TempFileTask is enabled by a propertie on localconfig file and the localConfig changes actually is made on the new Config Menu. When you go to the options task table page, the tempfiletask enable/disable state will be set by the changes made on config menu.
i beleave the localconfig file should not be included on profile because most of they options are about the user machine capabilities and there is no reason to change it on a profile..

from iped.

I'm spending to many hours trying to learn the code behavior, especially on how to load every taks and the config files without big progress. Some taks requires to call the process or the init method to set the ENABLE_PARAM propertie and other tasks dont. I dont know whats the best aproach to do it and theses clas are very sensible to the process result.

Its has not been easy learn the correct code behavior without a more detailed explanation about how to correctly manipulate it. So, to continue the task table implementation, i'll wait for your review!!

from iped.

If i not mistake, TempFileTask is enabled by a propertie on localconfig file and the localConfig changes actually is made on the new Config Menu. When you go to the options task table page, the tempfiletask enable/disable state will be set by the changes made on config menu.

Yes, it is correct. But it may be confusing to the final user and maybe the enable/disable of this Task could be moved to make its behavior similar to the others, just an idea.

So, to continue the task table implementation, i'll wait for your review!!

Don't worry about this, I plan to take care about this (complex) part when I have time. You can implement other things if you would like/have time. Thank you again for your big help with this feature!

from iped.

Hi folks, how's going?
I'll stop the coding for to weeks more or less.. It is my vacation now..
I finished the "open case" feature i have made some refactorings to the code and as the last thing before i go out to my vacations i tried to create a bootstrap to the iped home but could no finish.
The essentials function of this issue are ready. Some tests and code improviments can be made, but before to do it i will wait you take a look!!

from iped.

I have a suggestion. Case queue management for automatic processing could be implemented. Similar to the photo below.

from iped.

h

OK. The interface looks pretty good. Congratulations.

from iped.