pouët.net

iq: ofcourse you realize when the web is mature enough for graphical size compos most browsers will have their version of noscript alerting against anything strangely packed or obfuscated.

i think the demoscene should start a petition against antivirus companies, and mass announce it to the world (slashdot et al). have a wall of shame listing all the intros and antivirus companies that are wrongly recognized as virus and keep spamming it to the virus companies pr's till they do something about it. size optimization has feelings too. we have the right to pack our executables ffs.

i think fr guys did abit of that PR for a while then gave up. maybe if the whole scene was pushing it at the same time the companies would listen up and stop flagging anything thats packed as a virus..

Wouldn't it be enough to have a packer which doesnt frag with the windows exe header? Or is the problem bigger than that?

i think the problem is, if a specific packer is getting used to compress malware, they create a signature which just checks for the characteristics of that given packer.
the worst thing i experienced so far was a false positive of a program i wrote in borland delphi (which just utilized some windows API commands and was rather small), not even being compressed. the AV said something about Delphi.GEN :( changing the order of how i included some units fixed the problem tho.

The problem is mostly caused by the a feature in antivirus programs called "heuristic analysis", that is code patterns resembling patterns in the signature file should be detected as viruses, until the antivirus receives a clear pattern from its company. Since most packers have a specific way to pack an exe and since most of the packers have been used to pack malware, when a particular packer pattern is detected the antivirus flags it as a virus.

1: Make many 4k or 2k or 64k of random ints
2: call em exes and give them appropriate headers, or just add PE or MZ
3: scan em'
4: ????????????????????
5: life sux

you guys got hash'd

It's just not that the packers are "typically" used to pack malware... actually most antivirus just flag them as "packed exe", and not as malware (yeah, with weird signature names, but...).

The problem is that, for an antivirus to be effective, it should unpack to memory when scanning to make sure that something is not a virus (that's both unpractical and highy not doable, writing all possible forms of unpacking in an antivirus engine would be killer), OR put some hooks on every code execution on the system... both would be performance killers for any platform.

If an AV wouldn't give "false positives" for packed EXEs, it'd probably just allow any packed malware in.

It's not AV's to blame here... it's malware creators!

jcl: malware guys didnt invent badly implemented heuristic analysis advertised as bullet proof solutions.

ps: yes, but I'd rather have a false positive on an intro than my computer infected by malware because it was packed and the AV couldn't unpack it, OR an AV consuming 40% of my CPU by scanning every single byte of code running on my system's memory (vs. scanning a file on disk before execution).

I still agree with ps despite your supposed inefficient method used to excuse av doing it's job wrong. Unpack by packer signature and then check to see if it's malware using traditional methods. How hard can that possibly be? You can probably unpack between i/o waits for the sake of pete.

it's like 10 different AV vendors if you want to cover the popular ones (and a bunch of smaller ones as well). and they don't ever remove the packer signatures, they just seem to have a whitelist or something.


it's not about the header, they actually use (part of) the depacker as signature. i.e. using a non-optimized header would gain nothing.


the ones i've dealt with are all "real" signature matches, not heuristics. some of them are labeled weirdly (mostly after the trojan they added the signature for). there may be heuristic matches for kkrunchy too, but if so, i've never run into it.

hey, if your packer is used by just two trojans, you're hosed. i figure they have a large suite of "good" apps they test against to check if their signatures have critical false positives, but demos aren't in there. if adding kkrunchy detects 3 viruses at once with no false positives in their test suite, it's going to stay.

giving them an unpacker isn't a solution either. first off, unlike upx, the unpacker *did* change between almost every single kkrunchy version (and the project wasn't on source control until 0.21 or so). i don't have the old unpacker myself anymore, and even if i had, no AV vendor wants to add 10 decompressors just to avoid some very infrequent false positives. the second big issue is that the newer kkrunchy versions are actually symmetric - yes, debris does actually take several seconds to unpack, even on newer machines (the time before the resolution selector dialog shows up), and the packer/unpacker only exists in ASM (since it's copied verbatim into the executable). no chance in hell AV vendors are going to put something in their scanner that takes multiple seconds to unpack a ~170k .EXE (even if it's triggered very rarely!), and even less of a chance if the only unpacker is written in size-optimized ASM that quite likely will result in memory corruption if handed invalid data.

at this point the most practical solution to me seems to be renaming the files to a different extension, replacing the MZ/PE magic values with something different, and then agreeing on a small (uncompressed) stub program that can load and execute such a file.

Not quite, for any efficient packer... plus there's still the hassle of adding several different unpacking engines (plus maintaining those, with newer versions) on database updates.

I still think asking an antivirus to unpack every possible exe is just a bit too much... for the vast majority of people, a false positive is always better than letting malware (false negatives?) in (count me in for that majority of people).

However, what I'd ask AV companies is a simple way to "let slip through"... old AV programs used to have that option when finding any malware... now, if you want to run a "false positive" executable, more often than not, you have to go through a series of steps to disable the realtime protection, plus unflag the executable if it was already flagged (or disable the whole antivirus)... which is just too cumbersome.

I BLAME PROZAC FOR ALL THESE FALSE POSITIVES

ryg: Yes you are also right. The exclusively create signatures for packers. Run into this myself. Here is an example.

A line from the first post:

Regarding the hosting problem it should be feasible to "encrypt" (well, calling the .exe .rgba and prefixing the file with rgba shoud do) the files on disk and let your download.script decode them...

For the general exe problem you just have to create your own packer without releasing it, then it should always stay safe :D
Or at least avoid the packer to fall into the wrong hands. Say we have a safe-crinkler producing the same file size but with a different, undetected header. Then it could be possible (for the selected few) to recompress approved intros into this AV-safe format.

I'm still not sure I understand how the signature is created, but, would it be reasonable to reserve 4 bytes in every intro that crinkler would fill with random data everytime so it would be impossible for AV to recognize them? Not sure I'm saying something stupid, again, I don't really understand how AVing works.

btw, they already closed rgba's account down. Didn't even take 24 hours, great.

I never used any AV software on that 'my good ol' system' !! .. and it always runs .. and stable !! .. and does everything I want it to run .. even if I have to check things myself first !! .. All kind of demos intros and stuff !! .. I just donno what this talk is about !! .. I just surf safe and I don't get 'infected' !! .. not messing with AVS !! .. What's ya problem ?? ..

Make them net safer .. and you don't have to mess with AVS !! ..

i don't have AVs neither in any of my systems. But people do. And I'm afraid is too late to change the entire world, so we better find a solution.

stupid question of the day, does untergrund.net support wordpress?

IQ, we should NOT make harder to detect the packer.

All the hassle, is because the packer already make it hard enough to the AV, to the point that it has to flag the packer all the time, if you make it have "random stuff" to make detection harder, they would have to make the heuristic thing even more aggressive, taking even more packers down (and the legitim software on them).

The thing is: If we offer a packer that make heuristic harder, someone will use it to make a malware, because we just offered the malware creator a "free malware stealth generator".


The thing that we should do, is ask AV companies to NOT act aggresively with packed stuff (like, quarantine instead of deleting outright... and warn the user that the file is SUSPECT), except with files that they are certain that is malware (ie: a known packed malware, has its own easily recognizible signature).

Also, we should make a list of the most popularly attacked demos, and make that list available to AV vendors, so they can whitelist that shit.

iq: yes.

if the problem is malware, and the packers are closed source just make a version that doesn't import certain malware friend functions. although there are always other methods to import stuff from dlls it would make packers less efficient for malware.

also just a guess. but also the loadlibrary & getprocaddress api functions might be setting the things off.

i dont have read all the thread, so maybe what i will say have already been written...

if I was you i would encrypt these files using a simple algorithm... to do this, just download all your files in a folder and lauch a console application that will open and encrypt each of them (using a simple xor for example)

then put the file back on the server
after, instead of giving a direct link to the files make a link to a php page instead. in the php file, write a simple loop that will read the content file then write the xored (unencrypted) result to the stream. ( if you do it well you dont even need to create temporary file for this, or allocate a big buffer, just unencrypt littles blocks as you read them and send them directly to the stream)

it will be totally transparent for the end user, and, since the files are xored, the annoying bots will never detect any "malware" patterns anymore

when everything will be in place, the only work needed will be to encrypt the new files before uploading them (should not be that hard)

i like this solution very much.