Hi everybody,
I have one .exe file infected by CIH virus and I want to analyze it on virtual enviroment (like VMWare). Unfortunately this virus use some VXD calls in ring0 and it fails to work on VMWare. This dangerous virus works only on windows 95/98 and may damage the BIOS. I really want to understand its code and its functionality, so I need the virtual environment to test and debug it. Do you have any suggestion? Thanks for your help!

PS: Sorry for my poor english

Well, I guess I'd try with all the other alternatives within the virtualization field (VirtualPC etc, see: http://www.woodmann.com/collaborative/tools/Category:Virtual_Machines), and if none of them works, debug it in VMware and see why it's not working, and patch it.

In the general case, VMware should have no problem handling "VXD calls in ring0" as long as it runs the correct guest operating system (Windows 95/98 in this case, as you mention), and virtualization did not exist in the big sense back then, i.e. it really shouldn't be virtualization detection either, so the problem might just be some specific detail of the virus that you can patch your way past.

Why analyze it in a VM if you can just download and read its source code?
http://www.62nds.co.nz/62nds/documents/cih.txt

Well, looking at the source code might be just too easy. Maybe someone could point him to a copy of the "virtual" source code.

Regards,

There might be code behavior details that are not obvious in dead listing, even having source code, which need live debugging to be able to understand clearly. Otherwise developers, which by definition have the source code, and even better wrote the source would never have to use a debugger

Now to the question at hand:
I have tried to do some debugging of win95 and win98 in a VMware. I was trying to repair the drivers of an old application that interfaces with some instrument. My overall impression was that once I tried to go ring0, the VM stopped cooperating. This is in contrast with my experience with XP: I have been able to trace drivers and .sys files seamlessly inside winXP Vmware.
For reasons that are way beyond my capacity of comprehension, the VM simulation for older OS seems to be far less than perfect. I guess VMware was developed during the XP years with XP in mind, I don't know.

In any case, if you are so interested in studying Chernobyl, I would suggest you do it in an old machine/old OS installed using a throw away old hard-drive.

...and a throw-away motherboard, since it can nuke the BIOS too.

You can easily find the source code of this well-known virus, but I think live debugging will give us more details than dead listing, furthermore I need an environment to execute this virus to collect more samples. So I will try other virtual machine softwares. Thanks for your help!

Compile it and study it...

qemu is a cpu emulator, I think it will work no problem

You should eventually try to emulate all the VXD and ring-0 stuff on XP using SEH... it's not an easy job, but it can be done.
For an example of how to do, see my code here: http://www.woodmann.com/forum/showthread.php?t=10220

sapu: your stuff is awesome!

naides: I emphatically disagree with the assertion and attempted justification that you need to execute a program in order to reverse engineer it. There are plenty of folks in the AV industry that do a large amount of pure static reverse engineering. You can in fact recover 100% of the details in 100% of the cases, it's just a matter of time. Debugging is merely a luxury.

@habitual: You are right.
You will not find a strong argument from me. I do not reverse malware and only do some RCE as a hooby.
It is undeniable that, given enough time, pure static reverse engineering could recover 100% of the details. In fact, the rules by which a CPU operates and the way a program flows are well known. A CPU is a deterministic automaton, so all possible states can be solved by an analyst "pretending to be the cpu"(on paper simulation). I just think that in many situations, static analysis is just not practical.
Tracing crypted code, packed code from scratch, decryption keys that are not expressly present in the dead listing but calculated at run time, event driven behaviors, could generate quite a bit of pain to a static reverser. Surmountable with static analysis? yes. Practical? no.
Live debugging is a luxury: I agree. But sometimes is better to allow the cpu do most of the heavy lifting for you.

Hi everybody,

I've done my work without debugging :-D. Thanks for your help! :-)