ALeapp task #2095
ALeapp task #2095
Conversation
that does informs the non existence of registered artifacts in script, meaning it won't be treated as a plugin. Other exceptions are rethrown.
static variable, multiple plugins concurrent execution were scrambling device info between their specific file Output. As the necessary result is the merging of those all info, the concurrency is not a problem, being it done at the end of all individual plugins processing (4th queue).
allowing replacement of methods to redirect HTML table lines insertion to IPED classes, as long as logfunc and logdevinfo calls.
ALeapp, making it possible to override python class. It skips any keyword arguments passed to any class method.
report file, this means that this file is a genereted detailed content for this item. So, it is exported as the content of the artifact item.
exported file, saves it as a link and return, avoiding duplicate metadatas.
was leading to exception as fileLoader does not work with these files inside zip. So, for now, as ALeapp will be deployed unzipped, ignores the override of any files that are inside ZIP libs.
children), as the Leapp Report.
with double backslash, as it backslash is a escape char in python.
ilapfuncs that depends of this name.
integrated with IPED timeline.
referenced media file in html report. Inside IPED, this can just add a link to the media (TO BE IMPLEMENTED).
debugging compatibility).
method declaration. If so, method name is not declared, so a direct access to this PyCallable should be done.
misses patterns with * at the end name.
applying pattern.
first is a mount point to the second, so the link can be correctly done.
file in case output path.
|
I've made some more tests and pontual enhancements and corrections. I think I should some third developer evaluation/opinion before continuing, @lfcnassif. I fact, if the design is good and no errors found, I think this can be merged as is. |
|
Thank you very much @patrickdalla! This is a very important feature, I'll try to test it after other ready PRs scheduled for 4.2 in the queue. One question: if an UFDR is processed with this PR, will we get duplicated results coming from PA decoding and from ALeapp decoding? If yes, I think it should be avoided or be configurable. Maybe with a similar approach used for WhatsApp today, or maybe with the approach that would be implemented for #2012. |
|
Aleapp processes data from FFS. It expects data files in its original path,
not in the way they are in UFDR.
Em seg., 20 de mai. de 2024, 21:01, Luis Filipe Nassif <
***@***.***> escreveu:
… Thank you very much @patrickdalla <https://github.com/patrickdalla>! This
is a very important feature, I'll try to test it after other ready PRs
scheduled for 4.2 in the queue.
One question: if an UFDR is processed with this PR, will we get duplicated
results coming from PA decoding and from ALeapp decoding? If yes, I think
it should be avoided or be configurable. Maybe with a similar approach used
for WhatsApp today, or maybe with the approach that would be implemented on
#2012 <#2012>.
—
Reply to this email directly, view it on GitHub
<#2095 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AG247S7KCJ75V56GGLYFXADZDKMGZAVCNFSM6AAAAABDVRWLH2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRRGUYDIOJYG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Anyway, there is already a config file to inform which Aleapp parser not to
run.
Em seg., 20 de mai. de 2024, 22:22, Patrick Bernardina <
***@***.***> escreveu:
… Aleapp processes data from FFS. It expects data files in its original
path, not in the way they are in UFDR.
Em seg., 20 de mai. de 2024, 21:01, Luis Filipe Nassif <
***@***.***> escreveu:
> Thank you very much @patrickdalla <https://github.com/patrickdalla>!
> This is a very important feature, I'll try to test it after other ready PRs
> scheduled for 4.2 in the queue.
>
> One question: if an UFDR is processed with this PR, will we get
> duplicated results coming from PA decoding and from ALeapp decoding? If
> yes, I think it should be avoided or be configurable. Maybe with a similar
> approach used for WhatsApp today, or maybe with the approach that would be
> implemented on #2012 <#2012>.
>
> —
> Reply to this email directly, view it on GitHub
> <#2095 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AG247S7KCJ75V56GGLYFXADZDKMGZAVCNFSM6AAAAABDVRWLH2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRRGUYDIOJYG4>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
|
Also, thinking twice, the task searches for items from already processed
items and its paths. As IPED uses UFDR xml info to restore original path in
cel FS, maybe, with some simple modification, Aleapp parser can find these
items too. I will check it.
Em seg., 20 de mai. de 2024, 22:22, Patrick Bernardina <
***@***.***> escreveu:
… Aleapp processes data from FFS. It expects data files in its original
path, not in the way they are in UFDR.
Em seg., 20 de mai. de 2024, 21:01, Luis Filipe Nassif <
***@***.***> escreveu:
> Thank you very much @patrickdalla <https://github.com/patrickdalla>!
> This is a very important feature, I'll try to test it after other ready PRs
> scheduled for 4.2 in the queue.
>
> One question: if an UFDR is processed with this PR, will we get
> duplicated results coming from PA decoding and from ALeapp decoding? If
> yes, I think it should be avoided or be configurable. Maybe with a similar
> approach used for WhatsApp today, or maybe with the approach that would be
> implemented on #2012 <#2012>.
>
> —
> Reply to this email directly, view it on GitHub
> <#2095 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AG247S7KCJ75V56GGLYFXADZDKMGZAVCNFSM6AAAAABDVRWLH2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRRGUYDIOJYG4>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
Great!
I think it can be useful, for example, for an application supported by ALeapp but not supported by PA, or if PA decoding brings incomplete or eventually wrong results. For this last example, disabling PA results importing per application may be needed, but that is related to #2012. PS: Running ALeapp into AB backups (when #2079 is merged) should be very useful too. |
|
Yes, it worked with the modifications of last commit, ALeapp plugins found and processed items from UFDR. |
|
I'm eager to see this merged into main. Is this bringing ileapp too? Or is this planned for another PR? |
AFAIK this is just about ALeapp integration, iLeapp should be done later. Would you like to help testing? There is a snapshot with this support below, you should be logged in github to see the download link: |
|
Hi @patrickdalla, an user/developer is trying to test this, but got an error "no module named geopy". What is the updated python dependency list needed to run this PR? |
|
Just found this list in Teams, posting here for those willing to help testing, let me know if it is outdated: Just put those into a requirements.txt file and run from iped embedded python: |
creates the dump as zip file.
Hi @lfcnassif , I decided to create this pull request, but marked it as draft, as I am leaving on vacation