bot1.exe part2

After my last post I started the analysis of the bot1.exe malware.

Just as the unpackme from my previous post, the execution starts at the beggining of the HEADER section.

After a couple of jumps there is a call to a procedure I called detach_dbg_rebuild_imports.

The packer used in this piece of malware introduces a new (at least for me) anti-debugging technique: the usage of the int 2Eh instruction.

The int 2Eh is the interrupt responsible to pass execution to a system call. The system call number is located in the EAX register, while the stackframe for that given syscall is pointed to by EDX (information found here)

When the int 2Eh occurs, EAX is holding the value 0xE5. I found this nice list of win32 syscalls and their respective numbers. So for WinXP we can see that 0xE5 is the number of the NtSetInformationThread syscall.

While I was googling for info on int 2Eh, I also found this post, where an explanation on how this system call can be used to detach the process from a debugger is found.

Quoting:

"We will submit that as the first parameter and the enum value for ThreadHideFromDebugger, 0x11, as the second parameter. If a debugger is attached and we pass in 0x11 to NtSetInformationProcess, our process will immediately detach any attached debugger and terminate the process."

So let's see what the stackframe pointed to by EDX looks like:

Stack[00000254]:0012FFB4  arg_0 dd 0FFFFFFFEh
Stack[00000254]:0012FFB8  db  11h
Stack[00000254]:0012FFB9  db    0
Stack[00000254]:0012FFBA  db    0

Which resembles very much the info gathered from the veracode post, and indeed if we set a breakpoint at the address after the int 2Eh instruction, the breakpoint is never reached.

In order to bypass this protection I have a breakpoint set at the int 2Eh, and then I adjust the EIP to the next instruction.

After this, there is a call to VirtualProtect with the arguments set as:

lpAddress 400000h

dwSize 1000h

flNewProtect 4 (PAGE_READWRITE)

lpflOldProtect 12FFC0h

Afterwards, there is a call to a procedure that uncyphers and restores the original binary values, and the import table is rebuilt. Once this is done, the program jumps to the original entry point through a jmp eax instruction.

Therefore I have found out what the original entry point of the binary is, and am now in the process of reversing it.