aCaB wrote:
> Kris Deugau wrote:
>> ImgSpam.Misc.5:0:0:474946383761??(01|00)??004400002c00000000??(01|00)??0084(00|48|53)(00|15)(00|30|1c)f0f0f0(f0|e0|c0)f0(e0|b0|f0|d0|c0)f0(00|f0|40)(00|d0|e0|60|70)(f0|90|00|c0)(e0|90|00|b0|70)f0??(00|90|40|7d|10)(f0|ea)??(f0|00|e0|d0|46)
> 
> Hi Kris,
> There are a number of problems with your sample sig.

Advice appreciated... but I'm not sure you're at all correct.  As a
matter of fact, that's about a *third* of an active, live sig that Clam
seems to be using quite happily right now.  ;)

> The most important rules you should obey are:
> 1) you always need at least 2 static bytes before and after a wildcard
> (though a serie of ?? is fine)

Ick.  Clam doesn't seem to complain consistently about this, though.

Just for clarification, you mean:
Valid:   ...0ef2????bc34...
Invalid: ...(00|01)????f3(89|bc)... or
         ...??f4(00|01)b4??...

?

> 2) a static block must not start with 00

Ick again.  Clam doesn't consistently complain about this, either.

Again, for clarity:
Valid:     ...??0101ab...  or
           ...(a3|45)ff003400...
Invalid:   ...??0001ab...  or
           ...(a3|45)00003400...

> 3) The alt syntax is (aa|bb), not (aa|bb|cc..)

Ick cubed.  <g>

Clam happily *accepts* (aa|bb|cc..), and in fact I think it's working
just fine.  Except when it doesn't.  :(

In short:  If it's invalid, why doesn't Clam complain?
and:  If it's valid, why doesn't it work?

<G>

Let's take a new example.  This is one I've just pushed out to
production now:
(This is also one of the simpler ones I've generated!)

test.test:0:*:2c00000000??01??010003ff48badcfe30ca49abbd38ebcdbbff60288e64699e68aaae6cebbe702ccf746ddf78aeef7cefffc0a070482c1a8fc8a472c96c3a9fd0a8744aad5aaf????????(58|15|ed|e8)(70|2c|0a|7a)(b7|ba|16|05)(de|dc|8b)(6f|2f|2e|af)(97|d8|38|37)(20|4b|fc|2c)(1e|18|25|06)(9f|93|90|13)(cc|4f|cb|ca)(5a|e7|27|e6)(99|ad|34|53){180}ff{37}

Clam complains about this...  but once I trim the trailing {180}ff{37}
(something like that usually comes up), Clam is happy (and this time,
not only accepts the sig as valid, but tags the files I used to generate
it - which, for this class of imagespam, are almost disturbingly *regular*).

However, quite often I have to keep trimming bits off the end, with NO
pattern I can see (your rules don't seem to apply, if memory serves from
past attempts).  Eventually I reach a point where a) the sig is accepted
as valid by Clam, and b) Clam tags the source files using it.  b) is
quite often a much shorter sig than a).

Just to thoroughly confuse things, here's a sig that Clam doesn't
complain about, which *still* violates all three of your rules above (I
think...):

testsig:0:0:0aefbf??(00|01){12}(00|01|02|03)??ff

I don't know if it would actually match on any files though.  (Just
working on a quick hack to test this now.)

> So, just looking at the begin of your sig:
> 474946383761 <= all fine, static
> ?? <= wildcard following a static block, fine
> (01|00) <= wildcard not following a static block, bad
> ?? <= wildcard not following a static block, bad
> 0044 <= static block starting with 00, bad
> 
> So, this:
> 474946383761??(01|00)??0044
> Should really read:
> 474946383761????????44

The problem with doing that is that I end up with something like:

474946383761??????01ae{185}(ae|01){200}(0e|f0)

Or worse:

474946383761{400}

(I've come pretty close to that - *big*, *long* strings of "anything"
with maybe one or two solitary static bytes.)

If more than two possiblities for any given byte (and that's pretty much
normal for these images) have to be turned into ??, I generally end up
with a VERY long string of ??, which compresses down to {nn}.  Which
doesn't make a very useful signature.  :/

-kgd
_______________________________________________
http://lurker.clamav.net/list/clamav-users.html

Reply via email to