This is turning out to be an interesting thread
Quote:
|
Originally Posted by sgdt
It's worth noting that polymorphic code can (and usually is) written to avoid emulation detection. (Almost) Every emulator has bugs that can be programaticly detected, and when they are, the code remains harmless.
|
I refer you to a paper called defeating the perfect emulator:
hxxp://vx.netlux.org/lib/static/vdat/tudefeat.htm
Quote:
|
Originally Posted by defeating the perfect emulator
To detect an emulator you need to use something that differs when being emulated. This could be non common instructions, the function IsDebuggerPresent or similar. All of these methods has one weakness, The Perfect Emulator (tm). The Perfect Emulator would cut through them like me cutting through my victims, fast, elegant and non detectable. The Perfect Emulator would only differ from the processor in speed.
................................
Even if The Perfect Emulator never will exist its always possible to add some code to a good emulator after you have found a virus using a new technique. All your work with the polymorphic engine will then be useless.
|
To make code to detect one type of emulator will make it vunerable against other emulators so you are just moving the problem one step further.
An example of an extremely good emulator is the Microsoft Virtual PC 2004 ...
The only way to detect it is to detect the drivers installed under the virtual OS.. The names of which can be spoofed my modifying the .INF files before instalaltion.
Quote:
|
Originally Posted by sgdt
One piece of code I ran into recently (a protection, not a virus) set up a ring 0 call gate pointing to a "lock invalid instruction". If everything was running good, it would execute it from ring 3 and the exception would set up the next round of decryption. If things weren't quite right (too many clock-ticks on RDTSC), it would execute it as a call gate (ring 0) and the machine would instantly reboot. Even Softice was powerless to catch it. The instruction was identical, just how it was called was different. NOP the bad instruction, and the exception would never fire to finish decrypting code. Trace the code and BOOM. Quite eligent, but no match for OllyScript... (and exception handlers don't HAVE to be called from exceptions...)
|
Ok I have read up on very similar protections being used by the virus guys. In fact these guys were proposing this type of protection as early as 2001. I assume the scanners have a level of protection against this.
I would like to get my hands on that code you refer to Sgdt...
I haved used RDTSC detection before in my own code with great effect.
Here is an older virus which uses SEH to block emulators.
WIN32.OROCHI virus
MARCH 2000
Comments:
hxxp://www.madchat.org/vxdevl/vxmags/mtx1/virus/orochi.htm
Source:
hxxp://www.madchat.org/vxdevl/vxmags/mtx1/virus/orochi.zip
Anti-Debugging Highlights:
Quote:
|
Originally Posted by Web Page
- PUT A NEW SEH AND CAUSE ONE EXCEPTION, FOOLING APPLEVEL DEBUGGERZ AND EMULATORZ
- PROCESS MANY ANTI-EMULATION TRICKS:
* STACK MANIPULATION
* SELECTORS
* FPU COMPROBATION
* SELF MODIFIED CODE (INT 01H RULES)
- PROCESS ANTIDEBUGGER PART:
* IF W9.X DESTROY DEBUG REGS AND MAKE SHIT THE STACK
* IF NT, USE THE IsDebuggerPresent API
- BEFORE TO RETURN TO THE HOST IF WE ARE IN W9X JUMP TO RING0 AND STAY RESIDENT
HOOKING THE OPENFILE PROCEDURE AND STABLISH A COUNTAH IF THE NUMBER OF FILES OPENED
REACH A RANDOM VALUE MAKE A BIOS & CMOS TRASHING... ALSO EVERY FILE OPENED WILL
MODIFY THE DR3 REGISTER MAKING SOME DEBUGGERS VERY STONED (TRACING OROCHI UNDER TD32
THE PROGRAM JUMP INCORRECTLY INTO THE OFFSETS AND HANG THE ENTIRE MACHINE...)
|
I will run some tests on that virus code ....
I ran some tests about two months ago on all the AV programs I could get my hands on ...
I took 10 virus samples.
This is what I did:
1. A virus I wrote and never released - OLD MS DOS Polymorphic Companion virus - Anti-heuristsic and all (1996) ( I tested 4 generations )
2. A EXE dos file I wrote designed to trigger every heurtistic alarm possible.
3. Std Eicar Test File
4. Standard Win32 virus (forgotten the name :P ) (lets call it Test1)
5. Test1 with Eicar strings embedded and slight modifications.
6. Test1 with more modifications to program flow around dummy bytes at critical parts.
7. Heavily modified Test1 virus but the program logic stayed the same (ie it was still a virus)
After extensive testing I found the best anti-virus programs were:
Norton's Anti Virus
AVP
They caught every virus sample and were not thrown off by embedded eicar strings.
I will be doing some tests on "WIN32.OROCHI" especially the SEH and Floating point stuff...