Re: Latest dist v5.2

[Brandon Enright <bmenrigh () ucsd edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 27 Jan 2010 14:18:00 -0800
Fyodor <fyodor () insecure org> wrote:

> On Tue, Jan 26, 2010 at 05:31:42PM -0600, Ron wrote:
> > > Have you (or anyone else) tested to make sure this will solve the
> > > problem? If not, I guess what we'll have to do is build the
> > > installer and submit it to the same links as in
> > > http://seclists.org/nmap-dev/2010/q1/211.
> >
> > No, I didn't test it, but somebody commented that changing just the
> > first bit is enough to overcome the scanner. I change every bit,
> > though, and the encoder isn't built in, so there isn't really any
> > way an a/v scanner would pick it up.
>
> We should have tested :(.  Now I'm getting reports that
> nmap_services.exe triggers Panda Antivirus W32/Xor-encoded.A:
>
> http://www.cloudantivirus.com/en/threat-information/Xor-encoded.A/194318/
>
> VirusTotal finds that as well:
>
> http://www.virustotal.com/analisis/5938478eb7195e53ba408b6fc390b35f2ccff6e68b761da4a5dfab97f3164a9c-1264630143
>
> -F

I should have chimed in about this, sorry.  XORing by 0xff is probably
THE MOST COMMON byte to XOR by.  I just ran into a binary last week
XOR'd by 0xff.

It is *so* common, in fact, that here's something right out of my home
folder:

bmenrigh@gamma ~ $ cat xordecrypt.pl
#!/usr/bin/perl

use strict;
use warnings;

my $key = pack('H*', "ff");

[...more perl code...]


Unfortunately we can't just change to another byte because the next
most common thing is to XOR by some individual byte, just not 0xff.

Many AV products check for XOR encoding by XORing parts of the header
with other parts of the header looking for known values.

For example, the MS DOS stub header before the PE header in Windows
executables always starts with "MZ".  If you XOR M and Z together you
get the number 23:

$ perl -e 'print ord("M") ^ ord("Z")'
23

But, no single-byte XOR will change that

$ perl -e 'print ((ord("M") ^ 0xff) ^ (ord("Z") ^ 0xff))'
23

or

$ perl -e 'print ((ord("M") ^ 0x69) ^ (ord("Z") ^ 0x69))'
23

There are other well-known offsets in the MZ stub and PE header that AV
products will check against for XOR encoding too.

So, if we want to defeat dumb signatures and still obfuscate in a
simple, easy to decode way, I'd suggest we XOR by 4 bytes, say,
0xabcd1234, and prepend a null to the result.

So our file would be \x00<xor of the file>

This will defeat all generic, accidental signatures.  Of course, it
won't defeat deliberate targeting by AV companies.  If AV companies
take issue with our binary and write signatures for it, no amount of
obfuscation we try is going to work in the long run.  We can take the
issue up with them if it comes to that.

Brandon

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAktgyFEACgkQqaGPzAsl94J8gQCfTT1gaQxctrN02S0W8i2iPz62
AgwAn09YJja4sBDAd14YSFc8QRjgM5KI
=FLF8
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/