This blog post will further build on the basic concepts needed for exploit research and development. We will be walking through the bad character analysis process utilizing Freefloat FTP server – Download Link

This tutorial will build upon our previous post “0x0 Exploit Tutorial: Buffer Overflow – Vanilla EIP Overwrite”, so if you have not already performed the tasks laid out in that post, please do so first. For this article, we will step back to an earlier point in the Freefloat exploit process to detail how one would determine the “bad characters”, or characters that will negatively influence the execution of our exploit or shellcode, for a particular program. To follow on successfully with this blog post, you should have the follow setup prepared:

1. VM platform (Virtualbox, Vmware, etc.)

2. Have a Windows 32-bit XP VM and a Kali Linux or Backtrack 5r3 Linux VM

3. Install Immunity debugger,, and FreeFloat FTP server on the Windows VM

Getting Started:

As previously mentioned, you should have already completed the tutorial (linked above) for the Freefloat FTP server, and should have a baseline exploit to work with. We will be using the (almost) completed skeleton script for our bad character analysis, which has been posted below:

import sys, socket

target = sys.argv[1]

# EIP control after 230 bytes in buffer
# '0x7cb68d7d' - JMP ESP | XP SP3 EN [SHELL32.dll] (C:WINDOWSsystem32SHELL32.dll)

buff = 'x90'*230+'x7dx8dxb6x7c'+'x43'*366

print s.recv(2048)
s.send("USER "+buff+"rn")

At this point, we will go ahead and attach the program in Immunity (CTRL+F1):


We will want to set a breakpoint (F2) at our memory location 0x7c9d30d7:


Run the program (F9), and execute our exploit, and as we can see, we have successfully hit our breakpoint containing our JMP ESP instruction. We can hit F7 to execute the JMP ESP, and you will see that we land in our ‘x43’ C’s, our user controlled memory, which we previously used to store our shellcode.


At this point we have validated that our skeleton exploit is functioning as expected. Our next step will be to replace our ‘x43’ C’s with a listing of every possible character from 0 to 255 in hex format to use in our bad character testing. The characters have been posted below:



As you may notice, ‘x00’ is not listed. This is due to x00 being the hex representation of a null byte, which will immediately terminate the remainder of the shellcode during testing, and is always a bad character.

At this point, we will rerun our exploit, again hitting our breakpoint and stepping into our ‘badchars’ with F7. Now, we will right click the address in the ‘CPU” section of Immunity, and selecting ‘Follow in dump’.

We can start by locating the ’01’ in the hex dump. As we can see it was rendered properly. If we continue along we see that we have ’02’, ’03, ’04’, and so on in order, appearing in order until the point where we should see ‘0A’. As you may notice, our pattern has ceased at ‘0A’ and we can see that this a bad character. We will remove it and resend our buffer, following the same procedure to view the hex dump of our buffer:


This time, we see ‘0D’ has not rendered properly, indicating another bad character. We can repeat this process, removing each bad character in succession until we have successfully rendered all characters in the hex dump.

If you follow the process as detailed, you should determine the list of bad characters(“x00x0ax0d”), with your hex dump appearing as follows:


Now that we have successfully identified our bad characters, you can proceed with your shellcode generation process as usual (referenced in exploit tutorial 0x0 – vanilla EIP overwrite).

If you are looking for additional exploit tutorials check out Offensive Security training, Fuzzy security blog, and Corelan.