This presentation is from a hands-on session that happened at the Hacker Thursdays series of OWASP Bay Area delivered by Gábor, Co-Founder and CTO at Avatao. Join our meetup at https://www.meetup.com/Bay-Area-OWASP and follow @OWASPBayArea on Twitter and Instagram to keep up with the latest updates and chapter events. Details: As the topic itself is quite complex and deep, we don’t aim at digging into the details of any of the memory corruption errors (e.g., stack or heap overflow). Rather the goal is to get a bit of understanding of CPU internals, the assembly language, the goal of debuggers, program memory layouts and basic exploitation techniques. This information will help us to analyze binaries together and find ways to misuse them. This session intends to give an appetizer to those who spend most of their time with recent web technologies, but interested to understand a little bit the nature of the underlying native world. The exercises are going to be hosted on the Avatao framework, so everybody can easily join to solve them. Trainer: Gábor is a co-founder and CTO at Avatao, a cloud-based virtual lab to teach people build secure software and systems. He earned his Ph.D. degree in 2015 from the CrySyS Lab of Budapest University of Technology and Economics, but completed internships at iSecLab at Eurecom, France and TU Wien, Austria, too. His main research focus was on malware analysis and virtualization security. One of the vulnerabilities he found (XSA-59/CVE[masked]) affected several Intel chipsets that enabled attacks against hypervisors such as Xen or KVM. He was one of the key members of the Duqu, Flame, Miniduke and Teamspy targeted attack investigation teams. He founded and coordinated CrySyS Student Core for almost 5 years, which was an invite-only group of exceptionally talented students interested in system security. This group gave birth to the "!SpamAndHex" (https://ctftime.org/team/5347) CTF team, which became one of the top teams in the world in 2 years. As a member of !SpamAndHex he is a three-times DEFCON CTF finalist, that is widely regarded as the hacker world championship. Over the years, he gave talks at several cyber security conferences in the academia (e.g., ACM AsiaCCS, ESORICS, USENIX ASE ) and industry (e.g., DevSecCon, POC, Belluminar, Hacktivity).

1. An introduction to binary
exploitation
Gábor Pék

2. About me
● Co-founder and CTO at Avatao
● PhD in virtualization and malware security (CrySyS Lab)
● Virtualization hacks (e.g., XSA-59)
● Research of advanced malware (e.g., Duqu, Flame)
● Co-founder of !SpamAndHex (3x DEFCON CTF Finalist team)

3. So why this topic?

4. https://www.theverge.com

5. Let’s begin
LSzekeres,MPayer,WeiTao,DSong:SoK–EternalWarinMemory,IEEE
SecurityandPrivacy,2013

6. Maybe at another time :)
LSzekeres,MPayer,WeiTao,DSong:SoK–EternalWarinMemory,IEEE
SecurityandPrivacy,2013
X

7. First, Understand the basics
● Compilers (native, JIT, AOT) vs. interpreters
● Native binaries
○ compiled from C, C++ or Rust for example
● Loaders
● Program memory layout
● CPU instructions and registers including Assembly
● Type of bugs

8. interpreters
“An interpreter executes some
representation of a program’s source
file at run- time.”
Randall Hyde

9. Compilers
“A compiler translates a source
program in text form into executable
machine code.”
Randall Hyde

10. COMPILATION PROCESS (SIMPLIFIED)
Source
code
Analysis
Optimization
Code generation
Machine
code

11. Example Source code
Machine (object) code

12. Basic x86 system
Source: [1]

13. Cpu registers (32-bit)
Source: [1]

14. Interested in architecture internals? :D
Intel® 64 and IA-32 Architectures
Software Developer Manuals
(4846 pages)

15. Assembly basics
Assembler language is the
representation of machine code in
human readable form

16. assembly instructions
AT&T syntax: <instruction (mnemonic)>
<source>, <destination>
Intel syntax: <instruction (mnemonic)>
<destination>, <source>

17. Machine code vs Assembly

18. So how to store data in memory?
Stack: Built up from stack frames of
functions, LIFO, grows downwards
Heap: Dynamically allocated
memory, grows upwards

19. ELF binary in memory … too much for today

20. Function call example
int main(void){
int a, b, c;
a=7;
b=3;
c = addnum(a,b);
printf("%d", c);
}
int addnum(int a, int b){
int c = 4;
c = a + b;
return c;
}

21. Stack frame example (x86)
Free memory
← ESP
Local variables
Saved EBP
Previous frame
Return address
Function parameters
← EBP
Higher memory
addresses

22. Stack frame before function call (x86)
Free memory
← ESP
Lower memory
addresses
stack pointer, points to
the top of the stack frame

23. second function parameter placed first
Free memory
← ESP
Lower memory
addresses
3 (b) int main(void){
int a, b, c;
a=7;
b=3;
c = addnum(a,b);
printf("%d", c);
}

24. First function parameter placed after
Free memory
← ESP
Lower memory
addresses
3 (b) int main(void){
int a, b, c;
a=7;
b=3;
c = addnum(a,b);
printf("%d", c);
}
7 (a)

25. Place return address (Address of next instruction)
Free memory
← ESP
Lower memory
addresses
3 (b) int main(void){
int a, b, c;
a=7;
b=3;
c = addnum(a,b);
printf("%d", c);
}
7 (a)
Return address
& __asm__ add esp, 8

26. Place the Base pointer of the previous stack frame
Free memory
← ESP
Lower memory
addresses
3 (b) int addnum(int a, int b){
int c = 4;
c = a + b;
return c;
}
7 (a)
Return address
Saved EBP
__asm__ push ebp
__asm__ mov ebp, esp
__asm__ sub esp, 0x10

27. Align the base pointer to the current stack frame
Free memory
← ESP,
Lower memory
addresses
3 (b) int addnum(int a, int b){
int c = 4;
c = a + b;
return c;
}
7 (a)
Return address
Saved EBP
__asm__ push ebp
__asm__ mov ebp, esp
__asm__ sub esp, 0x10
EBP

28. Create space for local variables
Free memory
← EBP
Lower memory
addresses
3 (b) int addnum(int a, int b){
int c = 4;
c = a + b;
return c;
}
7 (a)
Return address
Saved EBP
__asm__ push ebp
__asm__ mov ebp, esp
__asm__ sub esp, 0x10
← ESP
Space for local variables

29. Let’s return: delete local variables from stack frame
Free memory
← EBP
Lower memory
addresses
3 (b) int addnum(int a, int b){
int c = 4;
c = a + b;
return c;
}
7 (a)
Return address
Saved EBP
...
ESP
__asm__ mov esp, ebp
__asm__ pop ebp
__asm__ ret

30. restore ebp to its previous value
Free memory
←ESP
Lower memory
addresses
3 (b) int addnum(int a, int b){
int c = 4;
c = a + b;
return c;
}
7 (a)
Return address
...
__asm__ mov esp, ebp
__asm__ pop ebp
__asm__ ret

31. Return to the address we saved before
Free memory
←ESP
Lower memory
addresses
3 (b) int addnum(int a, int b){
int c = 4;
c = a + b;
return c;
}
7 (a) ...
__asm__ mov esp, ebp
__asm__ pop ebp
__asm__ ret

32. Caller cleans the stack from function parameters
Free memory
←ESP
Lower memory
addresses
int main(void){
int a, b, c;
a=7;
b=3;
c = addnum(a,b);
printf("%d", c);
}
__asm__ add esp, 8

33. What about 64-bit mode (e.g.,System V AMD64) ?
Function parameters are put into CPU
registers like
RDI,RSI,RDX,RCX,R8,R9,XMM0-7

34. Debuggers (E.g., GDB, WinDBG, IDA)
Understand the runtime behaviour of
a program

35. Memory corruption errors
Attackers can read or write
arbitrary memory locations of a
vulnerable program

36. Vulnerability Examples
Stack overflow, heap overflow,
integer overflow format string,
use-after-free, ...

37. Protections
Stack canaries, DEP, ASLR, Control
and Data Flow Integrity, using safe
libraries, ...

38. Some exploitation techniques
Return to LibC, ROP, JOP, GOT
hijacking, Off-by-one, ...

39. Maybe next time
LSzekeres,MPayer,WeiTao,DSong:SoK–EternalWarinMemory,IEEE
SecurityandPrivacy,2013

40. My two cents
Write less and more secure code :)

41. Readings
[1] Randall Hyde: Write Great Code, Volume 2 - Thinking
low-level, writing high-level, No Starch Press, 2006
[2] L Szekeres, M Payer , Wei Tao, D Song : SoK – Eternal
War in Memory, IEEE Security and Privacy, 2013
[3] Intel® 64 and IA-32 Architectures Software Developer
Manuals, 2016

42. Huge thanks for coming!
Questions? gabor.pek@avatao.com