The goal of this article is to demonstrate how simple malware analysis can be using Memoryze and some good old fashion common sense. Readers should have some knowledge of how malware works, and be somewhat familiar with Memoryze. A good place to familiarize yourself with Memoryze is the user guide included in the installer.

Memoryze is designed to aid in memory analysis in incident response scenarios. However, it has many useful features that can be utilized when doing malware analysis. Memoryze is special in that it does not rely on API calls. Instead Memoryze parses the operating systems' internal structures to determine for itself what the operating system and its running processes and drivers are doing.

This paper is a direct descendent of my previous one regarding the metamorphic engine of the W32.Evol virus. I advise you to take a look at it before reading this one, or at least be acquainted with the subject of metamorphism. The focus of this paper is the special engine of the Lexotan32 virus.

The virus was released in 29A#6 Virus Magazine in 2002, the Annus Mirabilis of metamorphic viruses. The virus was created by the prolific VX coder, Vecna, and was one of the last complex creations of this kind. I could further elaborate on the genealogy of this virus, but I think it is sufficient to say that this virus is a culmination of many of the techniques developed throughout the author's career.

This article is about breaking modern executable protectors. The target, a
crackme known as HyperUnpackMe2,
is modern in the sense that it does not follow the standard packer model of
yesteryear wherein the contents of the executable in memory, minus the import
information, are eventually restored to their original forms.

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.

The W32.Evol virus was discovered around July 2000. Its name is derived from a string found in the virus, but much more can be implied from the name. Up until then, most of the viruses were using Polymorphic engines in order to hide themselves from Anti-Virus scanners. The engine would encrypt the virus with a different key on every generation, and would generate a small, variant decryptor that would consist of different operations but remain functionally equivalent. This technique was beginning to wear out as AV scanners would trace virus-decryption until it was decrypted in memory, visible and clear.

This article explores the features and functionality of the metamorphic engine of the Evol virus, the first virus to utilize a 'true' metamorphic engine according to Symantec.

In part three of this three part article series, the kernel-mode interface to Windows debugging is dissected in detail. The reader is expected to have some basic knowledge of C and general NT Kernel architecture and semantics. Also, this is not an introduction on what debugging is or how to write a debugger. It is meant as a reference for experienced debugger writers, or curious security experts. The reader is expected to have some basic knowledge of C and general NT Kernel architecture and semantics. Also, this is not an introduction on what debugging is or how to write a debugger. It is meant as a reference for experienced debugger writers, or curious security experts.

In part two of this three part article series, the native interface to Windows debugging is dissected in detail.
The reader is expected to have some basic knowledge of C and general NT Kernel architecture and semantics. Also, this is not an introduction on what debugging is or how to write a debugger. It is meant as a reference for experienced debugger writers, or curious security experts.

The internal mechanisms of what allows user-mode debugging to work have rarely ever been fully explained. Even worse, these mechanisms have radically changed in Windows XP, when much of the support was re-written, as well as made more subsystem portable by including most of the routines in ntdll, as part of the Native API. This three part series will explain this functionality, starting from the Win32 (kernel32) viewpoint all the way down (or up) to the NT Kernel (ntoskrnl) component responsible for this support, called Dbgk, while taking a stop to the NT System Library (ntdll) and its DbgUi component.

The reader is expected to have some basic knowledge of C and general NT Kernel architecture and semantics. Also, this is not an introduction on what debugging is or how to write a debugger. It is meant as a reference for experienced debugger writers, or curious security experts.