Guest User

Untitled

a guest
Aug 31st, 2015
770
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. Falkervisor Q&A
  2.  
  3. brownie - Windows snapshotting user-mode based hypervisor fuzzer thingy (intel vt-x)
  4. - Debugger for Windows for snapshotting register and memory state of an application
  5. - Load up snapshot in a intel vt-x VM.
  6. - Modify memory and then execute
  7.  
  8. brownie v2 - Windows ..... fuzzer thingy (amd svm)
  9. falkervisor - Cross-OS os-level fuzzer
  10. - Code coverage
  11. - Memory coverage (absolute and relative)
  12. - Debugging/single stepping
  13. - Networking
  14.  
  15. - Snapshots
  16. - PXE boot falkervisor in snapshot mode
  17. - Load up boot sector on disk and boot under falkervisor
  18. - Monitor hardware breakpoints
  19. - If 0x133713371337 is present in a debug register upon a hardware breakpoint
  20. take a snapshot of register state and memory, and ship over the network.
  21. - Once the snapshot is done, the hypervisor resumes execution
  22. - Feel free to take more snapshots
  23.  
  24. - Execution
  25. - PXE boot falkervisor in fuzz mode
  26. - falkervisor will request snapshot images over the network
  27. - falkervisor fuzz module will also pull whatever needed
  28.  
  29. 10:
  30. - fuzzer must change memory to change input
  31. - the vm is launched!
  32. - vm ends exeuction on one of three conditions
  33. - timeout
  34. - i/o access (disk, display, context switch)
  35. - fault (memory violation, div by zero, etc)
  36.  
  37. - #UD undefined opcode
  38. - #PF page fault
  39. - page faults occur A LOT under normal conditions
  40. NtPageFault - page fault handler
  41. - path for only 'true' page faults
  42. - #GP general purpose
  43. - on 64-bit bit systems, you get a #gp on non-canon memory accesses
  44. - 4141414141414141 - non-canon
  45. mov rax, 0x4141414141414141
  46. mov rdx, [rax] <- #gp
  47.  
  48. - if the vm ended on a fault, the register state and input file are reported
  49. over the network
  50.  
  51. - DIFFERENTIAL RESTORE!!! :)
  52. - Only restore pages in the VM with the dirty flag set.
  53. vvvv
  54. - [512 GB pages] -> [1GB pages] -> [2MB pages] -> [4k pages]
  55. ^ accessed ^ A ^A ^A ^D
  56. - 10-100x speedup
  57.  
  58. - GOTO 10
  59.  
  60. - Code coverage
  61. - falkervisor uses interrupt/timer based code coverage
  62. - LBR is a intel and AMD feature that basicially records last branches
  63. taken. Hence 'last branch recording'
  64. - LBR on intel stores the last 8(?) branches taken
  65. - LBR on AMD only stores the last branch taken
  66. br_from and br_to. [0x1000] -> [0x2000]
  67. - IBS instuction based sampling. AMD only
  68. - Give it a number of 'ticks'. It counts down these ticks, and then fires
  69. an interrupt after this counter hits zero.
  70. - Mainly for performance monitoring. Gives information on stalls, cache
  71. hits and misses, branch mispredictions, etc.
  72. - IBS for free tells you the physical and virtual addresses for RIP
  73. - IBS also tells you whether the instruction was a load or a store (or neither)
  74. as well as the physical AND virtual address of the load/store if it was one
  75.  
  76. - Storage of code coverage
  77. - Initial falkervisor used bswap(br_to) ^ br_from
  78. 00001337, 00002335
  79. 37132335 <- code coverage 'hash'
  80. - Later falkervisor uses falkhash to properly hash (br_to, br_from)
  81. falkhash is a 128-bit AES based hashing algorithm which is super duper fast
  82. https://github.com/gamozolabs/falkhash
  83.  
  84. - Use of code coverage
  85. - Each basic block has a counter associated with the number of times we've seen it
  86. - Early falkervisor
  87. - Sorted table of basic blocks based on frequency
  88. - Pick one of the least common 64 inputs, and use it as the base for the
  89. next generation of mutation
  90.  
  91. - Later falkervisor, sorted database was ditched!
  92. - Randomly select n (~16) inputs from the code covearge database.
  93. - Out of the 16 inputs, pick the least common one
  94. - Use this input as the base of the next fuzz case
  95.  
  96. - Crash coverage
  97. - Store each unique crash that I get
  98. - Initial falkervisor used unique PC
  99. - Later falkervisor used unique (PC, faulting address)
  100. - Later falkervisor used up to 10 unique faulting addresses for each PC
  101. - Bug shows up as null deref [0, 16KB) but then later in time shows up
  102. as a non-null deref.
  103. - 0x0, 0x10, 0x20, ... 0x3414141414141
  104.  
  105. - Current falkervisor stores 10 of each of the 5 groups of crashes
  106. Classify the bug as one of five types of crashes.
  107. - Null deref - #PF [0, 16KB)
  108. - Negative deref - #PF [-16KB, 0]
  109. - Normal deref - #PF any other address
  110. - 'ascii' deref - #GP (non-canon memory access)
  111. - None of the above - !(#GP || #PF)
  112.  
  113. - Similar to code coverage, randomly pick a crashing input to mutate with.
  114.  
  115. - Picking how to pick input base
  116. - 5% Original input file
  117. - 5% Corpus of input files (thousands if not millions of input files)
  118. - 80% Code coverage inputs
  119. - 10% Crash coverage inputs
  120.  
  121. - Weights!
  122.  
  123. - How do I usually mutate
  124. - Corpus of inputs. Randomly pick data from the corpus, and inject it randomly
  125. in the base input file. Splicing inputs.
  126.  
  127. - Minimization
  128. - Randomly delete parts/move parts/merge parts/change size of input file.
  129. - If it crashes in the same way as before, store this as the new 'minimal' input
  130.  
  131. - branch 'solving'
  132. - Look for compare instructions that have input file data present in a register.
  133. cmp rax, rbx - rbx = 0x414141414141414141414141 <-- present in the input file
  134. ^ equal, not equal, off by one (above and below), etc
  135. movcc
  136. jmpcc
  137. cmp al, bl - al 0x41
  138. - memcmp solver
  139.  
  140. - Comparing results from different snapshots
  141. - I have 8 NUMA nodes which each get their own snapshot
  142. - Stack corruption bug that would show up in thousands of ways.
  143. - crashing input hash '1337'
  144. - broadcast to all other nodes to run '1337' through.
  145. node 0 - lib+32
  146. node 1 - lib+32
  147. node 2 - lib+24
  148. node 3 - ~~~
  149.  
  150. - '3333'
  151. node 0 - lib+64
  152. node 1 - lib+32
  153. node 2 - ~~~
  154. node 3 - lib+8
  155.  
  156. 3333 and 1337 have lib+32 in common!
  157. [lib+32, lib+24, lib+64, lib+8, ~~~] -> [1337, 3333]
  158.  
  159. - Faults of this concept
  160. - What if lib+32 is __stack_check(), DebugBreak(), RaiseException(), memcpy()
  161. - Workarounds to this fault, blacklist
  162.  
  163. - Function flow [theory]
  164. - Lets say I have 2 crashes
  165. - minimize down the 2 crashes
  166. - Run each input through with full single stepping
  167. - What branches are taken, and what calls are made.
  168. - crash 1 - A() -> B() <- C() (crashes)
  169. - crash 2 - A() -> C() (crashes)
  170. - Make a set of all unique functions, and compare the sets.
  171. - 90% of functions match, assume the bugs are the same
  172. - A -> B -> C -> memcpy
  173. - A -> D -> F -> memcpy 2 differnt bugs
  174.  
  175. - Logic bugs
  176. - Speical tracing/breakpoints. LoadLibrary()
  177. - Put a breakpoint on LoadLibrary(), and see if user input is present in
  178. the file name.
  179. - MmProbeAndLockPages(), the address is a user address, but access mode is KernelMode
  180. - Little things like this. Usually going to have to be be manually implemented as
  181. plugins/modules.
  182.  
  183. - Memory covearge (relative and absolute)
  184. - IBS I get free load/store decodes
  185. - I can track what memory is being written and read from
  186. - I can track what blocks are making these accesses
  187.  
  188. - relative memory coverage by using stack/heap awareness.
  189. - mov rax, [0x100+0x100] <- heap address is 0x100
  190. - mov rax, [0x200+0] <- heap address is 0x200
  191. - 0x100 belongs to allocation @ 0x100 of 0x20 length.
  192. - so this access is 0x0 bytes relative to the access
  193.  
  194. - what if this address faults, and is out of bounds of our heap info, how can we tell?
  195. - page heap. make it so it would fault, and now we have the crash we wanted
  196.  
  197. - how does this evolve?
  198. - mov rax, [rbx] (100 times rbx = +0x10, 10 times = +0x20, 1 time = +0x1000)
  199.  
  200. - Stack walking
  201. - 'kb' or 'bt' in windbg/gdb
  202. - With code covearge, store the stack walk that caused us to get here
RAW Paste Data