Open patrickdalla opened 4 months ago
Hi @patrickdalla, yes, the reason you described is correct and this behavior is intentional. Users can also search for carved:true AND name:CarvedLed
to find all those files. Current behavior is fine to me, but I'll defer the decision about this to @wladimirleite, since he is the module author.
Hi @patrickdalla and @lfcnassif! Well, I think it is possible to change the pre-defined filter to include the search @lfcnassif mentioned, but I am not sure if it can be misleading to the user in some cases (e.g. incomplete videos recovered, from which nothing meaningful can be reproduced).
the current database already have some false positives.
In fact, in the specific case, all led carved, including the not alerted ones, were true positives, while there were false positives for some not carved zero filled files.
any way you decide.
The current database already have some false positives. In fact, in the specific case, all led carved, including the not alerted ones, were true positives, while there were false positives for some not carved zero filled files.
That is a valid point.
I see two options:
hashDb:status
to pedo
.@patrickdalla, which solution do you have in mind?
1
Well, I would prefer option 2 over 1, and actually almost suggested it. IMHO that hash filter originally intended to flag files which full hash was found into the hash database tagged as child abuse. Creating another predefined filter for LED carved files is another option. Anyway, as I said, @wladimirleite can take the decision here.
The filter Hash\ Alert\ (Child\ Porn) in top left combo filters list, lists some CarveLed* files, but not all of them. Maybe this happens because not the entire file was carved, as LED carving is based only on first bytes, what leads to a different total file hash. Any way, this inclomplete files could be listed as well. I almost skiped them.