1. Debugging
1.1. Breakpoints
1.1.1. 3 different types
1.1.1.1. Soft BP
1.1.1.1.1. most common
1.1.1.1.2. replaces first byte of original instruction
1.1.1.1.3. original byte must be stored in table
1.1.1.1.4. single bye interrupt 3 instruction (0xCC)
1.1.1.1.5. 2 different types
1.1.1.1.6. drawbacks
1.1.1.2. Hardware BP
1.1.1.2.1. done at CPU level via registers
1.1.1.2.2. raises interrupt 1 (like single stepping)
1.1.1.2.3. limitations
1.1.1.3. Memory BP
1.1.1.3.1. not really BPs, just changes page permissions
1.1.1.3.2. set guard page flag for memory page
1.1.1.3.3. the program code isn't changed
1.1.2. halting process to inspect variables, stack and memory
1.2. Stack
1.2.1. LIFO structure
1.2.2. grows from high memory addresses to low
1.3. Registers
1.3.1. General Purpose
1.3.1.1. EAX
1.3.1.1.1. accumulator register
1.3.1.2. EDX
1.3.1.2.1. data register
1.3.1.3. ECX
1.3.1.3.1. count register
1.3.1.4. ESI
1.3.1.4.1. source index
1.3.1.5. EDI
1.3.1.5.1. destination index
1.3.1.6. ESP
1.3.1.6.1. stack pointer
1.3.1.7. EBP
1.3.1.7.1. base pointer
1.3.1.8. EBX
1.3.1.8.1. nothing specific
1.3.1.8.2. extra storage
1.3.2. EIP
1.3.2.1. instruction pointer
1.3.2.1.1. points to current instruction being executed
2. Malware Analysis
2.1. automated malware must be analyzed in an automated fashion to keep up
2.2. 3 criteria
2.2.1. automatically
2.2.1.1. no user intervention needed
2.2.1.2. generating detailed analysis report
2.2.1.3. machine readable report may be used to initiate automated repsonse procedures like new IDS signatures
2.2.1.4. techniques
2.2.1.4.1. static analysis
2.2.1.4.2. dynamic analysis
2.2.2. effectively
2.2.2.1. all relevant behaviour must be logged
2.2.2.2. no executed functionality of malware should be overlooked
2.2.2.3. techniques
2.2.2.3.1. API hooking
2.2.2.3.2. vm inspection
2.2.3. correctly
2.2.3.1. all logged actions have to be initiated by malware sample
2.2.3.2. techniques
2.2.3.2.1. DLL code injection
2.3. relevant system behaviour
2.3.1. file creation and modification
2.3.2. registry modifications
2.3.3. loaded DLLs
2.3.4. virtual memory access
2.3.5. created processes
2.3.6. network connections
2.3.6.1. destinations
2.3.6.2. contents
2.4. 2 approaches
2.4.1. code analysis
2.4.1.1. static analysis
2.4.1.1.1. source/machine code is analysed in contrast to analysing the behaviour
2.4.1.1.2. sometimes ASCII or UNICODE strings contained in binary reveal functionality and/or insight into MW
2.4.1.1.3. imported libraries and functions disclose included functionality
2.4.2. behaviour analysis
2.4.2.1. dynamic analysis
2.4.2.1.1. execution in simulated/sandboxed environment
2.4.2.1.2. malware is treated as black box
2.4.2.1.3. is similar to HP anlysis
2.4.2.1.4. similar to hi interaction HPs executing malware may affect other systems
2.4.2.1.5. 2 approaches
2.4.2.1.6. completely automated process
2.5. hashing of binaries can be used for unique sample identification
2.5.1. malware countering AV approach
2.5.1.1. polymorhpism
2.5.1.1.1. encrypting or xoring program with changing keys, therefore changing also signature and hash
2.5.1.2. metamorphism
2.5.1.2.1. change whole program without changing programs behaviour
2.6. using virtual environment
2.6.1. system can be easily brought back into clean state
2.6.2. drawbacks
2.6.2.1. detectable
2.6.2.2. slower execution
2.7. same procedure applied to original process must be applied to all subsequently started processes
3. Spreading mechanism
3.1. sequentiell
3.2. random
3.3. hitlist
3.3.1. via special searchengine terms
3.3.2. predefined list of (favorite) targets
4. Rootkits
4.1. stealth
4.1.1. trying to ring no bells so that a real forensic analysis is never applied
4.2. a rootkit is a set of programs and code that allows a permanent or consistent, undetectable presence on a computer
4.3. 2 primary functions
4.3.1. remote command and control
4.3.1.1. control over files
4.3.1.2. command shell
4.3.1.3. general system access and control like reboots
4.3.2. software eavesdropping
4.3.2.1. sniffing packets
4.3.2.2. intercepting keystrokes
4.3.2.3. reading mails/documents
4.3.2.4. capture passwords
4.3.2.5. gain cryptokeys
4.4. rootkits usually use deifferent modification methods
4.4.1. patching
4.4.1.1. replacing parts of binaries to change their behaviour
4.4.2. source-code modifications
4.4.2.1. built in hidden backdoor by developer, may be disguised as a bug
4.4.3. spyware modifications
4.4.3.1. e.g. hooking into existing programs
5. Vulnerability Classes
5.1. Buffer Overflows
5.1.1. Stack Overflows
5.1.1.1. caused by neglect to perform bounds checking on incoming data
5.1.1.2. stack variables have fixed size, cuz compiler preallocates space in machine code
5.1.1.2.1. preallocates max expected data
5.1.1.3. problem
5.1.1.3.1. how to determine correct return address to injected code
5.1.1.4. possibilities to overtake process
5.1.1.4.1. overwriting return address
5.1.1.4.2. change function pointers
5.1.1.4.3. change execution chain of exception handlers
5.1.1.5. automated finding
5.1.1.5.1. 1. search for large stack frames
5.1.1.5.2. 2. find where pointer is used
5.1.1.5.3. 3. make sure access is aware of the size
5.1.1.6. protection
5.1.1.6.1. using a stack canary
5.1.1.6.2. nonexecutable memory
5.1.2. Heap Overflows
5.1.2.1. same idea as stack overflow
5.1.2.1.1. copying data into too small buffers
5.1.2.1.2. may also cause a takeover of the system
5.1.2.1.3. utilize linked list to overwrite memory in process's address space
5.1.2.1.4. less common than stack overflow
5.1.2.2. heap is usually organized as a linked list
5.1.2.2.1. entries store pointers to next and prev entries
5.1.2.3. main problem: miscalculation of buffer size
5.1.2.4. possibility to overwrite data structures of adjacent heap blocks
5.1.2.4.1. variables
5.1.2.4.2. function pointer
5.1.2.4.3. security tokens
5.1.2.4.4. any important data structure stored in heap
5.1.2.5. detection
5.1.2.5.1. program notices not until affected heap blocks are accessed by the program
5.1.2.5.2. e.g. windows allows developers to activate heap verification
5.2. Integer Overflows
5.2.1. result from incorrect treatment of integers
5.2.2. can lead to buffer overflows
5.2.3. safe integer checking is not as trivial as it seems
5.2.3.1. signedness
5.2.3.1.1. JG indicates signed integer comparison
5.2.3.1.2. JA indicates unsigned integer comparison
5.2.3.1.3. signed buffer length variables make no sense
5.2.3.1.4. functions with buffer size can't use signed int
5.2.3.2. arithmetic operations
5.2.3.2.1. arithmetics with user supplied length
5.2.3.2.2. overflown integer will be truncated by processor
5.2.3.2.3. if size of buffer is used to copy data into the new buffer created with overflown int, the new buffer will be overflown
5.2.3.2.4. solution
5.3. Type Conversion Errors
5.3.1. occurs on mishandling of incoming data types and incorrect conversions on them
5.3.2. in C(++) signed will be converted to larger data type as signed no matter what target data type is
5.3.2.1. called signed extending
5.3.3. solution
5.3.3.1. usage of signed and unsigned integers consistently
5.4. Format String Attacks
5.4.1. %n enables to write data to memory
5.4.2. %s enables to read memory until a NULL byte is hit
6. Exploit Counter Measures
6.1. detect memory corruption
6.1.1. GS
6.1.1.1. Guard Stack
6.1.1.1.1. stack cookies/canaries
6.1.2. SEH chain validation
6.1.3. heap corruption detection
6.2. stop common exploitation patterns
6.2.1. ASLR
6.2.1.1. Address Space Layout Randomization
6.2.1.1.1. Stack
6.2.1.1.2. Heap
6.2.1.1.3. images?
6.2.1.1.4. special structures like TEB and PEB on windows
6.2.1.2. the attacker cannot know where exactly stuff is
6.2.2. DEP
6.2.2.1. Data Execute Prevention
6.2.2.2. NX bit
6.2.2.2.1. tells processor which memory isn't executable
6.2.3. SafeSEH
6.2.3.1. Safe Structured Exception Handler
6.2.3.2. Exception function is checked if registered in function table in application
7. Anti-Reversing Methods
7.1. virtual machine detection
7.1.1. changed system behaviour in virtualised environment
7.1.1.1. nonvirtualizabel instructions
7.1.1.1.1. popf instruction
7.1.1.2. resource discrepancies
7.1.1.2.1. TLB (translation look-aside buffer)
7.1.1.3. timing discrepancies
7.1.1.3.1. latency of any two operations may change over time
7.1.1.3.2. resources (like a pci device register) may be available in only a single cycle instead of maybe hundreds cuz of caching
7.1.2. virtual devices may leak information of being in virtual environment
7.1.2.1. name of driver/manufacturer
7.1.2.2. values set in device
7.1.2.2.1. mac address of network card registered to VM product or unregistered at all
7.1.2.3. BIOS versions
7.1.3. some VMs have I/O backdoors to communicate with outside
7.1.4. failures in exactly implementing cpu behaviour
7.1.4.1. easter eggs
7.1.4.1.1. using CPUID with EAX 0x8FFFFFFF on AMD K8 returns IT'S HAMMER TIME in EBX, ECX and EDX
7.2. debugger detection
7.2.1. often platform or debugger specific
7.2.2. IsDebuggerPresent API in PEB
7.2.2.1. SystemKernelDebuggerInformation for kernel debuggers
7.2.3. check if exceptions are "swallowed"
7.2.4. code checksums
7.2.4.1. code is changed when soft breakpoints are set
7.3. anti-debugger code
7.3.1. perform operations that would somehow damage or disable a debugger
7.4. software breakpoint detection
7.5. hardware breakpoint detection
7.5.1. ?
7.6. anti-disassembler tricks
7.6.1. linear sweep disassembler traverse code from top to bottom
7.6.2. recursive traversal take jumps into account when disassembling
7.6.2.1. opaque predicates
7.6.2.1.1. filling junk bytes in nonreachable branches
7.7. eliminating symbolic information
7.7.1. bytecode programs usually contain many textual informations from the source code
7.7.2. export all functions by ordinals rather than name
7.8. obfuscation
7.8.1. control flow transformations
7.8.1.1. inserting opaque predicates
7.8.1.1.1. one branch is never reached
7.8.1.2. table interpretation
7.8.1.2.1. break code sequence into multiple short chunks
7.8.1.3. inlining functions
7.8.1.4. outlining
7.8.1.4.1. create new function for code sequence
7.8.1.5. interleaving code
7.8.1.5.1. split functions into segments and interleave them with opaque predicates
7.8.1.6. ordering transformations
7.8.1.6.1. randomly reorder non-codependent operations to confuse the reverser
7.8.2. data transformations
7.8.2.1. modifying variable encoding
7.8.2.1.1. e.g. shifting loop counter variables all one bit to the left
7.8.2.2. restructuring arrays
7.8.2.2.1. modify arrays preserving functionality but confuse reverser
7.8.2.2.2. merge several arrays to one
7.8.2.2.3. split up array into several
7.9. packing/encrypting code
7.9.1. creates another hurdle for reverser needing to first decrypt or unpack program