[clamav-users] clamdscan versus clamscan detection

[Kris Deugau]

Matus UHLAR - fantomas wrote:
> On 31.03.22 11:02, Petr Jurášek via clamav-users wrote:
>> https://www.mail-archive.com/clamav-users@lists.clamav.net/msg51769.html
>>
>> It's the same situation. Vir is detected, but file is "clean", you can 
>> see it in summary.
> 
> looks like that. I completely missed it.

[snip mix-n-match results]

*nods*  I've been trying to coherently describe the sets of interactions 
for a bug report, but it's not making a lot of sense from the outside.

 From the sets of files I've come across, I've found the following.

Component files as left by clamscan --leave-temps are not always matched 
correctly.

Both hash and pattern signatures for various component files will do one of:

- Work correctly:

$ clamscan -d foo.hdb nastyfile.xls
nastyfile.xls: foosig.UNOFFICIAL FOUND
[...]
Infected files: 1

- Match/don't-match with two result lines and "Infected files: 0"
$ clamscan -d foo.hdb nastyfile.xls
nastyfile.xls: foosig.UNOFFICIAL FOUND
nastyfile.xls: OK
[...]
Infected files: 0

Most prevalent on this series of files, creating pretty much any 
signature for the component/fragment file that appears to always extract 
as e3af082cc2ec644830a69ddafe5abe31_1, and which the "file" utility tags 
as "Applesoft BASIC program data".

- Double-match with multiple result lines listing the same signature:
$ clamscan -d foo.hdb --allmatch nastyfile.xls
nastyfile.xls: foosig.UNOFFICIAL FOUND
nastyfile.xls: foosig.UNOFFICIAL FOUND
[...]
Infected files: 1

This case also covers having *multiple* different signatures - either of 
the same type or different types - that should each match different 
files from --leave-temps.

- Don't match at all:
$ clamscan -d foo.hdb nastyfile.xls
nastyfile.xls: OK
[...]
Infected files: 0

This case usually happens for signatures based on what appears to be a 
generated datastructure reference file, xlm_macros.[hash], however I'm 
pretty sure one of the other extracted files from --leave-temps did the 
same thing.

===

Blind brute-force pattern (.ndb) signatures on the raw file appear to 
match OK.

At this point I've just fallen back to brute-force pattern signatures, 
generated from multiple samples by a script that runs sigtool --hex-dump 
on each one, filters out mismatched bytes, and compacts long runs of 
mismatched bytes to {nn}.  These are grossly oversized signatures (~~1K 
characters), but they work.

-kgd