pingkasce.blogg.se - Driverdoc 2011 download

#Driverdoc 2011 download how to
#Driverdoc 2011 download code

Shields in gives a high-level language example of the int 2d anti-debugging trick.

We could not repeat the success of StrongOD on IMM, however, the readers are encouraged to try it on OllyDbg. A solution is given: use the StrongOD plug-in for OllyDbg to handle the correct execution of "int 2d". However, no explanation is provided for this byte scission. The execution of "int 2d" will cause a byte scission ( the next immediate byte following "int 2d" will be skipped).

When a debugger is attached, the exception is handled and when a debugger is not attached, the program (Max++) will be able to see the exception.

Bonfa in points out that the "int 2d" instruction will trigger an interrupt (exception).

Let's summarize the conclusion of the above related work: Ferrie, "Anti-Unpacker Tricks - Part Three", Virus Bulletin Feb 2009.

Tyler Shields, "Anti-Debugging - A Developer's View", Available at.

Guiseppe Bonfa, "Step-by-Step Reverse Engineering Malware: ZeroAccess / Max++ / Smiscer Crimeware Rootkit", Available at.

(Simply search for the "int 2d", and ignore the other parts). Please take one hour and read the following related articles carefully. We need to read some background information of "INT 2D". The new EIP value (i.e., the location of the next instruction to be executed is 0x00413A38)! Now the big question: is the behavior of the IMM debugger correct (i.e., is it exactly the same as the normal execution of Max++ without debugger attached)? By stepping over (using F8) the instruction " INT 2D" at 0x413BD5, we are supposed to stop at the next immediate instruction " RETN" (0x00413BD7), however, it is not. Now let us watch the behavior of the Immunity Debugger (IMM). This is an important fact you should remember in the later analysis. After the execution of the first 8 instructions, right before the "INT 2D" instruction, the value of EAX is 0x1. By single-stepping the malware, you might notice that the program's entry point is 0x00413BC8. The instruction we are trying to analyze is the "INT 2D" instruction located at 0x00413BD5 (as shown in Figure 1). These techniques can be easily evaded by a debugger, by purposely masking the return result or the kernel data structure of the operating system. For example, an anti-debugging program can call system library functions such as "isDebuggerPresent()", or to examine the data structure of Thread Information Block (TIB/TEB) of the operating system. To tell the existence of a debugger, as pointed by Shields in, there are many different ways. Approach (2) is rare (it targets and attacks a debugger - and we will see several examples in Max++ later). Approach (1) is the mostly frequently applied (see an excellent survey in ). There could be several general approaches: (1) to detect the existence of a debugger, and behave differently when a debugger is attached to the current process (2) to disrupt or crash a debugger. The purpose of anti-debugging is to hinder the process of reverse engineering. Our analysis complements, and presents an in-depth analysis of the vulnerabilities of debuggers. Bonfa has provided a brief introduction of this technique in. This lesson presents " int 2d", an example of the various anti-debug techniques employed by Max++. To prolong the life of a malware, anti-debugging techniques are frequently used to delay the analysis process performed by security experts.

#Driverdoc 2011 download code

Analyze the code between 0xaaaa and 0xaaaa.

#Driverdoc 2011 download how to

Know how to use a binary debugger to patch an executable program.Understand the byte scission anti-debugging technique.Understand the general interrupt handling mechanism on X86 platform.