Thanks guys.
I have read that document before and I guess it is too early for these types of programs to be publiclly available. (Especially not source code)
hxxp://www.luna.co.uk/~elverex/
hxxp://www.cleanscape.net/programming-solutions/code-analysis/index.html
hxxp://www.darpa.mil/ato/programs/dqw.htm
hxxp://suif.stanford.edu/research/analysis.html
The links above show that this kind of technology is very much in its infancy.
TQN : Anti virus software uses three methods to find viruses.
1. Signature of the known virus
2. Heuristic rule defining what a potentially bad peice of code looks like.
3. Emulation of the virus code.
Now 1 and 2 have been fairly well documented but part 3 is the most interesting.
The anti-virus program sets up a "sandbox" or an area in memory to load the program (according to the PE header) and then proceeds to emulate the code.
The code can be emulated at three basic levels
1. Actual code emulation of every instruction (with software emulating the registers) - this is very slow
2. Emulation of simple instructions and real live "handover" to the cpu to execute then and then return the values of the flags and registers
3. Tracing of code - This is where a breakpoint is placed between each instruction and the code is actually executed and jsut monitored by the main program - Very fast
The only thing is the faster the code emulates, the less safe it is. It is not acceptable to have a virus which can infect a machine just by scanning for it! (pity heheheh)
ok so the emulator sets up fake API addresses in the sandbox and sets up other areas of memory to the correct constants.
[ Imagine if under some circumstances FS:[0030] was different each time the program was scanned. Then you could detect the emulator and randomly stop the program from running. ]
Now the emulator "runs" the code.
It marks down any calls to API's and the values held on the stack (and the values of address the pointers point to as well). (Things like file seeks, MAPI accesses, lots of calls to MapViewOfFile() etc)
The same thing applies to calls made under Ring-0 (where applicable).
It also can mark areas of memory that are always changing
<-- asm -->
mov ecx, (Length / 4)
mov edi, DecryptThis
push edi
pop esi
@looper:
LodSd
xor eax , key
stosd
loop @looper
@DecryptThis:
Db "Encrypted Bytes",0
<-- end asm -->
So ignoring the fact that this little loop "looks" like an encryption routine, it also behaves like one...
It modifies all the bytes from @DecryptThis onwards for a length of Length bytes (length / 4 dwords).. it also modifies a lot of bytes in a small instruction space and the loop executes less or the same amount of times of bytes that needs to be decrypted .....
So the sandbox engine will flag this code as very suspicous.
Other things like searches for "NAVAPSVC.EXE" and other such process names in memory can trigger flags.
It will also flag known code fragments (which perform common tasks) as suspicious....
But mostly modern AV emulators and heuristics is all about program flow and full dynamic analysis....
I refer you to a paper I wrote many years ago (back in the DOS days) .. the methods are useless now.
[ just 'scuse the rubble site ]
hxxp://www.geocities.com/prozos/protbav.txt
There are still ways to defeat emulators.
Benny (I Think) from 29A published a small doccie on "Defeating the perfect emulator"... He basically says you get a random number from the system (From an area of memory that only changes once every re-boot) and then run a conidtional branch based on that number.
<-- asm -->
call getTheNumber ; maybe it returns a number between 1 and 1000
cmp eax,100
jbe @RunTheVirus
@okDone
Call SetupReturnToOEP
jmp OEP
@RunTheVirus:
Decrypt and do your shit
jmp @OkDone
<-- end asm -->
Now the benifit is that the virus emulator might not take the branch leading to the decryption of the virus. Also the actual branch could be buiried deep within quite a few conditionals to create a really large "tree" of jmp to have to be followed. This is the only way to defeat Finite Discreet Automation Analysis. (The analyser will eventually (or should eventually) run out of different paths it can analise at once)
Hmm ...
l8rz lads
RedBull