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.
This is a cheatsheet to WinDbg from Microsoft. Thanks to the Metasploit for writing this.
RolfRolles has written an excellent article at OpenRCE about reverse engineering a sophisticated packer called HyperUnpackMe2.
"Modern protectors mutilate the original code section, use virtual machines operating upon polymorphic bytecode languages to slow reverse engineering, and take active measures to frustrate attempts to dump the process. Meanwhile, the complexity of the import protections and the amount of anti-debugging measures has steadily increased.
This article dissects such a protector and offers a static unpacker through the use of an IDA processor module and a custom plugin. The commented IDB files and the processor module source code are included. In addition, an appendix covers IDA processor module construction. In short, this article is an exercise in overkill. "
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.
SAVE seeks to classify closely related pieces of malicious software for the purposes of identifying future ones. The core idea is a good one: Byte code is modified for the purpose of obfuscating the signature of a piece of malware. The stated goal is to modify it in such a way that it is possible fool antivirus scanners. This is done in five different ways.
- Null operations are inserted into dead code. Assuming that one is modifying a section of code, insert null operations into the region. Nops are inserted at various places.
SPiKE: Engineering Malware Analysis Tools using Unobtrusive Binary-Instrumentation is a paper by Amit Vasudevan and Ramesh Yerraballi from UT Arlington. This paper outlines several different methods to control a running process. In this case, it is used for controlling malware.
The SPiKE method uses a kernel solution to implement "drifters" or memory read/write breakpoints. These breakpoints are then used to control the execution of the malware. The breakpoints are done via setting the target memory page in the kernel to a "not-present" flag, and then through "subtle software techniques" (their quote, not mine) they are able to transfer execution to the SPiKE API. This is very similar to Joe Stewart's OllyBone method of setting region based breakpoints. The rest of the interception points are based on the Windows API hooking via CreateProcess, OpenProcess, and others.
While reading through some papers, I found a particularly good one. While the methods are not ground breaking, and the paper is somewhat old (circa 2000) it does outline some of the good methods for detecting a viruses. These methods are still being rehashed today. Stripping Down an AV Engine by Igor Muttik is a good read. Check it out.
Do you have a particular paper you like? Post it in a blog or forum post with a brief description and share with the community.
Kurt Wismer comes up with the standard set of criticisms that we've received at Offensive Computing.
Kurt really touches on the heart of the issue when he says, "i suppose the argument could be made that public access helps those just breaking into the anti-malware market, but in reality there's all kinds malware already readily available to such people so they can build their malware databases organically... at the same time they can build their reputations and trust relationships with others in the anti-malware community so that by the time they need access to malware they can't easily find themselves they'll have people they can turn to..."
It is true, all you have to do is go look and you'll find all kinds of malware. What you won't find are collections of malware that are somewhat presorted for you. You won't find the analysis, and you won't find trends. This causes a duplication of effort that could better be spent on experimenting with new ideas. The old-guard of AV protection is just not working. There are many many smart people working on the issues, but in the end until people work together advancement cannot happen.
There are large barriers to starting malware research. We believe that those barriers are unnecessary for a largely innocuous threat. The real threat is the new malware that is not, and can not be detected. For the most part the current malware threat has been innocuous, and easily handled. What is the path forward when newer more creative threats emerge?
Ero Carrera created an excellent portable executable parser for python called PEFile. We've taken his file and run it across our entire malware collection for use in a future version of our malware analyzer. Attached is a collection of all the bug fixes we've made. If anyone has any comments on the modifications, I would very much appreciate hearing them.
Read the full article for all the bugs that have been fixed.
Apple has publicly apologized for including a virus on some of the latest iPods. While only 25 have been detected so far, this is still a disturbing trend. Apparently another unnamed manufacturer makes the iPods and is responsible for the infection.
One interesting quote is, "As you might imagine, we are upset at Windows for not being more hardy against such viruses, and even more upset with ourselves for not catching it."