Post on 07-Jul-2018
8/18/2019 Understanding Process Memory
1/39
Understanding
Process Memory(Win32)
Software Security AssessmentLecture 0x02Keith Makan @k3170makan
8/18/2019 Understanding Process Memory
2/39
Before we start...some toolage!
You will need some tools:● Immunity Debugger http://www.immunitysec.com/products-imm
● ID A community Edition https://www.hex-rays.com/products/ida
● Windows XP 32bit image (easy to obtain, will drop them at the
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
● http://insecure.org/stf/smashstack.html
● https://www.corelan.be/index.php/2009/07/19/exploit-writing-tu
stack-based-overflows/
http://insecure.org/stf/smashstack.htmlhttp://insecure.org/stf/smashstack.htmlhttp://insecure.org/stf/smashstack.htmlhttp://rsquared.sdf.org/gdb/mlats.htmlhttp://rsquared.sdf.org/gdb/mlats.htmlhttps://www.hex-rays.com/products/ida/index.shtmlhttp://www.immunitysec.com/products-immdbg.shtmlhttp://www.immunitysec.com/products-immdbg.shtmlhttps://www.corelan.be/index.php/2009/07/19/exploit-writing-tutorial-part-1-stack-based-overflows/https://www.corelan.be/index.php/2009/07/19/exploit-writing-tutorial-part-1-stack-based-overflows/http://insecure.org/stf/smashstack.htmlhttp://www.cs.nyu.edu/courses/fall04/V22.0201-003/ia32_chap_03.pdfhttp://rsquared.sdf.org/gdb/mlats.htmlhttps://www.virtualbox.org/https://www.hex-rays.com/products/ida/index.shtmlhttp://www.immunitysec.com/products-immdbg.shtml
8/18/2019 Understanding Process Memory
3/39
Why is this important?
● It’s 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 statemen
memory corruption you need to know how memory works.
○ Simple work cycle to becoming a memory corruption guru
memory mechanism -> figure out how to corrupt it -> figureto bend it to your will.
● You are computer scientists, enough said!
8/18/2019 Understanding Process Memory
4/39
Hang on, why windows XP 32 b
1. Because it's ridiculously easy to exploit.
2. Because it's ridiculously easy to exploit.3. Because it's ridiculously easy to exploit.
4. Because it's ridiculously easy to exploit.
5. Because it's ridiculously easy to exploit.
6. Because it's ridiculously easy to exploit.
7. Because it's ridiculously easy to exploit.
8. Because it's ridiculously easy to exploit.
9. Because it's ridiculously easy to exploit.
10. Because it's ridiculously easy to exploit.
8/18/2019 Understanding Process Memory
5/39
Basic work cycle of an executa
1. Some idiot writes some code (.c,.cpp,etc.)
2. A compiler generates machine dependent code (raw assembler)3. A linker maps in libraries (.DLLs, .so’s )
4. A PE (Portable Executable) File is produced---or on Linux an ELF (Executable aFormat)
5. When the PE or ELF is executed; a memory loader maps the sections of the file
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 rights6. 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 c(ELF) file is created and this is used to construct a memory image.
8/18/2019 Understanding Process Memory
6/39
Some important things to take note of
● The Compiler can only control certain attributes of a executablbehaviour generally speaking
● The Operating system can only control attributes that influence
during its execution generally speaking
The Compiler cannot control where an executable is loaded into me
example (since it would need to know what is executing and what will execute to some extent),
operating system cannot influence the contents of a process's codebe able to predict the outcome of the code without actually running it).
This difference in responsibility and functionality is important to understand sindetermines where certain security protections are enforced (at the compiler vs thsystem!
8/18/2019 Understanding Process Memory
7/39
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 co
(.text *mostly*)
○ Other parts hold data targeted by computation (variables,
values, dynamically assigned variables)
● Memory is segments (or areas of memory) are marked with ac○ READ
○ EXECUTE
○ WRITE
○ or any combination of these (see following screenshot) - im
debugger*
8/18/2019 Understanding Process Memory
8/39
The practical picture
access right
VirtualMemory
offset
Size of
section
8/18/2019 Understanding Process Memory
9/39
memory map (loaded not execu
8/18/2019 Understanding Process Memory
10/39
A sample memory map (loaded execu
8/18/2019 Understanding Process Memory
11/39
The Stack
●
*stolen from corelan.be - becaus
8/18/2019 Understanding Process Memory
12/39
Program Image
8/18/2019 Understanding Process Memory
13/39
DLLs (Imported Code).
8/18/2019 Understanding Process Memory
14/39
.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)
8/18/2019 Understanding Process Memory
15/39
.text?
memory offset
8/18/2019 Understanding Process Memory
16/39
.data?
● Holds references to values (variables) with non-NULL values a
time. Used to reference both global or local variables initialized
○ i.e. int one=1, the variable ‘one’ will have an address in the
segment
○ i.e. char *string = “this exploit only works on my machine”;
● The .data can hold both static (immutable values) and non-stat
○ i.e. const int one=1, this variable’s value cannot be changeinitialized with a non-zero value therefore it goes in the .da
*some compilers prefer to use the rdata section for non-mutable ini
8/18/2019 Understanding Process Memory
17/39
.data?
Literal values
encoded in hexVariable offsetaddresses
8/18/2019 Understanding Process Memory
18/39
Example reference to .data
4
Data section contents
Addresses
stackaddresses
values ataddresses
interpr
8/18/2019 Understanding Process Memory
19/39
Some good reading sources...
I’ve left out a few segments, if you’re interested in the full story as fa
executable formats go, check these links out:
● http://www.csn.ul.ie/~caolan/pub/winresdump/winresdump/doc
● https://evilzone.org/tutorials/(paper)-portable-executable-forma
rsrc-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
http://wiki.osdev.org/ELFhttp://wiki.osdev.org/ELFhttp://msdn.microsoft.com/en-us/magazine/cc301805.aspxhttp://msdn.microsoft.com/en-us/magazine/cc301805.aspxhttps://evilzone.org/tutorials/(paper)-portable-executable-format-and-its-rsrc-section/https://evilzone.org/tutorials/(paper)-portable-executable-format-and-its-rsrc-section/http://www.linuxjournal.com/article/1059http://wiki.osdev.org/ELFhttp://www.skyfree.org/linux/references/ELF_Format.pdfhttp://msdn.microsoft.com/en-us/library/ms809762.aspxhttp://msdn.microsoft.com/en-us/magazine/cc301805.aspxhttps://evilzone.org/tutorials/(paper)-portable-executable-format-and-its-rsrc-section/https://evilzone.org/tutorials/(paper)-portable-executable-format-and-its-rsrc-section/http://www.csn.ul.ie/~caolan/pub/winresdump/winresdump/doc/pefile2.html
8/18/2019 Understanding Process Memory
20/39
.stack?
● used as a “scratch pad” for local variables and switching execu
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 Dodd’s course
● Adopted from the stuff Turing wrote about Turing machines on
stack and a tape drive (memory) to be able to compute anythinmodern computers still rely on this fundamental principle.
The stack must provide a way for functions to call other functions a
to return to those that called them!
○ Have a little think about how you would have this work...
8/18/2019 Understanding Process Memory
21/39
8/18/2019 Understanding Process Memory
22/39
How the stack works
function A(){
B();
}
function B(){
C();
}
function C(){
D();
}
main(){
A();
}
f unction A’s stac
function B’s stac
function C’ stack
function D’s stac
G r o w t h
BasePointer
Stack
Pointer
bo
to
8/18/2019 Understanding Process Memory
23/39
From the code...How functions setup their own stacks...
push ebp #save the previous functions EBP
calling stack
calling EBP
calling ebp
calling esp
called stack
*this stack is still to be set up, this diagram does not reflect its actual size but inste
will occupy
Return Address
8/18/2019 Understanding Process Memory
24/39
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
calling stack
calling EBP
called ebp
called esp
*esp and ebp are equal so effectively the stack currently occupies 0 space at th
Return Address
8/18/2019 Understanding Process Memory
25/39
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
push ebx #save the EBX value to the stack
calling stack
calling EBP
called ebp
called esp called stack
fuca
fu
beca
calling EBX
Return Address
8/18/2019 Understanding Process Memory
26/39
From the code...How functions setup their own stacks...
sub esp, 0Ch #create space on the stack by sub-ing
called ebp
called espcalled stack
calling EBP
calling EBX
Return Address
8/18/2019 Understanding Process Memory
27/39
Some notes
● The last diagram indicates a fully setup stack ready to rock!
● Here the EBX on the stack is not important, it’s merely saved/pa convention of the specific function being called. For all intents
purposes it has nothing to do with setting up the stack in the cl
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 simp
explanation, if you’ve noticed this or have some questions sit ti
not done ;)
F th d ( t )
8/18/2019 Understanding Process Memory
28/39
From the code... (cont.)How functions destroy their own stacks...
add esp, 0Ch #add back the 12 bytes we allocated on the s
called ebp
called esp
called stack
calling EBP
calling EBX
Return Address
F th d ( t )
8/18/2019 Understanding Process Memory
29/39
From the code... (cont.)How functions destroy their own stacks...
pop ebx #restore the ebx value we saved
called ebp
called espcalled stack
calling EBP
calling EBX
V
Return Address
F th d ( t )
8/18/2019 Understanding Process Memory
30/39
From the code... (cont.)How functions destroy their own stacks...
pop ebp #remove the ebx value we saved
calling stack
calling EBP
called ebp
called esp
called stack
New st
restoreoriginastate
Old sta
Saveus kn
placebounstack
calling EBX
Return Address
F th d ( t )
8/18/2019 Understanding Process Memory
31/39
From the code... (cont.)How functions destroy their own stacks...
retn #this instruction basically branches executi
calling stack
calling EBP
called ebp
called esp
called stack
New st
restoreoriginastate
Old sta
calling EBX
Return Address
8/18/2019 Understanding Process Memory
32/39
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
it takes the value saved on top of the stack and placed it inside
● The processor then expects to find instructions to execute at th
value. I.e. call *stack[0] ← execute whatever stack+0 points to!
8/18/2019 Understanding Process Memory
33/39
Hang on...
● How does the processor know where to return to?
● Where did this magic return address value come from? Who p● What happens to the stack of the previous function when anoth
called?
● All these details are hidden in the CALL opcode.
○ It’s actually a shorthand for a bunch of operations (sort of)
● Return is almost the perfect inverse of CALL.
8/18/2019 Understanding Process Memory
34/39
The Call instruction explained..
1. Save the current EIP (plus an instructthe stack (so we know where to return
2. Load the called location into the EIP
3. Execute as normal...
8/18/2019 Understanding Process Memory
35/39
Stack after call and setup...
1. call instruction saves EIP (+1 instruction)
2. called function preserves the caller’s EBP3. called function makes space for its stack
cal
cal
ca
Retu
savepop
Here we have an example where the function
Immunity.004010BB has just been called, beforethe next functions prologue began executing.
8/18/2019 Understanding Process Memory
36/39
practical example (all together n
Called Stack - set up after thmade.
Calling EBP value - the
that called this one’s EBP
Return Address
Example here shows a function stack a
snapshot during its execution.
8/18/2019 Understanding Process Memory
37/39
Some notes
● I consider the return address, saved EBP and arguments part
function's stack○ This doesn’t really matter but you could consider it part of
function's stack given that it is the calling function that loa
values
○ But it makes it an easier story to tell from the perspective o
corruption given that the calling function corrupts this data
○ You could also think of the calling function as preparing th
placing these values in the called stack.
8/18/2019 Understanding Process Memory
38/39
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 locstack).
● The calling function will push these arguments onto its stack in REVERSE order
the call and branching execution to the callee. *on some architectures the EDI anto store points to arguments before the stack is used to store them when calling
(optimization effort)* And Then…
● The callee will reference these arguments outside of its stack by using registers
R f d f th di
8/18/2019 Understanding Process Memory
39/39
References and further readingMake 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/tutori
html
https://www.fuzzysecurity.com/tutorials/expDev/1.htmlhttps://www.fuzzysecurity.com/tutorials/expDev/1.htmlhttps://www.corelan.be/index.php/2009/07/19/exploit-writing-tutorial-part-1-stack-based-overflows/https://www.corelan.be/index.php/2009/07/19/exploit-writing-tutorial-part-1-stack-based-overflows/http://insecure.org/stf/smashstack.htmlhttp://www.mgraziano.info/docs/stsi2010.pdf