Author Archive

Anti Debugging unleashed series # Part 2

September 29th, 2011 No comments

NTGlobalFlag lies at an offset 0x68 from PEB. The value of NTGlobalFlag
 is 0 when the process is not bein debugged. However, if the process is
 being debugged, the value of this flag is 0x70.

First we see the starting of PEB in windbg:

0:000> !peb
PEB at 7ffd6000
    InheritedAddressSpace:    No
    ReadImageFileExecOptions: No
    BeingDebugged:            Yes
    ImageBaseAddress:         00400000

Lets parse the PEB:

0:000> dt _PEB 7ffd6000
   +0x000 InheritedAddressSpace : 0 ''
   +0x001 ReadImageFileExecOptions : 0 ''
   +0x002 BeingDebugged    : 0x1 ''
   +0x003 SpareBool        : 0 ''
   +0x004 Mutant           : 0xffffffff
   +0x008 ImageBaseAddress : 0x00400000
   +0x00c Ldr              : 0x00271ea0 _PEB_LDR_DATA
   +0x010 ProcessParameters : 0x00020000 _RTL_USER_PROCESS_PARAMETERS
   +0x014 SubSystemData    : (null)
   +0x018 ProcessHeap      : 0x00170000
   +0x01c FastPebLock      : 0x7c980600 _RTL_CRITICAL_SECTION
   +0x020 FastPebLockRoutine : 0x7c901000
   +0x024 FastPebUnlockRoutine : 0x7c9010e0
   +0x028 EnvironmentUpdateCount : 1
   +0x02c KernelCallbackTable : (null)
   +0x030 SystemReserved   : [1] 0
   +0x034 AtlThunkSListPtr32 : 0
   +0x038 FreeList         : (null)
   +0x03c TlsExpansionCounter : 0
   +0x040 TlsBitmap        : 0x7c9805c0
   +0x044 TlsBitmapBits    : [2] 1
   +0x04c ReadOnlySharedMemoryBase : 0x7f6f0000
   +0x050 ReadOnlySharedMemoryHeap : 0x7f6f0000
   +0x054 ReadOnlyStaticServerData : 0x7f6f0688  -> (null)
   +0x058 AnsiCodePageData : 0x7ffb0000
   +0x05c OemCodePageData  : 0x7ffc1000
   +0x060 UnicodeCaseTableData : 0x7ffd2000
   +0x064 NumberOfProcessors : 2
   +0x068 NtGlobalFlag : 0x70

As you can see, the NtGlobalFlag is set to 0x70.

Following is the assembly code to detect the same:
MOV EAX, fs:[0x30]       ;PEB in eax

MOV EAX, dword ptr[EAX+0x68]  ;Value of NTGlobalFlag in EAX

CMP EAX,0x70			 ;If equal, means debugger present

As a side effect of NtGlobalFlags being set, heaps that are created
will have some flags turned on that can be used for anti debugging.
 Every process has a default process heap. Flags and ForceFlags for
a heap are 0x02(means the heap can grow) and 0 respectively. However,
 when debugging, they are set to 0x50000062 and 0x40000060

   Lets see the whole picture in windbg:

0:000> dt _PEB 7ffd6000
   +0x000 InheritedAddressSpace : 0 ''
   +0x001 ReadImageFileExecOptions : 0 ''
   +0x002 BeingDebugged    : 0x1 ''
   +0x003 SpareBool        : 0 ''
   +0x004 Mutant           : 0xffffffff
   +0x008 ImageBaseAddress : 0x00400000
   +0x00c Ldr              : 0x00271ea0 _PEB_LDR_DATA
   +0x010 ProcessParameters : 0x00020000 _RTL_USER_PROCESS_PARAMETERS
   +0x014 SubSystemData    : (null)
   +0x018 ProcessHeap : 0x00170000
   +0x01c FastPebLock      : 0x7c980600 _RTL_CRITICAL_SECTION

So, we know that the default process heap gets created at address
0x00170000. Lets parse the heap at this address:

0:000> dt _HEAP 170000
   +0x000 Entry            : _HEAP_ENTRY
   +0x008 Signature        : 0xeeffeeff
   +0x00c Flags : 0x50000062
 +0x010 ForceFlags : 0x40000060
   +0x014 VirtualMemoryThreshold : 0xfe00
   +0x018 SegmentReserve   : 0x100000
   +0x01c SegmentCommit    : 0x2000

So, malware authors can check these values for detecting the debuggers. Following is the assembly code to find the same(consider the debugger running):

MOV EAX, FS:[0x30]      ;Go to PEB

MOV EAX, dword ptr[EAX+0x18]   ;EAX holds the address of default
                               ;process heap

MOV EBX, dword ptr[EAX+0xc]     ;EBX holds the value of Flags

MOV ECX, dword ptr[EAX+0x10]   ;ECX holds the ForceFlags


PE Parser

September 29th, 2011 No comments

Understanding the structure of PE file is very important from the reverser’s point of view. And, I think the best way to learn it is to code a PE file parser itself. So, here is my PE Parser. This was compiled using Visual studio 8.

(Change the exetension to .rar)

PE_Parser download


Ch33r5 !!! :)

Anti Debugging unleashed series # Part 1

September 26th, 2011 1 comment

This is the first in the series of anti debugging tricks. I will discuss the various anti debugging tricks one by one in my further posts:


I will start with the most basic ones.


The first one in the race is the PEB.BeingDebugged flag.

PEB refers to Process Environment Block, and it contains the information regarding the Environment and various parameters of a process. fs:[0x30] always points to PEB. The structure of PEB can be seen using the following command in windbg:


0:000> dt _PEB


+0×000 InheritedAddressSpace : UChar

+0×001 ReadImageFileExecOptions : UChar

+0×002 BeingDebugged : UChar

+0×003 SpareBool : Uchar


For a process that is being debugged, note the peb.BeingDebugged flag below in windbg:



PEB at 7ffda000

InheritedAddressSpace: No

ReadImageFileExecOptions: No

BeingDebugged: Yes

ImageBaseAddress: 00400000

Ldr 00261ea0


Hence, a program using the anti debugging techniques can use this flag to know whether the program is being debugged or not.


The api IsDebuggerPresent() in kernel32.dll checks this flag to determine the presence of the debugger.


This check can be easily bypassed by patching the PEB.BeingDebugged flag to 0.


Ch33r5 !!!



September 2nd, 2011 3 comments




Zi _Crackme (Download crackme)



This is a simple crackme, and it took only 5 minutes to crack fom a noobe like me. Here comes the solution:


Target Study


Run the target. You see something like the below:

We need to change the registration routine, so that whatever the input we give, it accepts it.


Fire the olly. Now, the problem is how do we reach the routine where this serial registration is shown. I tried looking at call stack, but of no help. What to do now ?


Lets use the “animate” feature of the olly to reach near this registration routine. Do “animate over”, and whenever you get the serial registration screen, there should be a call which lead to the screen. So, breakpoint the call, do F9, step in(F7), and “Animate over” again. Doing this again and again will take you closer to the registration routine.



When we follow the above strategy, we see something like:

Stepping over the code, we see the following:


If the EAX is 0, then CMP EAX,0 will set the zero flag, and the JNZ will lead to the wrong serial. So, we need to patch the code somewhere here. There can be many possibilities, and for that brain usage is strictly recommended ;) I will simply NOP the JNZ instruction, and check if it runs es, it fine. Yes, I can see the message “Well Done”.


But But But ……. OOPS !! Address A50183 is allocated at runtime, so we cannt directly change the instruction to nop. We need to write a loader for it.


So, here is the script for loader(I am using RISC Loader creater)

O=risc_Zi _Crackme.exe: ;Output filename

F=Zi _Crackme.exe: ;File to patch


T=50000: ;Patching times

P=00A50183/0F,85,20,00,00,00/90,90,90,90,90,90: ;Patch the JNZ


However, the loader this script will create doesnt work. :( So, I tried out some more reversing and found the reason. The address A50000h gets populated with instructions after you have entered the serial. In the meantime you enter the serial, the loader has already finished.


By reversing in depth(again using animate over and F7 trick), I found the following instruction to be responsible for copying the code.




He He…. so everything is clear now. The code from the location specified by ESI gets copied to the location specified by EDI. Think… think .. think.. !! You only need to change the corresponding instruction from ESI.


EDI = 0A50000

ESI = 1016cb5c



So, adding 183h to ESI



You will notice that it is the same JNZ instruction at address 1016CCDF. Its your wish now whether to directly patch it, or change the address in RISC loader creator script.

The new RISC loader script is:


O=risc_Zi _Crackme.exe: ;Output filename

F=Zi _Crackme.exe: ;File to patch


P=1016ccdf/0F,85,FC,FF,FF,FF/90,90,90,90,90,90: ;Patch the JNZ




Yippie !!!! it works beautifully.



CHEERS !!!! :)









Binary-auditing training package – Manual decompilation, Exercise 8

August 13th, 2011 No comments
This problem statement is part of binary-auditing package. This needs
to be converted to HLL

Problem:(Assembly code)

sub_408138 proc near
000 push ebx
004 push esi
008 mov esi, edx
008 dec esi
008 test esi, esi
008 jl short loc_40816F
008 inc esi
008 xor edx, edx
008 mov dl, [eax]
008 xor ebx, ebx
008 mov bl, cl
008 add edx, ebx
008 test edx, edx
008 jge short loc_40815B
008 mov ebx, 100h
008 sub ebx, edx
008 mov edx, ebx
008 jmp short loc_408169
008 cmp edx, 100h
008 jle short loc_408169
008 sub edx, 100h
008 mov [eax], dl
008 inc eax
008 dec esi
008 jnz short loc_408142
008 pop esi
004 pop ebx
000 retn
sub_408138 endp

Pseudo/High Level code:
var_esi = var_edx;
var_esi -- ;

if(var_esi >=0)

LOWER byte of EDX=*var_eax;  //EAX supplied from outside

LOWER byte of EBX=LOWER byte of ECX;  //ECX supplied from outside


var_ebx=100h;   //256

*var_eax=LOWER byte of EDX

binary-auditing RCE exercise

August 11th, 2011 1 comment
As a part of learning reverse engineering and enhancing RCE skills, I was going through binary-auditing tutorials. This is manual decompilation exercise 7.

Problem: This is the code to be analysed:

proc near
000 push ebx
004 push esi
008 xor ebx, ebx
008 mov [eax], ebx
008 mov ebx, ecx
008 dec ebx
008 test ebx, ebx
008 jl short loc_408135
008 inc ebx
008 mov ecx, [eax]
008 shl ecx, 4
008 movzx esi, byte ptr [edx]
008 add ecx, esi
008 mov [eax], ecx
008 mov ecx, [eax]
008 and ecx, 0F0000000h
008 test ecx, ecx
008 jz short loc_40812D
008 mov esi, ecx
008 shr esi, 18h
008 xor [eax], esi
008 not ecx
008 and [eax], ecx
008 inc edx
008 dec ebx
008 jnz short loc_40810E
008 pop esi
004 pop ebx
000 retn
sub_408100 endp

Read more…

Categories: MalwareAnalysis Tags:

Writing Self modifying shellcode

July 31st, 2011 1 comment


Nowadays, as I am working on the shellcoding, I thought of writing the self modifying shellcode. Normally, this kind of behaviour is seen in malwares, packers etc, where the code gets modified due to the other instructions. Lets have a look how to do so:


I will be taking the example of MessageBox shellcode. This shellcode I have prepared earlier. Using it as a basis, I would write the self modifying code. The shellcode for MessageBox looks like:


004040A0 31DB       XOR EBX,EBX ;Zero the EBX

004040A2 68 47474700       PUSH 0×00474747 ;PUSH “GGG”

Read more…

Categories: MalwareAnalysis Tags:

Writing Shellcode

July 31st, 2011 No comments

The WinExec shellcode (NASM)


[Section .text]



global _start



JMP GetCmd


POP EBX ;Holds the Pointer to the command string to be executed using WinExec

MOV ECX,1 ;Parameter 2 for WinExec SW_SHOWNORMAL

PUSH ECX ;Push the 2nd param on the stack

PUSH EBX ;Push the first Param

XOR EBX,EBX ;Zero the EBX register

MOV EBX,0x7c86114d ;WinExec address. found it using Arwin utility

CALL EBX ;Call the WinExec


Read more…

Categories: MalwareAnalysis Tags:

Switch to our mobile site