, there are several different types of breakpoints, and OllyDbg supports all of those types. By default, it uses software breakpoints, but you can also use hardware breakpoints. Additionally, you can set conditional breakpoints, as well as set breakpoints on memory.

You can add or remove a breakpoint by selecting the instruction in the disassembler window and pressing F2. You can view the active breakpoints in a program by selecting View ▶ Breakpoints or clicking the B icon in the toolbar.

After you close or terminate a debugged program, OllyDbg will typically save the breakpoint locations you set, which will enable you to debug the program again with the same breakpoints (so you don’t need to set the breakpoints again). shows a complete listing of OllyDbg’s breakpoints.

that strings can be a useful way to gain insight into a program’s functionality, which is why malware authors often try to obfuscate strings. When malware authors do this, they often use a string decoder, which is called before each string is used. shows an example with calls to String_Decoder after obfuscated data is pushed on the stack.

shows the stack window when a breakpoint is hit at the start of VirtualAlloc.

shows the disassembler window when a breakpoint is hit at the start of VirtualAlloc. We set a conditional breakpoint when [ESP+8]>100, in order to catch Poison Ivy when it is about to receive a large amount of shellcode. To set this conditional software breakpoint, follow these steps:

1. Right-click in the disassembler window on the first instruction of the function, and select Breakpoint ▶ Conditional. This brings up a dialog asking for the conditional expression.

2. Set the expression and click OK. In this example, use [ESP+8]>100.

3. Click Play and wait for the code to break.

.

Hardware breakpoints are powerful because they don’t alter your code, stack, or any target resource. They also don’t slow down execution speed. As we noted in the previous chapter, the problem with hardware breakpoints is that you can set only four at a time.

To set hardware breakpoints on an instruction, right-click that instruction and select Breakpoint ▶ Hardware, on Execution.

You can tell OllyDbg to use hardware breakpoints instead of software breakpoints by default by using the Debugging Options menu. You might do this in order to protect against certain anti-debugging techniques, such as software breakpoint scanning, as we’ll discuss in .

Memory Breakpoints

OllyDbg supports memory breakpoints, allowing you to set a breakpoint on a chunk of memory in order to have the code break on access to that memory. OllyDbg supports the use of software and hardware memory breakpoints, as well as the ability to specify whether you want it to break on read, write, execute, or any access.

To set a basic memory breakpoint, select a portion of memory in the memory dump window or a section in the memory map, right-click it, and select Breakpoint ▶ Memory, on Access. You can set only one memory breakpoint at a time. The previously set memory breakpoint is removed if you set a new one.

OllyDbg implements software memory breakpoints by changing the attributes of memory blocks containing your selection. However, this technique is not always reliable and can bring with it considerable overhead. Therefore, you should use memory breakpoints sparingly.

Memory breakpoints are particularly useful during malware analysis when you want to find out when a loaded DLL is used: you can use a memory breakpoint to pause execution as soon as code in the DLL is executed. To do this, follow these steps:

1. Bring up the Memory Map window and right-click the DLL’s .text section (the section that contains the program’s executable code).

2. Select Set Memory Breakpoint on Access.

3. Press F9 or click the play button to resume execution.

The program should break when execution ends up in the DLL’s .text section.

Назад: Executing Code

Дальше: Loading DLLs

Отправить

sss

sss

×

Войти в систему

Войти с помощью соц. сетей: