I thought some people might be interested in this prize challenge by insecure.org. There are 3 files, 2 PE and 1 ELF, the PE files have modified sections with the names .adata and .svkp, PEiD identifies them as ASProtect 1.2x - 1.3x and SVKP 1.3x.

http://seclists.org/lists/fulldisclosure/2006/Jan/0814.html

=== CSRRT-LU Malware Contest ===

Sometime ago, we made the [[Honeylux]] contest and it was a very funny
and interesting contest. Now inside various projects at CSRRT-LU, we
are collecting a lot of undefined malware. We would like to give the
ability to all the people that are interested to better understand
what malware is doing. So if you want to give a try and maybe
win... just pick the following files and read the very basic rules.


I like the idea of this type of challenge. Personally though, I think having to wade through the apparent unpacking chores first to get at the "malware" analysis itself, makes it less appealing to the larger population of those who might want to try the challenge. A good piece of malware should withstand intense analysis even without being protected by a registered copy of Asprotect. Seems a bit more like an RE employment exam, "You got the skillZ boy?

Regards,
Kayaker

GEEZ!

Maybe that's why it's so hard to get rid of all that stuff it's packed! - I agree Kayaker - what are they looking for - unpackers, (crackers), or code analysts - I hardly think anything remotely installed has ever been packed.

SiGiNT

The third one, the ELF, is fortunately not packed, and looking through it in a hex editor I can see many interesting strings, but my minimal knowledge of *nix prohibits me from going any farther...

exe #1 seems to borrow a lot of code from this paper:
EDITED BY GABRI3L TILL END OF CONTEST

I absolutely agree with you, Kayaker. If this is a virus analysis "contest", then it should focus on those techniques wich are naturally in a virus, for example communication through IRC or anything else. For cracking purposes, the fact of having to loose time unpacking it - depending on the version it may be an unpacker, but i guess it isn't the case, will prevent most people from working on this target.

I frankly don't understand why to focus so much on the unpacking stuff, given i can set up a couple of VMs, with sniffers and so on, and check its behaviour in five minutes. It isn't necessary to unpack a virus if you are only interested in some specific parts of it.

Cheers,

did you say ELF? Hm, there are a few days left

HAVOK


hmm i slightly ddisagree - or better explained don't care. The unpacking etc skills are probably wanted, too by them. Also when given the case - an unknown executable - could have ie a virus body in itself, protected by packers etc. Sounds obvious to me at least.
Also I doubt you can find a ie "payload" via monitoring network etc, oltough your point is valid, to see if it is probably a NW communicating malware at all - it helps.

so ... gonna d/l this now

thanks,

--
0xf001

What if it's only active on Tuesdays and you're sniffing it on a Wednesday? What if it takes specific actions on English versions of Windows XP but your VM is using the German version of Windows Server 2003? These are examples of why black-boxing can't be the only approach.

update - on the ELF

nice, sweet and sexy hehe - fools every disassembler tried so far (did not try IDA yet), also ELFsh, and all "exploring" tools I tried ...

[edited, too - in the sense of the contest]

segfaulting your tools, thats what you want to see hehe.

means almost back to the ELF specification and at least set some valid values there in order to do anything useful. a pitty they left in so many strings - or are they there just to get on a wrong path ?

its a good prog to test your RE tools I can allready say - I use it now to improve them - once they can open this, they are good enough hehe

it catched me, wanna know now ...

disavoved: i see it the same, it can as best help to see something, which then is at least good to know

regards,

--
0xf001

Not the *only* approach, but the first one. If its obvious the proggy is a virus then you take the signature, and again you don't need (most likely) to do the full unpacking, and job done.

Don't missinterpret me I do think unpacking is a very valuable skill, but packing virii and then asking to analyze diverts the focus, at least for me. One can gain a lot of info hooking syscalls and using some basic network tools. Then, if there is something missing you need to debug, use IDA, etc.

Example: it's known (published in a "serious" journal), that current AVs are not able to recognize virii packed with execryptor. They don't have signatures to aply, cos this packer use kinda metamorphic engine. Neither you have the chance to emulate it, due to its too strong anti-debug. This is a clear example, at least in my opinion, where an unpacking approach is pointless.

Now it seems everybody uses weak packers but this can change in the near future. I bet it will.

In practice, when i take a virus, or any other app, i never run it in a VM first. I always examine it with a debugger and then move to the disassembler, but this doesn't mean i think is the most effective way.


Cheers,

HAVOK, you focus so much on virii here, the binaries are about "malware" in general I think.
#3 in fact is not a virus for example.

I just still think in order to be (more) sure it's really necessary to look at the code, especially when its a "malware" with unknown purpose.

I am also more the disassemble first, then debug kind of person hehe

regards,

--
0xf001

I think the arguments have merit on both sides. For the first file, I didn't even bother unpacking it. EDITED BY GABRI3L TILL END OF CONTEST Now that does not mean that that is the only thing going on. The protector could have emulated API's or it could have changed the access flags for my dll's checking for redirection, etc... Which would have made my analysis method useless.

Unpacking the program isn't tough and it really doesn't play a role in how the program operates. But sometimes, as havok sort of mentioned above, the packer can actually play a part in how the malware is analyzed. API emulation, encrypted sections, or themida which protects a programs memory space from being read. Can all play important parts in how malware functions.

I think the issue isn't as much as "If its packed" but rather "how it's packed". If the packer just functions as a wrapper for the code, then yes, its just another step in the analysis to unwrap the executable
But if the packer/protector plays a role in how the malware functions then that needs to be taken into account and viewed as one more thing to analyze.

In this case, I think it is correct that the unpacking is just another step in the analysis. They didn't need to pack the files, and just causes more time to be spent before real analysis can take place.

The first file is detected by NAV that it is W32.Gaobot. The second is W32.Spybot.

CNT: don't trust antivirs...

I think it's not fair to talk about the 3 malwares in details, at least not before the end of the contest...

hehe try avg /scan "path" and it will say its sdbot.tqf and sdbot.swf
irc backdoor trojan
it wont identify the elf and kaspersky will obviously have a different story to tell

@0xfoo1
elfsh not loading it ?
which version you tried the stable 0.51 or beta 0.65rc1 ?

i tried that elf on elfsh some time back and it was able to load it
and try playing with hdr1.arch set commands + info

and as Zairon says i think it would be not be fair enough to talk about details
before the eggs are hatched

blabberer,

its elfsh 0.65rc1 and to be correct it _loads_ it, but ie displaying program headers resulted in endless loops in this case.
at least its not clean checked for these invalid values used here. So the impression was "elfsh can not handle it".

it handles it - somehow/partly. the elf header it displays correct I would wish sthg like: a marker "Invalid" for so obvious cases. Whatever happens with mem allocation in this specific case some tools loop forever, some segfault
when tables are accessed "out of range" hehe

I am writing with Zairons words in my mind not to unveil too much. I know the reason and its obvious why the progs "misbehave" etc ...

regards, 0xf001

In fact, it's funny to know how to extract signatures. Very basic example:

Imagine we have a virus x and and antivirus av(). x is a sequence of bytes, say (b1,...,b100), but not them all have been included in the signature which av() has in its database. For example, Av recognizes that an application is infected by x if it contains bytes b1, b7, b19 and b30. This bytes are the "signature" of the virus x. Obviously, if we nop out those bytes in x and examine it with av, computing av(x), then the result will be "not infected by x".

Now, let's see how to extract the signature:

Ok, if we have a copy of x available, let's take only the first half of x and let's see if av detects it as a virus:

Is "av(b1,...,b50)" detected?.
yes: then the last byte of the signature is b1,...,b50 (them all are in the interval)
no: then the last byte of the signature is in b50,...,b100.


With this "divide and conquer" approach we can find the last byte of a virus (discarding always one half). Now suppose we have found that b19 and b30 are the last two bytes in the virus' signature, we ask this:

Is "av(b1,...b9,b19,b30)" detected?
yes: appart from b19 and b30, the rest of offending bytes are in b1,...,b9
no: appart from b19 and b30, there is an offending byte in b10,...,b18

Note that we have included all detected bytes in the question. That's the trick.

When we have found that the signature is b1, b7, b19 and b30 we can paste this bytes in our favourite application so it is "infected" by x.

I hope the explanation is readable

If the signature has wildcards this would be more sophisticated to do, but still possible. So, one has to take AV results very carefully. Manual inspection is the only way and, as disavowed and 0xf001 have told, debugging + disassembling is totally necessary if you want to make sure, but i'm lazy...

Cheers,

PS: @0xf001: i mentioned "virii" instead of "malware", but it was a general comment.

uh ah - my norton has just deleted this (slightly modified) ELF file before I could disassemble it in IDA

well I am fully for "never trust the AV" but maybe I was wrong before and it is a virus ....

we'll see

cheers, 0xf001

Hell!

Norton deletes half of the tools I want to be able to use, even if I tell it to ignore "Hack Tools" - AVG is good at that too! PC-Cillin seems to be the most "reverser friendly".

SiGiNT

yeah ,

i usually have these effects when I accidently do system scans, or they run automatically and destroy half of my "DOCz" folder

just some steps before, all was fine - i test disassembled it stage after stage, and I did not even thik it could be a virus, that was the "shock".

cheers, 0xf001