These are the presentation materials we presented at Blackhat USA 2007 and Defcon 15. Thanks to everyone who came to the talks.
Software armoring techniques have increasingly created problems for reverse engineers and software security analysts. As protections such as packers, run-time obfuscators, virtual machine and debugger detectors become common, newer methods must be developed to cope with them. In this paper we will present our covert debugging platform named Saffron. Saffron is based upon dynamic instrumentation techniques as well as a newly developed page fault assisted debugger. We show that the combination of these two techniques is effective in removing armoring from most software armoring systems.
Read more for the release notes for Saffron DI.
i was wondering if it was bad to create viruses if you have never and or have no intention to set it off/distrube to other computers? but just out of plain curisosity.
if anyone has any replies to this plz send.
(and i have not created any viruses...)
Since more and more malware are using the COM interface I thought it was time to write some reconstruction helpers and creating a video tutorial how to use it on a real life malware. You'll see how a complete function which uses the COM interface will be translated into far more readable code than before. The code itself dumps the windows protected storage to steal account data like member site passes, outlook express accounts, autocomplete fields and so forth. The IDAPython scripts are indeed also available on my site.
Practical COM Code Reconstruction at Reconstructer.org
Tom Liston and Ed Skoudis has written a clean paper about how to detect a Virtual Machine and some possible method for prevent it against detection .
In the past I've taken some deep looks at device driver malware. Rustock is a good example of this (with some generous work from Frank Boldewin and others as well :).
However I am vaguely aware of some malware which mucks with the microsoft signing certificate stores and things like this. I've seen this behavior during analysis but never really thought about it. What are the reasons for this? Instdrv type methods seem to do a good job at installing malware drivers. A quick deobfuscation and disassembly reveals
push 0 ; lpServiceArgVectors
Code normalization is a popular topic for anti-virus researchers, especially with respect to classifying the phylogeny of a particular sample. The essence of the idea is that each assembly instruction is translated into an intermediate language that contains all the state modification performed by an instruction. The consummate example is that of the dec assembly instruction. This modifies a register and also modifies six other control flags. The results are then run through a series of optimizations which remove and reorder the code into the normalized form.
This intermediate form is interesting in that it is simply an expansion of the assembly language. I have trouble seeing how this intermediate step would be worthwhile over just optimizing the non-expanded assembly code. It seems completely impractical for implementing on a real-time defense system (such as a virus scanning engine) and is better suited to closed research systems.
The article is in the Volume 5, issue 2 of IEEE's Security and Privacy. The article requires a ridiculous fee to get to, so if you have access check it out.
Update: Find them on the author's website.
All versions of Windows support animated mouse pointers and a function from USER32.DLL load animated mouse pointer. An .ani file is based on chunks and each chunks start with 4 byte ID word and a DWORD have chunk lenghth. One of the chunks is "anih" and contains 36 bytes. The vulnerability is here ... code doesn't check the length of the "anih" long field before using it. Here are some teams that have published their analysis of the ANI vulnerability:
I'm currently looking for the VBS.Solow Variants A..E for analyzation. If anyone has them, I'd greatly appreciate it!
One of the many features of Vista that Microsoft has included is PatchGuard v2. Skywing has posted a great article on Uninformed about subverting PatchGuard v2. The protection mechanisms that Microsoft employs are some of the exact same ones that malware authors have been using for years.
There are some startling techniques that Microsoft is using to protect itself from reverse engineering and modification. One of them is to do a standard IsDebuggerPresent (or KdDebuggerNotPresent) to validate that PatchGuard isn't being debugged. The next protection mechanism is to use self-decrypting and self-modifying code inside of the Integrity Check Routine. Skywing has done a great job of outlining the defenses that are taken, as well as methods for subverting the system.
PatchGuard is meant to protect against unauthorized modifications of the Vista kernel. In essence, Microsoft does not want you to modify their kernel with your bad code. While these mechanisms are useful for preventing rootkits, as Skywing has pointed out they can be modified.
Virtual Machine Threats by Symantec Research
As virtual machine emulators have become commonplace in the analysis of malicious code, malicious code has started to fight back. This paper describes known attacks against the most widely used virtual machine emulators (VMware and VirtualPC). This paper also demonstrates newly discovered attacks on other virtual machine emulators (Bochs, Hydra, QEMU, and Xen), and describes how to defend against them.