There are a number of reasons for the differences in the detection cases. The first of which is how ClamAV identifies the file type of file being scanned. ClamAV determines the file type of a scanned file using the 'ftm' signature files. The important signatures follow:
type:offset:magic:rtype:type 0:0:504b0304:ZIP:CL_TYPE_ANY:CL_TYPE_ZIP 0:0:504b3030504b0304:ZIP:CL_TYPE_ANY:CL_TYPE_ZIP 1:*:504b0304:ZIP-SFX:CL_TYPE_ANY:CL_TYPE_ZIPSFX 0:0:1f8b:GZip:CL_TYPE_ANY:CL_TYPE_GZ There ZIP archive file type signatures, two of which look for a specific magic at offset 0. However, the last signature uses a '*' offset which indicates the magic can be located anywhere within the file. Do note that the signature is meant to detect the specific variant of ZIPSFX. The GZ file, on the other hand, only has one magic that only triggers if found at offset 0. While an argument could be to extend the GZ file type signature file to search the entire file, there are a number of important counter arguments: 1. The GZ file magic is only 2 bytes long, this means that the extension over the whole file would result in a large number of false positives 2. In theory, by modifying the original GZ file, the file may no longer be a valid GZ file. Thus it's likely that ClamAV would not be able to correctly parse the file. Argument 2 may also result in the lack of detection as the file may not be possible to parse with modifications. As for the reason for the curl POST issue in case #6, can I ask how you what response you get back from clamd when you upload the file using curl POST? clamd is designed to handle a specific of commands that are described in the clamdoc.pdf that comes with the ClamAV source distribution. From what I can see, clamd does not natively support parsing HTTP messages. When I send a file to scan to clamd using curl, clamd fails to understand the message and sends back the message: UNKNOWN COMMAND -Kevin On Tue, Feb 17, 2015 at 1:23 PM, Noel Jones <njo...@megan.vbhcs.org> wrote: > On 2/17/2015 12:11 AM, Manoj Ramakrishnan wrote: > > Hi Al, > > > > Thanks for replying. > > It is exactly what I thought. But why is it different from ZIP file? > > I added extra characters in the beginning of the ZIP file but no issues > in > > scanning that and finding eicar signature. > > zip and gzip are very different formats. I suppose you added your > random character at a point where unzip ignored it. > > > > > > Also curious to see why is it not working in case #4 and #6? > > Either broke the eicar file with leading or trailing characters, or > maybe the squid plugin didn't recognize the file as a gzip. Use the > clam debug tools to examine the files extracted and scanned. > > The eicar signature is *very* specific, anchored at both the > beginning and end allowing only for a few extra spaces at the end of > the payload, no other extra characters. > _______________________________________________ > Help us build a comprehensive ClamAV guide: > https://github.com/vrtadmin/clamav-faq > > http://www.clamav.net/contact.html#ml > _______________________________________________ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
