anti-analysis.md (4009B)
1 +++ 2 title = 'Anti-analysis' 3 +++ 4 5 # Anti-analysis 6 Goal is to make analysis as difficult as possible. 7 8 ## Anti-static 9 ### Control flow obfuscation 10 Transformations that make it hard to analyze flow of control of program 11 - confuse about function boundaries, if statements/loops, jump targets 12 13 Opaque predicate: expression whose value know to programmer but difficult for analyst 14 - e.g. `(x*x)+x % 2`, which always results in 0 15 16 Control flow flattening: aims to obscure control flow logic 17 - remove control flow structure from function, hide nesting of loops and conditionals 18 - put each block of code as case inside switch statement, wrap switch inside infinite loop 19 - control flow guided by dispatcher variable 20 21 Return address patching: `ret` pops value from stack and jumps to place pointed by it, if function modifies return value then disassemblers get confused 22 - so you can overwrite return address 23 - to make it easier to analyze, `nop` the bytes that are skipped, which gives you actual instructions 24 25 ### Data obfuscation 26 i.e. convert variable to representation that's hard for analyst to understand or is unexpected 27 28 Encryption: 29 - `xor` bytewise with known constant value 30 - convert to function that computes its value at runtime 31 32 Variable splitting: 33 - split `x` into `x1` and `x2`, never compute the real value 34 - define encoding and decoding functions 35 - you may need to still compute the actual value of `x`, such as in system calls 36 - can also add variable merging, e.g. splitting two variables and merging parts of them 37 38 ## Anti-dynamic 39 ### Anti-debugging 40 different flags (PEB, Heap flags, NtGlobalFlag) 41 - NtGlobalFlag is value in Process Environment Block, value is 0x70 when debugging 42 43 detect breakpoints 44 - hardware 45 - hardware breakpoint fires when instruction tries to access specific address 46 - check debug hardware registers (but can only be accessed at level 0, in Windows you can register exception handlers and use that to check) 47 - software 48 - `int 0x3` (opcode `0xcc`) is software breakpoint, debugger overwrites original instruction with this 49 - to detect, just look for these instructions 50 51 exception traps 52 - program intentionally calls `int 0x3` 53 - if debugger not attached, program raises an exception, so check for it 54 55 self debugging 56 - only one debugger at a time can be attached 57 - so make program try to debug itself (`ptrace()`), and if it fails, another debugger already attached 58 59 time-based detection 60 - if process executed in single-step mode, it's very slow 61 - almost any timing mechanism can be used 62 63 #### How do you counter? 64 - reduce debugger visibility 65 - intercept API functions and return fake results 66 - single step through problematic part and disable anti-debugging checks 67 68 ### Anti-VM 69 Malware analysis often uses VMs to run samples, so samples refuse to run in VMs. 70 71 Look for VM-specific artifacts 72 - names/strings/processes/configurations typical of a VM (e.g. `VMwareService.exe`) 73 - but can easily be fooled by patching the OS to hide artifacts 74 - critical OS tables are relocated in VM 75 - Interrupt Descriptor Table (DT) usually higher in memory on guest machines than on host 76 - similarly for Global and Local Descriptor Tables (GDT, LDT) 77 - look for differences in memory structures using `sidt`, `sgdt`, `sldt` (can be done from userspace) 78 - virtualised hardware may have distinct fingerprints 79 - illegal opcodes that are supported by VM (e.g. communication with host) 80 - instructions that are buggy or have side-effects with some CPUs but not VM, and vice-versa 81 - e.g. VMware modifies functionality of `in` instruction 82 83 ### Anti-monitoring in general 84 - user interaction (see if you're a robot) 85 - only do bad things after reboot 86 - run before/after specific date 87 - execute after initial call to `NtTerminateProcess` 88 - sleep for a while, since analysis has time-outs (but some sandboxes have anti-sleep-acceleration) 89 - could still be avoided by introducing race condition that involves sleeping 90 - use environment details as key to decrypt actual payload