the walking 0xdead

93
Inspecting and Manipulating binaries

Upload: carlos-garcia-prado

Post on 29-Nov-2014

353 views

Category:

Technology


7 download

DESCRIPTION

A short training introducing binary reverse engineering in x86. Some application to malware is presented as well. The actual training is hands on and contains a software package for the participants.

TRANSCRIPT

Page 1: The walking 0xDEAD

Inspecting and Manipulating binaries

Page 2: The walking 0xDEAD

Introduction.

x86 architecture. Assembler.

Binary inspection.

General sample (crackme)

Binary manipulation.

Python to the rescue!

Malware analysis

What we (you) are going to do 2

Page 3: The walking 0xDEAD

Welcome to the city of death 3

Page 4: The walking 0xDEAD

Braaaaiiinnnssss 4

$ whoami

4

Page 5: The walking 0xDEAD

Binary Reverse Engineering Malware Programming The walking dead

5

$ whoami

Binary Reverse Engineering

5

Page 6: The walking 0xDEAD

Yeah, but what is reversing ???

6

Kind of a reconstruction

Code Binary

int main(int argc, char **argv) push ebp

{ mov ebp, esp

int gv = 0; // global mov dword_403394, 0

[…] […]

Page 7: The walking 0xDEAD

Requisites

ASM knowledge

Binary format (PE32, etc.)

OS Knowledge

Patience ;)

so, i want to do some reversing

7

Page 8: The walking 0xDEAD

At the beginning, there was c0de

#include "stdafx.h"

#include <iostream> using namespace std;

int add(int x, int y)

{ return x + y; }

int main() {

int a = 0, b = 0; cout << "Enter a: ";

[…] return 0; }

8

Page 9: The walking 0xDEAD

The compiler fucks it all up

9

Page 10: The walking 0xDEAD

compiling is like...

… that scene of Apollo XIII

10

Page 11: The walking 0xDEAD

It may hurt a little bit… 11

Page 12: The walking 0xDEAD

Bytes :: opcodes

12

Page 13: The walking 0xDEAD

Opcodes :: basic blocks

13

Page 14: The walking 0xDEAD

Basic blocks :: functions

14

Page 15: The walking 0xDEAD

Cpu registers

„General purpose“ registers:

eax, ebx, ecx, edx, esi, edi, ebp, esp

32 bits (64 bits in x86_64)

Some of them have special uses.

„The rootkit arsenal“ Bill Blunden

It may hurt a little bit… 15

Page 16: The walking 0xDEAD

Cpu registers

Not so „general purpose“ registers:

eax: Arithmetic and function return values

ecx: counter (loops, etc.)

esi, edi: src, dst in memcpy, strcpy, etc.

ebp, esp: stack operations :)

and more...

It may hurt a little bit… 16

Page 17: The walking 0xDEAD

Some common instructions

Read

mov eax, [ecx]

mov eax, [00401000]

Write

mov ebx, 0x20

mov [ebx+0x1C], ecx

It may hurt a little bit… 17

Page 18: The walking 0xDEAD

Some common instructions

push

push 0x100

push dword_1377

pop

pop ecx

pop 0x00c0ffee

It may hurt a little bit… 18

Page 19: The walking 0xDEAD

Some common instructions

inc, dec

mul, div Use your imagination :)

add, sub

add esp, 0x08

sub esp, 0x1c

It may hurt a little bit… 19

Page 20: The walking 0xDEAD

Some common instructions

lea dst, src

lea eax, [esi*2]

lea ecx, [esi+ecx]

shl, shr

shl eax, 2

It may hurt a little bit… 20

Page 21: The walking 0xDEAD

Some common instructions

jxx dst

jmp 0xbadc0de

jnz eax

ja 0xc0ffee

jl ebx

t

call 0x00412F1E

It may hurt a little bit… 21

Page 22: The walking 0xDEAD

Some common instructions

cmp dst, src

cmp eax, ebx

cmp ecx, 0xFF

test dst, src

test ecx, edx

It may hurt a little bit… 22

Page 23: The walking 0xDEAD

Important segments

.data: statically allocated *initialized*

int g = 1; char str[] = „yomamma“;

.bss: statically allocated *UNinitialized*

int var; char *ptr;

.rdata: read-only data (const c = 0)

It may hurt a little bit… 23

Page 24: The walking 0xDEAD

It‘s all about the .(r)data

It may hurt a little bit… 24

Page 25: The walking 0xDEAD

Moar data

It may hurt a little bit… 25

Page 26: The walking 0xDEAD

Moar data

It may hurt a little bit… 26

Page 27: The walking 0xDEAD

Imports and all that stuff…

It may hurt a little bit… 27

Page 28: The walking 0xDEAD

The problem with imports

Problem: O(n2) vs. O(n)

„Thunks and dynamic resolution makes the binary *portable* between Windows versions.

XP and Win7 don‘t have the same addresses for all

kernel32 functions

It may hurt a little bit… 28

Page 29: The walking 0xDEAD

thunks Regular call

Opcode: 0xE8 + offset

Memcpy = thunk (nur jmp)

Not resolved yet

It may hurt a little bit… 29

Page 30: The walking 0xDEAD

“direct“ import calls call ds:xxx

Opcodes: 0xFF15 + absolut address

Not resolved yet

It may hurt a little bit… 30

Page 31: The walking 0xDEAD

Page based (4 KB pages, arch dependent)

Pages (virtual mem.) -> page tables -> page frames

(physical mem.)

Pages have several attributes:

User / Supervisor (Kernel)

read-only, read-write, read-execute, etc.

Memory is not disk, dough! 31

Page 32: The walking 0xDEAD

Picture: CC Hameed, (http://blogs.technet.com) 32

Page 33: The walking 0xDEAD

Picture: Bill Blunden (The Rootkit Arsenal) 33

Page 34: The walking 0xDEAD

Application starts. Process is generated. Process = running instance of an application.

Processes are separated from each other.

Every process gets its own virtual address space (32-bit: 4 GB)

A process is a container (own VM, Handles, Threads (min.1)) Thread = context execution of a process.

Multithreading.

Shares system resources (Code, Data, Handles)

Own stack, though.

Thread Local Storage.

Threads (within a process) can share memory.

Processes and Threads 34

Page 35: The walking 0xDEAD

Important data structures in every process

PEB: Process Environment Block (1 pro Process) Location of executable (ImageBase)

Information about DLLs

Information regarding the heap

TEB: Thread Environment Block (1 pro Thread) Location of the PEB

Location of the stack

Pointer to first SEH Chain entry

PEB vs. TEB 35

Page 36: The walking 0xDEAD

Process memory segmentation:

Code (.text): like the segment on disk

Data (.data): like the segment on disk

Stack: function arguments, local variables

Grows towards lower addresses

Defined through top (ESP) and bottom (EBP)

PUSH vs POP (dword)

Heap: managed by Allocator/Deallocator algorithms

Two new segments 36

Page 37: The walking 0xDEAD

4GB

2GB Picture courtesy of CORELAN Copyright (c) Corelan GCV

37

Use

r la

nd

K

ern

el l

and

Page 38: The walking 0xDEAD

Open cmd.exe in ImmunityDebugger

Time to take a peek 38

Page 39: The walking 0xDEAD

Time to take a peek 39

Page 40: The walking 0xDEAD

Time to take a peek 40

Page 41: The walking 0xDEAD

The stack . Push & pop.

It may hurt a little bit… 41

Page 42: The walking 0xDEAD

Function prologue

It may hurt a little bit… 42

Page 43: The walking 0xDEAD

function calls

Different types:

cdecl (C progs, variable arg number)

Caller* is responsible for adjusting the stack.

How many args were there? Unknown

stdcall (windows API, fixed arg number)

Function self adjusts the stack before return.

It's clear in advance how many arguments

_funcName@nrBytes

It may hurt a little bit… 43

Page 44: The walking 0xDEAD

Argument passing

It may hurt a little bit… 44

Page 45: The walking 0xDEAD

Argument passing ( by ref )

It may hurt a little bit… 45

Page 46: The walking 0xDEAD

Argument passing ( by ref )

It may hurt a little bit… 46

Page 47: The walking 0xDEAD

Argument passing ( by value )

It may hurt a little bit… 47

Page 48: The walking 0xDEAD

Argument passing ( by value )

It may hurt a little bit… 48

Page 49: The walking 0xDEAD

Go home Compiler, you are drunk

#include <stdio.h> int main(void) { char x = 0xff; if(x == 0xff) puts("YES"); else puts("NO"); return 0; }

sign extensions from hell 49

Page 50: The walking 0xDEAD

Time to take a peek 50

Page 51: The walking 0xDEAD

There is NOT such thing as static reversing ONLY

Combine static (IDA) and dynamic (debugger).

The trick is to optimize the information transfer

between these two.

Best of both worlds 51

Page 52: The walking 0xDEAD

Examples:

IDA debugging capabilities

Dynamic Binary Instrumentation (PIN).

Import results in IDA to see code coverage

Trace with .py

Differential debugging

Best of both worlds 52

Page 53: The walking 0xDEAD

53

Page 54: The walking 0xDEAD

Not really scary… 54

Page 55: The walking 0xDEAD

Don't get distracted! 55

Page 56: The walking 0xDEAD

Look, it works! 56

Page 57: The walking 0xDEAD

Loooooong function 57

Page 58: The walking 0xDEAD

Don't really feel like doing this manually 58

Page 59: The walking 0xDEAD

We will solve this soon… intelligently 59

F*ck this shit I'm outta here!

Page 60: The walking 0xDEAD

Take the control! 60

Page 61: The walking 0xDEAD

Not elegant but effective… 61

Page 62: The walking 0xDEAD

I want more… finesse… 62

Page 63: The walking 0xDEAD

Python to the rescue!

Tzzzzzz. Tttzzzz… 63

Page 64: The walking 0xDEAD

Python to the rescue!

If it‘s in twitter it must be true 64

Page 66: The walking 0xDEAD

Example: utorrent readfile

Page 67: The walking 0xDEAD

Which ReadFile ?!?!

There are several references…

Manually inspecting all is a tedious job. 67

Page 68: The walking 0xDEAD
Page 69: The walking 0xDEAD

Reading from a File

CreateFile(...)

Returns handle

ReadFile(handle)

CloseHandle(handle)

Page 70: The walking 0xDEAD

Reading from a File

It's a long shot 70

Page 71: The walking 0xDEAD

And... found!

It's a long shot 71

Page 72: The walking 0xDEAD

Binary manipulation

Binaries can be easily modified Patched (on disk, live) Functions intercepted (hooking, live)

Usage:

Inspection (ex. Tracing) Change execution flow Whatever you can imagine

Page 73: The walking 0xDEAD

What you all have been waiting for… 73

Page 74: The walking 0xDEAD

Braaaaiiinnnsss… I mean, credeeeennttiiiaaalllssssss… 74

So many questions…

APIs used to send() and recv() data?

Sure? Think twice

Functions I don't see?

What happens with the data received?

How does the malware achieve persistency?

Page 75: The walking 0xDEAD

Braaaaiiinnnsss… I mean, credeeeennttiiiaaalllssssss… 75

Page 76: The walking 0xDEAD

Malware are deceiving bastards… 76

Are these the

ONLY APIs

used by this malware?

Page 77: The walking 0xDEAD

Braaaaiiinnnsss… I mean, CPU cycles… 77

Page 78: The walking 0xDEAD

I like it here. I think I‘m gonna stick for a while… 78

How does the malware

achieve

persistency?

Page 79: The walking 0xDEAD

Braaaaiiinnnsss… I mean, CPU cycles… 79

Page 80: The walking 0xDEAD

Getting in the enemy's mind 80

Page 81: The walking 0xDEAD

Hands on: STRINGS

Juicy info in two minutes 81

Page 82: The walking 0xDEAD

Hands on: imports

Very interesting imports… 82

Page 83: The walking 0xDEAD

Hands on: resources

The .rsrc section is perfect for hiding data 83

Page 84: The walking 0xDEAD

"Crypto" stuff

Takes less time and is less brain damaging 84

Page 85: The walking 0xDEAD

Hands on: sneaky bastards

I see what you did there… 85

Page 86: The walking 0xDEAD

86

There are so many! What Do i do?!?!?

Page 87: The walking 0xDEAD

Who are u gonna call? Sneakbuster!

Takes less time and is less brain damaging 87

Page 88: The walking 0xDEAD

Hands on: WTFTLS

NO ME GUSTA 88

Page 89: The walking 0xDEAD

Hands on: WTFTLS

Call, call, call … 89

Page 90: The walking 0xDEAD

Hands on: running it

Thanks for the info… 90

Page 91: The walking 0xDEAD

Hands on: running it

Here's (another?) candy for you… 91

Page 92: The walking 0xDEAD

Last chance! ;) 92

Page 93: The walking 0xDEAD

Twitter: @m0n0sapiens 93