Dynamic File Analyser for Hostile Code

[redbull]

Hi Guys,

You've all heard about static file analysis, where a program checks out the API calls made by an application (without running it). This is often used to determine if the file is some kind of trojan.

Also is there much available to do dynamic analysis.

Well i was wondering what software is available to do this. (And not crap like the API snoop type utilities) I'm talking about something a little more hard-core and job-specific. (kinda like the emulation an anti-virus uses to sandbox a virus while it analysises it)

Thanks

RedBull

[TQN]

I think we can use IDAPro to disassemly the hostile code and use some IDA x86 emulation plugins to simulate run it. Those plugins can find on Wasm site and have source code (Thank Volodya). I will try to play with them.
Regards

[Polaris]

Originally Posted by TQN

I think we can use IDAPro to disassemly the hostile code and use some IDA x86 emulation plugins to simulate run it. Those plugins can find on Wasm site and have source code (Thank Volodya). I will try to play with them.
Regards

The best idea while analizing viruses is to actually statically analize them using a disassembler (IDA/PVDasm/BDASM...) and to integrate this static analisys with live analisys...

You can do this live analisys by using:
1 - remote debugging using sice capabilities (or using latest IDA Pro if you have it) on a dedicated machine - hxxp://www.datarescue.com/idabase/remotedebugging/index.htm
2 - bringing up a "virtual network" using VMware like done here - hxxp://www.zeltser.com/sans/gcih-practical/revmalw.html

With this solutions you also have the possibility to run the monitoring tools from sysinternals and gather more infos.

Hope this helps,

Polaris

[TQN]

Thank for your informations, Polaris.
I known and have read some articles on Universitas Virtualis Bibliotheca Server (hxxp://bib.universitas-virtualis.org/) about Reverse Engineering the virus and hostile code. Some titles are:
- Reverse Engineering Hostile Code (pdf file)
- Reverse Engineering Malware (pdf file)
- Alien Autopsy: Reverse Engineering Win32 Trojans on Linux (pdf file)
However, all methods request to run the virus or hostile code on a machine or virtual machine (VMWare...), and if we have some mistake or carelessness ???
I am wonder, how some AntiVirus softwares know the virus? Do they statically scan the signature in the virus code or simulating run the virus code. Almost virus uses PE packing programs to pack them.
Regards

[redbull]

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

[Polaris]

Originally Posted by TQN

However, all methods request to run the virus or hostile code on a machine or virtual machine (VMWare...), and if we have some mistake or carelessness ???

The idea is to set up a machine to let the worm do its works - without care for that machine. In fact monitoring is done by using ANOTHER machine running a remote debugging system.

By running a worm/virus on a machine to be sacrificed, you can do whatever you want.

Byez,

Polaris

and what would you say about this

hxxp://www.woodmann.net/bart/files/shaker.zip

does it look like a virus code (asm obfuscator's output) ?

any ideas to improve it?

[TQN]

Thank redbull !
I think I need more time to read again and again your informations.
Regards.

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.

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...)

Anyway, I've been told a lot of emulators don't emulate Floating Point correctly, and a earlier post showed that VM Ware can be detected, so maybe just looking at it under a microscope isn't always Proof that code is harmless. What A sentance! Obvoiusly, I didn't major in english...

[redbull]

This is turning out to be an interesting thread

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

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.

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:

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...

for older versions of VPC (before m$) not emulates INTO & BOUND exceptions..
(very stupid fact, ye?)
so i recommend to old VPC users: update to m$-VPC.

you can detect it by looking at the IDT base address too

usually it is 0x80...... and on VPC/VMWARE it is 0xF.... or 0xE.... etc

RDTSC can also be catched, with a driver.
one can activate some flag in control registers to do that.

I suppose one could write a driver to avoid detection by such instructions.
Anyone ever tried?

{Edit by JMI: Line79 you DON"T get to increase your post count by posting TWO separate posts, 2 seconds apart. ]

Edit by Me: Rofl bullshits, i don't give a flying f... of my post count

[redbull]

I would love to get my claws on this software

hxxps://www.rootkit.com/gal_open.php?id=462

Please check it out and let me know if you have seen it before or know it or anything. I think this is a private build as I cant find it anywhere!!!