Kris Deugau wrote: > Is there a way to force matching on the raw file, or at least control > the normalization to some degree so that formatting and details in the > original code aren't lost?
As a complement to that question, is there a way to *force* other Javascript files to be normalized for matching? The key problem with the obfuscation as in the examples I posted is all the ways you can split those strings, plus all the variations on whitespace in between the string fragments and operators. -kgd > I've been coming across .wsf files in .zip files, which are essentially > Javascript wrapped in a very thin wrapper: > > <job><script language="JScript" width=100> > [insert nasty Javascript here] > </script></job> > > However, signatures I've created based on the raw file never match, and > I finally figured out a few months ago that I'd have to use clamscan > --leave-temps to dig up the normalized text Clam was actually running > pattern matches against. > > Unfortunately I've just discovered a flaw in this process, in that the > normalizing process is also stripping off some of the key JS-obfuscation. > > I've posted the raw first ~8 lines of one of these files, and the > normalized version of that same chunk of text: > > http://deepnet.cx/clamfrags/raw-wsf-01 > http://deepnet.cx/clamfrags/norm-wsf-01 > > In this case, one of the key things I'd like to match on is the > "br"+"o"+"ken" strings in their broken form, but that information is > wiped away in the normalized version. > > -kgd > _______________________________________________ > 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
