Understanding

Process Memory
(Win32)
Software Security Assessment
Lecture 0x02
Keith Makan @k3170makan

Before we start...some toolage!

You will need some tools:

Immunity Debugger http://www.immunitysec.com/products-immdbg.shtml

IDA community Edition https://www.hex-rays.com/products/ida/index.shtml
Windows XP 32bit image (easy to obtain, will drop them at the campus this
week)
Oracle VirtualBox (https://www.virtualbox.org/ )

Some stuff you will probably need to read after this class:

http://rsquared.sdf.org/gdb/mlats.html
http://www.cs.nyu.edu/courses/fall04/V22.0201-003/ia32_chap_03.pdf
http://insecure.org/stf/smashstack.html
https://www.corelan.be/index.php/2009/07/19/exploit-writing-tutorial-part-1stack-based-overflows/

Why is this important?

Its fun to know how processes really work

You will probably get a lot better at debugging your programs
Needed for successful and meaningful exploitation!

Just like for SQL injection you need to know how an SQL statement works, for
memory corruption you need to know how memory works.
Simple work cycle to becoming a memory corruption guru: learn a
memory mechanism -> figure out how to corrupt it -> figure out ways
to bend it to your will.
You are computer scientists, enough said!

Hang on, why windows XP 32 bit?

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

Because it's ridiculously easy to exploit.

Because it's ridiculously easy to exploit.
Because it's ridiculously easy to exploit.
Because it's ridiculously easy to exploit.
Because it's ridiculously easy to exploit.
Because it's ridiculously easy to exploit.
Because it's ridiculously easy to exploit.
Because it's ridiculously easy to exploit.
Because it's ridiculously easy to exploit.
Because it's ridiculously easy to exploit.

Basic work cycle of an executable

1.
2.
3.
4.
5.

6.

Some idiot writes some code (.c,.cpp,etc.)

A compiler generates machine dependent code (raw assembler)
A linker maps in libraries (.DLLs, .sos )
A PE (Portable Executable) File is produced---or on Linux an ELF (Executable and Linkable
Format)
When the PE or ELF is executed; a memory loader maps the sections of the file into memory (.
bss,.data.text , .reloc, etc.)
a. During this phase the OS makes space for the stack and heap memory
b. Marks memory segments with the appropriate access rights
The operating system switches context to the .text section of the file.

This is a gross oversimplification but the important parts are mentioned. It starts with code, then a PE
(ELF) file is created and this is used to construct a memory image.

Some important things to take note of

The Compiler can only control certain attributes of a executable files

behaviour generally speaking
The Operating system can only control attributes that influence the process
during its execution generally speaking

The Compiler cannot control where an executable is loaded into memory for
example (since it would need to know what is executing and what will execute to some extent), and an
operating system cannot influence the contents of a process's code (it would need to
be able to predict the outcome of the code without actually running it).

This difference in responsibility and functionality is important to understand since it will

determines where certain security protections are enforced (at the compiler vs the operating
system!

A little about process memory

Store information needed to run a process.

Memory is read like a file (with random access)
Some parts hold instructions for the CPU to execute .i.e code, libraries
(.text *mostly*)
Other parts hold data targeted by computation (variables, static
values, dynamically assigned variables)
Memory is segments (or areas of memory) are marked with access rights
READ
EXECUTE
WRITE
or any combination of these (see following screenshot) - immunity
debugger*

The practical picture

access rights

Virtual
Memory
offset

Size of
section

memory map (loaded not executing).

A sample memory map (loaded executing)

The Stack

*stolen from corelan.be - because corelan is awesome!

Program Image

DLLs (Imported Code).

.text?

Used to store code that will dictate the processes behaviour

READ ONLY, well it's intended to be so
Corresponds to the .text area of the executable file (usually)

.text?
instructions

raw opcodes

memory offset

.data?

Holds references to values (variables) with non-NULL values at compile

time. Used to reference both global or local variables initialized this way.
i.e. int one=1, the variable one will have an address in the .data
segment
i.e. char *string = this exploit only works on my machine;
The .data can hold both static (immutable values) and non-static variables
i.e. const int one=1, this variables value cannot be changed, but is still
initialized with a non-zero value therefore it goes in the .data

*some compilers prefer to use the rdata section for non-mutable initialized data.

.data?

String values
initialized at
compile time

Variable offset
addresses

Literal values
encoded in hex

Example reference to .data

4

interpretation
Data section contents
Addresses

stack
addresses

values at
addresses

Some good reading sources...

Ive left out a few segments, if youre interested in the full story as far as
executable formats go, check these links out:

http://www.csn.ul.ie/~caolan/pub/winresdump/winresdump/doc/pefile2.html
https://evilzone.org/tutorials/(paper)-portable-executable-format-and-itsrsrc-section/
http://msdn.microsoft.com/en-us/magazine/cc301805.aspx
http://msdn.microsoft.com/en-us/library/ms809762.aspx

Linux

http://www.skyfree.org/linux/references/ELF_Format.pdf
http://wiki.osdev.org/ELF
http://www.linuxjournal.com/article/1059

.stack?

used as a scratch pad for local variables and switching execution

between functions
Used to set up arguments to pass to called functions
Grows in size dynamically toward address 0x0
Works just like the stacks you learned about in Dodds course
Adopted from the stuff Turing wrote about Turing machines only need one
stack and a tape drive (memory) to be able to compute anything =>
modern computers still rely on this fundamental principle.

The stack must provide a way for functions to call other functions and functions
to return to those that called them!
Have a little think about how you would have this work...

Using the Stack

ESP (x86)/RSP (x64) register is used to point to the top of a functions

stack
EBP (x86)/RBP (x64) register is used to point to the bottom of a functions
stack
These registers are used as ways to deference addresses to variables on
the stack.
Facilitates function nesting and recursion
Can also sometimes be used as a place to store dynamic variables (with
runtime dependent size) i.e. emulate a heap!

How the stack works

function A(){

Base
Pointer

function B(){
C();
}
function C(){
D();

Stack
Pointer

bottom
function Bs stack
top
function C stack

}
main(){
A();
}

function Ds stack

Destruction

function As stack

Growth

B();

From the code...

How functions setup their own stacks...

push

ebp

#save the previous functions EBP

calling ebp
calling stack

function
calling

Return Address
calling esp

calling EBP

function
being
called*

called stack
*this stack is still to be set up, this diagram does not reflect its actual size but instead the space it
will occupy

From the code

How functions setup their own stacks...

push

ebp

#save the previous functions EBP

mov

ebp, esp

#grab the current value of EBP and move it to ESP

calling stack

function
calling

Return Address
called ebp
calling EBP
called esp

*function
being
called

*esp and ebp are equal so effectively the stack currently occupies 0 space at the moment

From the code...

How functions setup their own stacks...

push

ebp

#save the previous functions EBP

mov

ebp, esp

#grab the current value of EBP and move it to ESP

push

ebx

#save the EBX value to the stack

calling stack
Return Address

function
calling

calling EBP
called ebp

called esp

calling EBX
called stack

function
being
called*

From the code...

How functions setup their own stacks...

sub

esp, 0Ch

#create space on the stack by sub-ing 0xC = 12 bytes

Return Address
called ebp

calling EBP
calling EBX

called esp

called stack

0xC
addresses

Some notes

The last diagram indicates a fully setup stack ready to rock!

Here the EBX on the stack is not important, its merely saved/preserved as
a convention of the specific function being called. For all intents and
purposes it has nothing to do with setting up the stack in the classical
sense and was clumped in as part of the this example as pure
happenstance.
We have left out a crucial part of this operation in order to simplify
explanation, if youve noticed this or have some questions sit tight were
not done ;)

From the code... (cont.)

How functions destroy their own stacks...

add

esp, 0Ch

#add back the 12 bytes we allocated on the stack

Return Address
called ebp
calling EBP
called esp

calling EBX
called stack

From the code... (cont.)

How functions destroy their own stacks...

pop

ebx

#restore the ebx value we saved

Return Address
called ebp

calling EBP
calling EBX

called esp

called stack

Value placed in
EBX register

From the code... (cont.)

How functions destroy their own stacks...

pop

ebp

#remove the ebx value we saved

calling stack
called ebp
Return Address
called esp

calling EBP

Saved EBP value lets

us know where to
place the bottom
bound of the old
stack
New stack
restored to
original
state

calling EBX
Old stack
called stack

From the code... (cont.)

How functions destroy their own stacks...

retn

#this instruction basically branches execution

calling stack
called ebp
Return Address
called esp

calling EBP

New stack
restored to
original
state

calling EBX
Old stack
called stack

The RETN instruction

Literally
pop eip

Used to branch execution after a process is done executing

Branches execution to whatever is on top of the stack! So this means
it takes the value saved on top of the stack and placed it inside eip.
The processor then expects to find instructions to execute at that address
value. I.e. call *stack[0] execute whatever stack+0 points to!

Hang on...

How does the processor know where to return to?

Where did this magic return address value come from? Who put it there?
What happens to the stack of the previous function when another one is
called?
All these details are hidden in the CALL opcode.
Its actually a shorthand for a bunch of operations (sort of)
Return is almost the perfect inverse of CALL.

The Call instruction explained...

1. Save the current EIP (plus an instructions) to
the stack (so we know where to return to)
2. Load the called location into the EIP
3. Execute as normal...

Stack after call and setup...

calling stack

1.
2.
3.

call instruction saves EIP (+1 instruction)

called function preserves the callers EBP
called function makes space for its stack

Here we have an example where the function

Immunity.004010BB has just been called, before
the next functions prologue began executing.

Return Address
calling EBP

called stack

saved return pointer

popped onto stack

practical example (all together now)

Example here shows a function stack at a random
snapshot during its execution.

Called Stack - set up after the call was

made.
Calling EBP value - the function
that called this ones EBP

Return Address

Some notes

I consider the return address, saved EBP and arguments part of the called
function's stack
This doesnt really matter but you could consider it part of the calling
function's stack given that it is the calling function that loads these
values
But it makes it an easier story to tell from the perspective of memory
corruption given that the calling function corrupts this data.
You could also think of the calling function as preparing the stack by
placing these values in the called stack.

What about function arguments?

What happens when a function has arguments?

How is this handled according to the mechanics of the stack?

Well

All functions passed to a callee (function being called) need to be accessible locally (via the its
stack).
The calling function will push these arguments onto its stack in REVERSE order before making
the call and branching execution to the callee. *on some architectures the EDI and ESI are used
to store points to arguments before the stack is used to store them when calling a function
(optimization effort)*

And Then

The callee will reference these arguments outside of its stack by using registers (EBP, ESP)

References and further reading

Make sure to soak these up before the next lecture ;)

Smashing the stack in 2010 http://www.mgraziano.info/docs/stsi2010.pdf

Smashing the stack for fun and profit http://insecure.org/stf/smashstack.html
Exploit Writing tutorial part 1 : Stack Overflows https://www.corelan.be/index.
php/2009/07/19/exploit-writing-tutorial-part-1-stack-based-overflows/
Part 1 : Introduction to Exploit Development https://www.fuzzysecurity.com/tutorials/expDev/1.
html