or by reviewing your answers.

When we load this malware into OllyDbg, we see that it attempts to delete itself. Suspecting that something must be wrong or that this malware is significantly different from , we load Lab16-01.exe into IDA Pro. As shown in , we notice that the beginning of the main method appears suspicious because of several accesses of fs:[30] and calls to a function that IDA Pro identifies as one that doesn’t return. In fact, most functions recognized by IDA Pro have this suspicious start. (None of the functions in have this code.)

We see at ❶, ❷, and ❸ in that sub_401000 is called and the code stops there (no lines leave the boxes). Since a line doesn’t leave the box, it means the function probably terminates the program or doesn’t contain a ret instruction. Each large box in contains a check that decides whether sub_401000 will be called or the malware will continue to execute normally. (We’ll analyze each of these checks after we look at sub_401000.)

The function sub_401000 is suspicious because execution won’t return from it, so we examine it further. shows its final instructions.

. Let’s dissect in more detail.

shows the code in the top box of .

. At ❷, the second byte is accessed and moved into the BL register. At ❸, the code decides whether to call sub_401000 (the terminate and remove function) or to continue running the malware.

The BeingDebugged flag at offset 2 in the PEB structure is set to 1 when the process is running inside a debugger, but we need this flag set to 0 in order for the malware to run normally within a debugger. We can set this byte to 0 either manually or with an OllyDbg plug-in. Let’s do it manually first.

In OllyDbg, make sure you have the Command Line plug-in installed (as discussed in ). To launch the plug-in, load the malware in OllyDbg and select Plugins ▸ Command Line. In the command-line window, enter the following command:

. Then right-click the BeingDebugged flag and select Binary ▸ Fill With 00’s, as shown in the bottom portion of . This sets the flag to 0. With this change, the BeingDebugged check performed several times at the start of functions in the malware will no longer call the sub_401000 function.

Now let’s try the plug-in approach. The OllyDbg plug-in PhantOm () will protect you from many anti-debug checks used by malware. Download the plug-in and install it by copying it to your OllyDbg installation directory before launching OllyDbg. Then select Plugins ▸ PhantOm ▸ Options to open the PhantOm Options dialog, as shown in . Check the first option, Hide from PEB, to set the BeingDebugged flag to 0 the next time OllyDbg loads malware. (Confirm this by dumping the PEB structure before and after the plug-in is installed.)

shows the code in the middle box of .

to show that the 0x3E is included in the next instruction at ❸. If you look at the disassembly in OllyDbg, you won’t see this error.

is shown in .

uses three different anti-debugging techniques to attempt to thwart debugger analysis. The malware manually checks structures for telltale signs of debugger usage and performs the same three checks at the start of nearly every subroutine, which makes flipping single jump flags tedious when inside a debugger. As you’ve seen, the easiest way to defeat the malware is to change the structures in memory so that the check fails, and you can make this change either manually or with the PhantOm plug-in for OllyDbg.

Назад: Lab 15-3 Solutions

Дальше: Lab 16-2 Solutions

Отправить

sss

sss

×

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

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