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.
…tion:" for chats and "Communication:" for messages
I think in the Aleapp report tree root node. Maybe specific plugin credit could be also rendered in the plugin tree node (create author field in PluginSpec). |
|
I noticed some file references weren't added in Linked_ITEMS. For example:
I let a case running this night, but IPED was compiled with ec4902d, so maybe you have already fixed. Maybe this mapping identification and correction can be done the line 311 of LavaInsertSqliteDataInterceptor |
|
Some items categorizations I did in the processClassificationAndMappings aren't being done anymore. The logic may have changed but the items are still extracted but not categorized. |
Add a FILE_PATH fallback in the LEAPP integration: untyped columns whose values are device file paths (File Path, Local Path To Media, *Path, etc.) are resolved to the matching case item and added as linked items. Path resolution handles Android storage symlinks and is deferred to AleappTask.process() so the per-row searches spread across the worker pool. Cookie/URL and other non-file "Path" columns are excluded per plugin.
Thanks, @patrickdalla, for alerting such fact! These columns are not mapped to files by ALEAPP. So I took the code you had implemented and added some other maps for symbolic links. The result is in commit 7b51954. |
Move media-type derivation out of LavaInsertSqliteDataInterceptor into a dedicated AleappMediaTypeResolver, and make it the single classification point: plugin-specific rules emit stable subtypes (notification, account, email, siminfo, etc.) that map to categories via CategoriesConfig.json, instead of setting categories in code.
Great! A similar logic was applied in commit 91b493c that introduced the class AleappMediaTypeResolver. |
|
I am trying to process again the same case with last commit, but it freezes in LeapUtils findItemByPath method. It seems that the plugin "Emulated Storage Metadata" returns some unexpected value that causes this method to freeze. It calls findItemByPath with pathRoot="samsung" and pathValue="samsung", then called searchItemByPath freezes |
|
One thing i have noticed: the case I am processing is an UFDR. The Aleapp report node is being created right at the root of the ufdr zip, but the extracted cell phone file system structure root is a subfolder of this zip/ufdr folder. Have you tested UFDR processing? It seems the problem cause is in this report node positioning. Another detail. I named as "samsung" the evidence when starting IPED using the -d parameter. |
I tested a case with |
|
Right. UFDR processing was a request from @lfcnassif : #2095 (comment) |
|
@patrickdalla I've just fixed it. |
Validates each extraction type in isSupportedAndroidExtraction: ufdr file systems must hold a "data"/"system" top level folder. Reuses LeappUtils.findItemByPath for the checks, now iterating the hits lazily.
|
It worked. |
|
Hi @aberenguel. The code have passed all my previous test cases. I've made a little change to ignore linking to FFS root this info seems to be irrelevant (straightforward in fact) and was slow as the item search was returning to many entries. |
Good catch, @patrickdalla . I've just changed to compare the string with equals and to also trim the pathValue. |
|
The property |
Hi @lfcnassif , I decided to create this pull request, but marked it as draft, as I am leaving on vacation