Maximize
Bookmark

VX Heaven

Library Collection Sources Engines Constructors Simulators Utilities Links Forum

The protector scene

Kalkin/EViL
Coderz [1]
June 2000

[Back to index] [Comments]

There are many sub-cultures in the computer world: hackers, demo-coders, musicians, graphicans, virusauthors, crackers. And there's also a not so well knows scene: the protector-scene. It mostly consists of crackers. So what do these protector guys do? They research ways how to defeat debuggers/code analyzers/emulators/disassemblers and write programs that use these ways to protect COM and EXE files. Why am I telling this? Because there's been quite some talk about anti-byte techniques, the advantages of slow polymorphism and other ways to make the detecting and/or disinfecting of virus harder. But almost nothing has been said about anti-debug tricks, even if those are REALLY important. Already in number 4 (or was it number 6?) of 40hex was an article about ADcode. Samples there were for confusing the reading of code. But the methods have involved FAR beyond that. Nowadays the protecting part uses stack tricks to crash debuggers, changes between protected and real mode, checks memory, calculates checksums, debugs and emulates it self, relocates the code in memory, opens the original file and checks it for changes. The protectors contain polymorphic engines (I've seen all better known MTEs in them: TPE, ViCE, MtE, DAME, etc.). They have become really powerfull. But they still resemble to viruses: become executed first, do their stuff, clean up, execute the real program. Some of these protectors are REALLY hard to crack, even really good crackers have a problem with them. I come to the point now: what do you think, how many really good crackers are there among AVers? Sure, they know debuggers and dissemblers, but that's not enough to be a good cracker. What now if some hard AD code, so hard that even the best crackers have problems with it, has been used in your virus? Wouldn't the AVer, who gets a sample of it, have some sad times, sitting up all night and trying to decrypt the virii? But how can a viruswriter get this kind of code? For our luck, exactly like in viral business, there are many sourcecodes available. And there's also an another reason why to check protectors: quite a lot of them check the executable for changes. It's no problem when your virus is resident and has stealth capabillities, but if you coded a runtime virii then you're fucked. This can be changed by adding code that prevents the virii from infecting protected files. Ofcourse there's a third reason: use the encryption routines of a protector for crypting the virus. Or you can encrypt the file with this code and insert another decryptor, which decrypts your virii, into the main decryptor. The main coal is that AVP for example (seems to be the AV which can unpack the most executable compressors and decryptors) scans the file (finds no viral infection), finds the protector, unpacks it, scans the unprotected file (and finds again no virus). A (possilbly) good example of the code produced by the protector scene are EliCZ device drivers - ExDs. They are VxDs that are executed in DOS, work their way up to ring0 and stay there. Plus points: undetectable (or that's atleast what EliCZ claims). Why can't we use this technology in our virii? But check out the things yourself. You just need access to Internet and the following address: http://www.suddendischarge.com

By accessing, viewing, downloading or otherwise using this content you agree to be bound by the Terms of Use! vxheaven.org aka vx.netlux.org
deenesitfrplruua