hakers.info

NTGlobalFlag 

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
ntdll!_PEB
   +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

HeapFlags
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
ntdll!_PEB
   +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
ntdll!_HEAP
   +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

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 !!!

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

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 !!!

 

 

 

 

Zi _Crackme (Download crackme)

 Zi_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.

 

10099FE3 REP MOVS DWORD PTR ES:[EDI],DWORD PTR DS:[ESI]

 

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

 

A50183-A50000=183h

So, adding 183h to ESI

1016cb5c+183h=1016CCDF

 

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 !!!!