
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 -=-=-=-=                                                         =-=-=-=-
 -=-=-=-=                 The protector scene                     =-=-=-=-
 -=-=-=-=                                                         =-=-=-=-
 -=-=-=-=                      Kalkin/EViL                        =-=-=-=-
 -=-=-=-=                                                         =-=-=-=-
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-



   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

