Trojanizing an application… for good

Actually, the word “patching” instead of “trojanizing” would fit as well, but “trojanize”, which apparently is not even an english word, looks cooler :P

Today I was reading an article, written by the always awesome Didier Stevens, about the new version of EMET. In that article Didier explains how to use EMET in order to allow legacy applications enjoy some of the modern security techniques (DEP, ASLR, SEHOP, etc.)

Although EMET is a very nice tool, I started wondering if a more “intrusive” method would be successful. A method like the binary code inclusion and flow hijacking used in some simple trojan horses.

Just to play a bit I decided to add DEP capabilites to PuTTY, the almighty SSH client :)

Activating DEP for a given binary is a simple thing. This just have to call a Kernel32.dll function name SetProcessDEPPolicy with the right arguments.

In our case, just a Dword argument set to 0x00000001 will do the trick:

Enables DEP permanently on the current process. After DEP has been enabled for the process by setting PROCESS_DEP_ENABLE, it cannot be disabled for the life of the process.


Now I just need to know the address of the function in order to CALL it in x86 ASM. Since the symbols in Kernel32 don’t change among SP and are not ASLR’ed, it’s rather safe to use a hardcoded address.

In order to get this address I just open any binary in Immunity Debugger and search for it by name in the Executable window:

Names in KERNEL32, item 1146


Nice, everything I need now is a good place inside the original binary where to put my new code. No surprise, there’s a huge code cave at the end of the image:



This will be more than enough place since my “shellcode” is really small:

push 0x01

call 7C8622A4

This is the assembler equivalent of the following function call:



I want to reach this code so early as possible, so I’m going to hijack the entry point of the application and redirect the execution flow to my code cave.

Original Entry Point

0044777F > 6A 60 PUSH 60
00447781 68 B8744600 PUSH putty_de.004674B8
00447786 . E8 E91E0000 CALL putty_de.00449674


PATCHED Entry Point

0044777F > E9 5C7D0000 JMP putty_de.0044F4E0
00447784 90 NOP
00447785 90 NOP
00447786 . E8 E91E0000 CALL putty_de.00449674

I need to save the two ASM instructions I overwrite in order to execute them after the “shellcode”.

The following screenshot shows precisely this code, commented. On it you can observe the usual foreign code inclusion armor (PUSHAD/PUSHFD/POPFD/POPAD) which takes care of saving/restoring the state of CPU registers and flags.

The discussed function call is implemented and the original code is placed at the end, finishing with a jump to resume the normal execution flow.

It’s important to note that usually there would be a routine to align back the stack after the “shellcode” (before the POPFD instruction) but in this case the payload is so simple that the only modification is a single push and the function itself takes care of rewinding the stack.

In the screenshot you can see as well that right after the function call, the register EAX contains the value 1. This is the return value of the function, indicating that it was successful.

Saving the changes as “putty_dep.exe” and opening both the original and the trojanized patched PuTTY, we can proof that the modification produced the intended result :) (check the DEP column in Process Explorer)

Isn’t that nice?


UPDATE: Didier Stevens has gone three steps further as usual and wrote some shellcode implementing this functionality. Go Didier! Check it out here.


319 828 534 116


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s