Where can I get an un-packer I can trust?

[Virus Guy]

Got an e-mail tonight with an attachment that VirusTotal identifies
as various versions of Bagle, such as DM/FB/GT/BT/CW/DL, but some
ID it as DX (CAT, Ikarus, Kaspersky, TheHacker, VBA32).

This is probably what it is:

http://www3.ca.com/securityadvisor/virusinfo/virus.aspx?ID=47438

Anyways, it says it's FSG packed. I looked for some FSG unpackers,
but many seem to have been written by hackers (cOmPleTe wItH FrEekY
..rEAdmE Filz tHaT m8ke me wOndeR iF i wAnT 2 tRy ThEm). Submitting
these unpackers to Virus Total usually come back with all but 2 or 3
AV progs finding nothing.

For example, this FSG unpacker:

http://protools.reverse-engineering.net/files/unpackers/fsg133unpazker.zip

has this in the file "usage.txt":

----------
hEllo there..

tHiz iz my first pub_prog_unpukzer.

ATTANSION!!!!!!!!!!!
tHiz prog is intended for use by TerriBBle iLLegalz ONLEY!!!
All other are restricted & will be prosecuted with
sincerely tsehpis,
my jE!
------------

Now maybe I just don't get east-european humor, but the text of that
message is just totally nutz.

What is a "TerriBBle iLLegalz" ???

What is the point of that warning? Or am I simply not hip enough to
understand it?

What is "HDD-MBR law" ???

Do I want to mess with software that is making a vague or disturbing
reference to the MBR of my hard drive?

 

[Art]

Got an e-mail tonight with an attachment that VirusTotal identifies
as various versions of Bagle, such as DM/FB/GT/BT/CW/DL, but some
ID it as DX (CAT, Ikarus, Kaspersky, TheHacker, VBA32).

This is probably what it is:

http://www3.ca.com/securityadvisor/virusinfo/virus.aspx?ID=47438

Anyways, it says it's FSG packed. I looked for some FSG unpackers,
but many seem to have been written by hackers (cOmPleTe wItH FrEekY
.rEAdmE Filz tHaT m8ke me wOndeR iF i wAnT 2 tRy ThEm). Submitting
these unpackers to Virus Total usually come back with all but 2 or 3
AV progs finding nothing.

For example, this FSG unpacker:

http://protools.reverse-engineering.net/files/unpackers/fsg133unpazker.zip

has this in the file "usage.txt":

----------
hEllo there..

tHiz iz my first pub_prog_unpukzer.

ATTANSION!!!!!!!!!!!
tHiz prog is intended for use by TerriBBle iLLegalz ONLEY!!!
All other are restricted & will be prosecuted with

sincerely tsehpis,
my jE!
------------

Now maybe I just don't get east-european humor, but the text of that
message is just totally nutz.

What is a "TerriBBle iLLegalz" ???

"Terrible illegals" presumably are criminals, wouldn't you think?

What is the point of that warning? Or am I simply not hip enough to
understand it?

The clown who wrote the unpacker is claiming it's only for use by
criminals.

What is "HDD-MBR law" ???

A lame threat that any "straight" person who uses the unpacker will
result in the criminals hacking and owning their machines, I suppose.

Do I want to mess with software that is making a vague or disturbing
reference to the MBR of my hard drive?

If you are incapable of analyzing the code, you would follow safe hex
rules, I would hope, and never run code from untrusted sources. OTOH
if your h.d. is fully backed up on removeable media you may not care
much if you take a hit.

Personally, I enjoy playing with stuff like this. I might try using it
to see which av are capable of unpacking and finding malicious
code in the packed file. It's a endless game, though. Obviously the
screwballs continue to write new runtime packers that av can't handle.
Reacting to new and unusual packers is as much of a rat race for av
developers as developing sigs for new malware.

Art

http://home.epix.net/~artnpeg

 

[Virus Guy]

It's a endless game, though. Obviously the screwballs continue
to write new runtime packers that av can't handle. Reacting
to new and unusual packers is as much of a rat race for av
developers as developing sigs for new malware.

Why is it necessary (for an AV program) to be able to unpack a given
payload or attachment?

The minute a new payload starts circulating in the obvious channels,
why not simply come up with a hash or a checksum (or how-ever the
def's are generated) for the payload as circulated - without going
through the hassle of unpacking it?

Do packed payloads change as they get circulated? If not, then for
detection purposes why do you need to unpack them to ID them? ID
them as they are - as circulated. You may not know just what they are
(Bagle vs Mytob, etc) but is that important?

If any given AV program doesn't have good unpacking capability, seems
they should instead just ID packed payloads based on their un-packed
signature.

 

[Art]

Why is it necessary (for an AV program) to be able to unpack a given
payload or attachment?

The minute a new payload starts circulating in the obvious channels,
why not simply come up with a hash or a checksum (or how-ever the
def's are generated) for the payload as circulated - without going
through the hassle of unpacking it?

Do packed payloads change as they get circulated? If not, then for
detection purposes why do you need to unpack them to ID them? ID
them as they are - as circulated. You may not know just what they are
(Bagle vs Mytob, etc) but is that important?

If any given AV program doesn't have good unpacking capability, seems
they should instead just ID packed payloads based on their un-packed
signature.

I don't know why sig scanning isn't done more prevelantly. Clamav,
which was designed for email gateways, uses simple sig scanning, so it
is being done.

I think many developers are overly focused on realtime scanning to
catch such stuff. The monitor is supposed to alert on the
self-extracted file in memory before it executes . The problem with
that is most users rely on their single realtime monitor. That's a
mere secondarly line of defense, and one to not rely on. Far better to
have the ability to reliably scan downloaded files using multiple
on-demand scanners.

Art

http://home.epix.net/~artnpeg

 

[Roger Wilco]

Why is it necessary (for an AV program) to be able to unpack a given
payload or attachment?

Probably because the detection signature deals with non-trivial portions
of the code rather than with the whole file. The packer may make a
different looking file depending on differences in trivial portions of
the whole file.

The minute a new payload starts circulating in the obvious channels,
why not simply come up with a hash or a checksum (or how-ever the
def's are generated) for the payload as circulated - without going
through the hassle of unpacking it?

Mostly because the hash or checksum is by far an inadequate method for
detection let alone identification. A file itself may be quite unique,
but it will share a hash or checksum with another equally unique (and
possibly legitimate) file. The only way to tag a unique file with a
unique tag is to use the file itself (or a larger one) as a tag (total
information redundancy). AV tries to reduce FP detections by using
arrangements of unique vital portions as signatures.

Do packed payloads change as they get circulated?

Only if the payload repacks a copy of itself to create a new malware
file (like worm/trojans do) so it depends on what the payload is or
does. A runtime unpacker could be used as a polymorphic virus dropper -
basically a type of first generation virus. Sure, the ones distributed
via usenet in one run will all be equal - but then all the perpetrator
would have to do to get around detection would be to change some
arbitrary text before packing. If the AV uses an unpacking and sig
scanning scenario then the perpetrator would have to do more than just
trivial changes to make the next go-round evade AV.

If not, then for
detection purposes why do you need to unpack them to ID them?

It may not be necessary, but remember this is a cat and mouse game where
the AVers want to make the next step more difficult for the perpetrator.

ID
them as they are - as circulated. You may not know just what they are
(Bagle vs Mytob, etc) but is that important?

I've argued this in here before - I don't think identification is
important, but detection is. Since reliable detection necessitates
having the actual code revealed, it just makes sense to use less some
vital snippets, which are also revealed, to do some further perhaps
vague identification.

If any given AV program doesn't have good unpacking capability, seems
they should instead just ID packed payloads based on their un-packed
signature.

Some of the lesser AVs probably do this already, I don't know. The
problem is that it isn't good enough to make minor alterations to the
payload program also detectable. A payload that writes "You're toast!!"
to the screen while deleting data files may get detected while one that
writes "Gotcha!!" while doing the same may not. It is best to detect the
actual dirty work code after it is revealed by the unpacker or runtime
environment emulator, this way the malware coder has to do more work to
evade detection on the next run. Not that they're not up to the task -
considering the two you mentioned already have many minor variants.

 

[Art]

Probably because the detection signature deals with non-trivial portions
of the code rather than with the whole file. The packer may make a
different looking file depending on differences in trivial portions of
the whole file.

The way I looked at this question was/is from the POV (and the limited
scope) of blocking malicious email attackments _and also_ downloaded
malicious setup/install files. For such purposes it seems to me a
"good sig method" (whatever that might be) might be a useful adjunct
to or enhancement of av scanners.

Mostly because the hash or checksum is by far an inadequate method for
detection let alone identification. A file itself may be quite unique,
but it will share a hash or checksum with another equally unique (and
possibly legitimate) file. The only way to tag a unique file with a
unique tag is to use the file itself (or a larger one) as a tag (total
information redundancy). AV tries to reduce FP detections by using
arrangements of unique vital portions as signatures.

Some hash or "good sig method" should be suitable for the purpose I
have in mind. MD5, for example, would not produce a unacceptable FP
rate, but it might be too slow. I'll just say that some compromise
method that's both fast enough and low enough in FP rate can likely be
used, though I don't know off hand exactly what the best method might
be.

This "special sig" method would come into play only for email
attachments and when a setup/install file is detected. Whether or not
such an approach would turn out to be better or easier in the long run
than unpacking/uncompressing and "scanning within" I don't know. I do
know that many av are not doing the prevention job in this regard,
though.

<snip>

Art

http://home.epix.net/~artnpeg

 

[Mal]

Art wrote:




Why is it necessary (for an AV program) to be able to unpack a given
payload or attachment?

E-Mail scanners at a corporate level as a start.

Think of the AV detection (upside down) pyramid in a corporate environment.

You want to detect as much junk at the entry to the organisation.
Desktops at the final level are much harder to keep up to date vs the
email gateway...

 

[Virus Guy]

E-Mail scanners at a corporate level as a start.

What does that have to do with anything?

Think of the AV detection (upside down) pyramid in a
corporate environment. You want to detect as much junk
at the entry to the organisation.

Detecting mal-ware payloads inside e-mail at the server is not the
issue.

I don't see why you can't do detection based on the signature of the
packed file (uu-encoded because we're talking e-mail attachment). I'm
still not convinced that there is an advantage or need to unpack
widely-circulated e-mail payloads just to id them.

If malware authors are resorting to more and more obscure and
customized packing methods, then ID'ing the packed file is one way to
flush their efforts down the toilet.

 

[kurt wismer]

Virus Guy wrote:
[snip]

I don't see why you can't do detection based on the signature of the
packed file (uu-encoded because we're talking e-mail attachment).

because it's trivial to re-pack it with some other packing program or
some other set of packing options and get a file with a different
signature...

how many signatures do you think should be required for the same malware?