Clone of . For those who would prefer to not be tracked by MS.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

364 lines
42 KiB

5 years ago
3 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
5 years ago
3 years ago
3 years ago
3 years ago
  1. # Fuzzing (and bug hunting)
  2. -------------------------------------------------
  3. ## Table of Contents
  4. - [General](#general)
  5. * [101](#101)
  6. * [Books](#books)
  7. * [Bug Hunting in Source Code](#bughunt)
  8. * [Educational/Informative](#edu)
  9. * [History](#history)
  10. * [General](#general2)
  11. * [Presentations/Talks](#pres)
  12. * [Training](#train)
  13. - [Fuzzing Stuff & Hunting Bugs](#fuzzhunt)
  14. * [Dynamic Fuzzing](#dynamic)
  15. * [Static Fuzzing](#static)
  16. * [Android Bug Hunting/Fuzzing](#android)
  17. * [Browser Bug Hunting/Fuzzing](#browser)
  18. * [C/C++ Fuzzing](#c)
  19. * [Cellular Related Technologies Bug Hunting/Fuzzing](#cell)
  20. * [Cisco](#cisco)
  21. * [COM Fuzzing](#com)
  22. * [Embedded Devices](#embedded)
  23. * [File Formats Bug Hunting/Fuzzing](#file)
  24. * [Network Protocol Bug Hunting/Fuzzing](#network)
  25. * [Fuzzing Linux](#linux)
  26. * [Medical Devices](#medical)
  27. * [OS X Bug Hunting/Fuzzing](#osx)
  28. * [PDF](#pdf)
  29. * [RTP](#rtp)
  30. * [Source Fuzzing/Bug Hunting](#source)
  31. * [USB Bug Hunting/Fuzzing](#usb)
  32. * [Virtual Appliance Bug Hunting/Fuzzing](#virtual)
  33. * [Web Application Bug Hunting/Fuzzing](#web)
  34. * [Windows Fuzzing/Bug Hunting](#windows)
  35. - [Non Specific Fuzzing Related Tools](#nonspecific)
  36. * [AFL](#afl)
  37. * [Peach](#peach)
  38. * [Miscellaneous/Other](#misc)
  39. ------------
  40. ### <a name="general"></a>General<a name="general"></a>
  41. * **101**
  42. * [15 minute guide to fuzzing](
  43. * [Fuzzing to break software - grid - Scott M](
  44. * Ever wanted to break software? You know you want's fun! In this talk, I will share some tools & techniques I've used to improve software by breaking it.
  45. * [Quick explanation of fuzzing and various fuzzers](
  46. * **Books**
  47. * [*THE* Book on fuzzing](
  48. * **Bug Hunting in Source Code**
  49. * [GitHub for Bug Bounty Hunters](
  50. * [Secure Code Review -](
  51. * [High-Level Approaches for Finding Vulnerabilities](
  52. * [Vulnerabilities 101 : How to Launch or Improve Your Vulnerability Research Game - Joshua Drake, Steve Christey Coley](
  53. * [Bug Hunting with Static Code Analysis - Nick Jones](
  54. * **Educational/Informative**
  55. * [Faster Fuzzing with Python](
  56. * [Good slides on fuzzing](
  57. * [The Power Of Pair: One Template That Reveals 100+ Uaf Ie Vulnerabilities - BlackhatEU14](
  58. * [Mining for Bugs with Graph Database Queries [31c3]](
  59. * [ClusterFuzz](
  60. * [Google VRP and Unicorns](
  61. * In July 2017 at BountyCraft event we delivered a presentation entitled "Google VRP and Unicorns", featuring a selection of interesting bugs reported to our program, and disclosing some planned updates in store for Google VRP.
  62. * [How to Spot Good Fuzzing Research - trailofbits](
  63. * **History**
  64. * [Symbolic execution timeline](
  65. * Diagram highlights some major tools and ideas of pure symbolic execution, dynamic symbolic execution (concolic) as well as related ideas of model checking, SAT/SMT solving, black-box fuzzing, taint data tracking, and other dynamic analysis techniques.
  66. * **General**
  67. * [Fools of Golden Gate](
  68. * How major vulnerabilities/large amounts of publicly vulnerable systems can exist without public recognition for long periods of time. (i.e. CVEs(10.0) exist, but no mapping in nessus/metasploit/etc)
  69. * [Fuzzing workflows; a fuzz job from start to finish](
  70. * [Youtube Playlist of Fuzzing Videos](
  71. * [Effective Bug Discovery](
  72. * Sophisticated methods are currently being developed and implemented for mitigating the risk of exploitable bugs. The process of researching and discovering vulnerabilities in modern code will require changes to accommodate the shift in vulnerability mitigations. Code coverage analysis implemented in conjunction with fuzz testing reveals faults within a binary file that would have otherwise remained undiscovered by either method alone. This paper suggests a research method for more effective runtime binary analysis using the aforementioned strategy. This study presents empirical evidence that despite the fact that bug detection will become increasingly difficult in the future, analysis techniques have an opportunity to evolve intelligently.
  73. * [Upping Your Bug Hunting Skills Using Symbolic Virtual Machines by Anto - x33fcon](
  74. * [The Best of Bug Finding - Duo Tech Talk (Charlie Miller)](
  75. * I look at how security vulnerabilities are found (or missed) and some of my favorite bugs and exploits I’ve come across in my career.
  76. * [fuzzdb](
  77. * Dictionary of attack patterns and primitives for black-box application fault injection and resource discovery.
  78. * **Presentations/Talks**
  79. * [Unusual bugs - 23C3](
  80. * In this presentation I'll present a series of unusual security bugs. Things that I've ran into at some point and went "There's gotta be some security consequence here". None of these are really a secret, and most of them are even documented somewhere. But apparently most people don't seem to know about them. What you'll see in this presentation is a list of bugs and then some explanation of how these could be exploited somehow. Some of the things I'll be talking about are (recursive) stack overflow, NULL pointer dereferences, regular expressions and more.
  81. * **Training**
  82. * [Modern fuzzing of C/C++ Projects - Slides](
  83. * [libfuzzer-workshop](
  84. * Materials of "Modern fuzzing of C/C++ Projects" workshop.
  85. -----------------
  86. ### <a name="fuzzhunt"></a> Fuzzing Stuff & Hunting Bugs
  87. * **Dynamic Fuzzing**
  88. * **Frameworks**
  89. * [Triton](
  90. * Triton is a dynamic binary analysis (DBA) framework. It provides internal components like a Dynamic Symbolic Execution (DSE) engine, a Taint engine, AST representations of the x86 and the x86-64 instructions set semantics, SMT simplification passes, an SMT Solver Interface and, the last but not least, Python bindings.
  91. * [XDiFF](
  92. * XDiFF is an Extended Differential Fuzzing Framework built for finding vulnerabilities in software. It collects as much data as possible from different executions an then tries to infer different potential vulnerabilities based on the different outputs obtained. The fuzzer uses Python and runs on multiple OSs (Linux, Windows, OS X, and Freebsd). Its main goal is to detect issues based on diffential fuzzing aided with the extended capabilities to increase coverage. Still, it will found common vulnerabilities based on hangs and crashes, allowing to attach a memory debugger to the fuzzing sessions.
  93. * **Differential Fuzzers**
  94. * **101**
  95. * [Differential testing - Wikipedia](
  96. * Differential testing, also known as differential fuzzing, is a popular software testing technique that attempts to detect bugs, by providing the same input to a series of similar applications (or to different implementations of the same application), and observing differences in their execution. Differential testing complements traditional software testing, because it is well-suited to find semantic or logic bugs that do not exhibit explicit erroneous behaviors like crashes or assertion failures. Differential testing is sometimes called back-to-back testing.
  97. * **Articles/Blogposts/Writeups**
  98. * [Exposing Hidden Exploitable Behaviors in Programming Languages Using Differential Fuzzing - Fernando Arnaboldi](
  99. * **Talks and Presentations**
  100. * [Exposing Hidden ExploitableBehaviors in ProgrammingLanguagesUsingDifferential Fuzzing - Fernando Arnaboldi](
  101. * [Differential Slicing: Identifying Causal Execution Differences for Security Applications](
  102. * Abstract —A security analyst often needs to understand two runs of the same program that exhibit a difference in program state or output. This is important, for example, for vulnerability analysis, as well as for analyzing a malware program that features different behaviors when run in different environments. In this paper we propose a differential slicing approach that automates the analysis of such execution differences. Differential slicing outputs a causal difference graph that captures the input differences that triggered the observe d difference and the causal path of differences that led from thos e input differences to the observed difference. The analyst uses the graph to quickly understand the observed difference. We implement differential slicing and evaluate it on the analysis of 11 real-world vulnerabilities and 2 malware samples with environment-dependent behaviors. We also evaluate it in an informal user study with two vulnerability analysts. Our results show that differential slicing successfully identifies the input differences that caused the observed difference and that the causal difference graph significantly reduces the amount of time and effort required for an analyst to understand the observed difference
  103. * **Tools**
  104. * [XDiFF](
  105. * XDiFF is an Extended Differential Fuzzing Framework built for finding vulnerabilities in software. It collects as much data as possible from different executions an then tries to infer different potential vulnerabilities based on the different outputs obtained.
  106. * **SAT/SMT Solvers**
  107. * **101**
  108. * [Quick introduction into SAT/SMT solvers and symbolic execution - Dennis Yurichev](
  109. * [SAT_SMT_Article](
  110. * **Articles/Blogposts/Writeups**
  111. * **Talks and Presentations**
  112. * **Taint Analysis**
  113. * **101**
  114. * **Articles/Blogposts/Writeups**
  115. * [Taint analysis and pattern matching with Pin - Jonathan Salwan](
  116. * **Talks and Presentations**
  117. * [Applying Taint Analysis and Theorem Proving to Exploit Development - Sean Heelan - RECON2010](
  118. * [All You Ever Wanted to Know About Dynamic Taint Analysis and Forward Symbolic Execution (but might have been afraid to ask)](
  119. * Abstract — Dynamic taint analysis and forward symbolic execution are quickly becoming staple techniques in security analyses. Example applications of dynamic taint analysis and forward symbolic execution include malware analysis, input filter generation, test case generation, and vulnerability dis- covery. Despite the widespread usage of these two techniques, there has been little effort to formally define the algorithms and summarize the critical issues that arise when these techniques are used in typical security contexts. The contributions of this paper are two-fold. First, we precisely describe the algorithms for dynamic taint analysis and forward symbolic execution as extensions to the run-time se- mantics of a general language. Second, we highlight important implementation choices, common pitfalls, and considerations when using these techniques in a security context.
  120. * **Papers**
  121. * [A Critical Review of Dynamic Taint Analysis and Forward Symbolic Execution](
  122. * In this note , we describe a critical review of the paper titled “All you wanted to know about dynamics taint analysis and forward symbolic execution (but may have been afraid to ask)” [1] . We analyze the paper using Paul Elder critical thinking framework [2] . We sta rt with a summary of the paper and motivation behind the research work described in [1]. Then we evaluate the study with respect to the universal intellectual standards of [2]. We find that the paper provides a good survey of the existing techniques and algorithms used for security analysis. It explains them using the theoretical framework of operational runtime semantics. However in some places t he paper can do a better job in highlighting what new insights or heuristics can be gained from a runtime seman tics formulation. The paper fails to convince the reader how such an intricate understanding of operational semantics of a new generic language SimpIL helps in advancing the state of the art in dynamic taint analysis and forward symbolic execution. We also found that the Paul Elder critical thinking framework is a useful technique to reason about and analyze research papers.
  123. * [TAJ: Effective Taint Analysis of Web Applications - Java Webapps](
  124. * Taint analysis, a form of information-flow analysis, establishes whether values from untrusted methods and parameters may flow into security-sensitive operations. Taint analysis can detect many common vulnerabilities in Web applications, and so has attracted much attention from both the research community and industry. However, most static taint-analysis tools do not address criti- cal requirements for an industrial-strength tool. Specifically, an industrial-strength tool must scale to large industrial Web applica- tions, model essential Web-application code artifacts, and generate consumable reports for a wide range of attack vectors. We have designed and implemented a static Taint Analysis for Java (TAJ) that meets the requirements of industry-level applica- tions. TAJ can analyze applications of virtually any size, as it em- ploys a set of techniques designed to produce useful answers given limited time and space. TAJ addresses a wide variety of attack vec- tors, with techniques to handle reflective calls, flow through con- tainers, nested taint, and issues in generating useful reports. This paper provides a description of the algorithms comprising TAJ, evaluates TAJ against production-level benchmarks, and compares it with alternative solutions.
  125. * **Tools**
  126. * [usercorn](
  127. * dynamic binary analysis via platform emulation
  128. * **Writeups**
  129. * [Fuzzing TCP servers - Robert Swiecki](
  130. * [From Fuzzing to 0day.](
  131. * **Static Fuzzing**
  132. * **101**
  133. * **Articles/Blogposts/Writeups**
  134. * **Frameworks**
  135. * [Paper Machete](
  136. * Paper Machete (PM) orchestrates Binary Ninja and GRAKN.AI to perform static analysis on binary targets with the goal of finding exploitable vulnerabilities. PM leverages the Binary Ninja MLIL SSA to extract semantic meaning about individual instructions, operations, register/variable state, and overall control flow. This data is then migrated into GRAKN.AI, a hyper-relational database. We then run queries against the database that are designed to look for indications of common software vulnerability classes.
  137. * **Tools**
  138. * **Talks/Writeups**
  139. * [Aiding Static Analysis: Discovering Vulnerabilities in Binary Targets through Knowledge Graph Inferences - John Toterhi - Derbycon7](
  140. * Static analysis is the foundation of vulnerability research (VR). Even with today's advanced genetic fuzzers, concolic analysis frameworks, emulation engines, and binary instrumentation tools, static analysis ultimately makes or breaks a successful VR program. In this talk, we will explore a method of enhancing our static analysis process using the GRAKN.AI implementation of Google's knowledge graph and explore the semantics from Binary Ninja's Medium Level static single assignment (SSA) intermediate language (IL) to perform inference queries on binary-only targets to identify vulnerabilities.
  141. * **Android Bug Hunting/Fuzzing**
  142. * **Articles/Writeups**
  143. * [Fuzzing Object s d’ART Digging Into the New Android L Runtime Internals](
  144. * **Tools**
  145. * [MFFA - Media Fuzzing Framework for Android](
  146. * [android-afl](
  147. * Fuzzing Android program with american fuzzy lop (AFL)
  148. * [Droid Application Fuzz Framework](
  149. * Droid Application Fuzz Framework (DAFF) helps you to fuzz Android Browsers and PDF Readers for memory corruption bugs in real android devices. You can use the inbuilt fuzzers or import fuzz files from your own custom fuzzers. DAFF consist of inbuilt fuzzers and crash monitor. It currently supports fuzzing the following applications:
  150. * [MFFA - Media Fuzzing Framework for Android (Stagefright fuzzer)](
  151. * The main idea behind this project is to create corrupt but structurally valid media files, direct them to the appropriate software components in Android to be decoded and/or played and monitor the system for potential issues (i.e system crashes) that may lead to exploitable vulnerabilities. Custom developed Python scripts are used to send the malformed data across a distributed infrastructure of Android devices, log the findings and monitor for possible issues, in an automated manner. The actual decoding of the media files on the Android devices is done using the Stagefright command line interface. The results are sorted out, in an attempt to find only the unique issues, using a custom built triage mechanism.
  152. * **Browser Bug Hunting/Fuzzing**
  153. * [Browser Bug Hunting and Mobile](
  154. * [Grinder - Fuzzer](
  155. * Grinder is a system to automate the fuzzing of web browsers and the management of a large number of crashes. Grinder Nodes provide an automated way to fuzz a browser, and generate useful crash information (such as call stacks with symbol information as well as logging information which can be used to generate reproducible test cases at a later stage). A Grinder Server provides a central location to collate crashes and, through a web interface, allows multiple users to login and manage all the crashes being generated by all of the Grinder Nodes.
  156. * [browserfuzz](
  157. * A very simple browser fuzzer based on tornado.
  158. * [Browser bug hunting - Memoirs of a last man standing, Atte Kettunen](
  159. * [morph](
  160. * an open source browser fuzzing framework for fun.
  161. * **C/C++ Fuzzing**
  162. * [ansvif]( - An advanced cross platform fuzzing framework designed to find vulnerabilities in C/C++ code.
  163. * [libFuzzer]( - In-process, coverage-guided, evolutionary fuzzing engine for targets written in C/C++.
  164. * **Cellular Related Technologies Bug Hunting/Fuzzing**
  165. * [Binary SMS - The old backdoor to your new thing](
  166. * [Fuzzing the Phone in your Phone](
  167. * **Cisco**
  168. * [asadbg](
  169. * asadbg is a framework of tools to aid in automating live debugging of Cisco ASA devices, as well as automating interaction with the Cisco CLI over serial/ssh to quickly perform repetitive tasks.
  170. * [asatools - NCCGroup](
  171. * Main repository to pull all Cisco ASA-related projects.
  172. * [asafw](
  173. * Set of scripts to deal with Cisco ASA firmware [pack/unpack etc.]
  174. * **COM Fuzzing**
  175. * [COMRaider](
  176. * ActiveX Fuzzing tool with GUI, object browser, system scanner, and distributed auditing capabilities
  177. * [Github](
  178. * **Embedded Devices Fuzzing/Bug Hunting**
  179. * [Bug Hunting: Drilling into the Internet of Things(IoT) - DuoLabs](
  180. * **File Formats Bug Hunting/Fuzzing**
  181. * [Practical File Format Fuzzing](
  182. * File format fuzzing has been very fruitful at discovering exploitable vulnerabilities. Adversaries take advantage of these vulnerabilities to conduct spear-phishing attacks. This talk will cover the basics of file format fuzzing and show you how to use CERT’s fuzzing frameworks to discovery vulnerabilities in file parsers.
  183. * [File Format Fuzzing in Android](
  184. * [Funky File Formats - Advanced Binary Exploitation](
  185. * **Network Protocols Bug Hunting/Fuzzing** <a name="network"></a>
  186. * **Articles/Writeups**
  187. * [Fuzzing proprietary protocols with Scapy, radamsa and a handful of PCAPs](
  188. * [Introduction to Custom Protocol Fuzzing](
  189. * **Tools**
  190. * [boofuzz](
  191. * Boofuzz is a fork of and the successor to the venerable Sulley fuzzing framework. Besides numerous bug fixes, boofuzz aims for extensibility. The goal: fuzz everything.
  192. * [boofuzz quickstart](
  193. * [rage_fuzzer](
  194. * A dumb protocol-unaware packet fuzzer/replayer.
  195. * [Nightmare](
  196. * A distributed fuzzing testing suite with web administration, supports fuzzing using network protocols.
  197. * [pcrappyfuzzer](
  198. * Script to perform quick 'n dirty fuzzing of PCAPs with radamsa and Scapy.
  199. * **Fuzzing Linux**
  200. * **Kernel**
  201. * [KernelFuzzer]( - Cross Platform Kernel Fuzzer Framework.
  202. * **Syscalls**
  203. * [syzkaller - linux syscall fuzzer](
  204. * An unsupervised, coverage-guided Linux syscall fuzzer. It is meant to be used with KASAN (CONFIG_KASAN=y), KTSAN (CONFIG_KTSAN=y), or KUBSAN.
  205. * **Libraries**
  206. * [libFuzzer]((
  207. * library for in-process evolutionary fuzzing of other libraries.
  208. * **Medical Devices**
  209. * [Open Up and Say 0x41414141: Attacking Medical Devices - Robert PortvlIet - Toorcon19](
  210. * Network accessible medical devices are ubiquitous in today’s clinical environment. These devices can be of great aid to healthcare profes- sionals in assessing, treating and monitoring a patient’s condition. However, they can also fall victim to a number of systemic vulnerabili- ties that can expose personal health information or PHI, compromise the integrity of patient data in transit, and affect the availability of the devices themselves. This talk looks at the methodology and approach to penetration testing of modern medical devices. It will provide an overview of the various stages of a medical device assessment, including discovery and analysis of a device’s remote and local attack surface, reverse engineering and exploitation of proprietary network protocols, vulner- ability discovery in network services, compromising supporting sys- tems, attacking common wireless protocols, exploitation of hardware debug interfaces and bus protocols and assessing proprietary wireless technologies. It will also cover a number of real world vulnerabilities that the speaker has discovered during medical device penetration testing assessments. These include weak cryptographic implementations, device impersonation and data manipulation vulnerabilities in pro- prietary protocols, unauthenticated database interfaces, hardcoded credentials/keys and other sensitive information stored in firmware/ binaries and the susceptibility of medical devices to remote denial of service attacks. The talk will conclude with some suggestions on how some of the most common classes of medical device vulnerabilities might be reme- diated by vendors and also how hospitals and other healthcare provid- ers can defend their medical devices in the meantime.
  211. * **OS X Bug Hunting/Fuzzing**
  212. * [There's a lot of vulnerable OS X applications out there](
  213. * **PDF**
  214. * [0-day streams: pdfcrack](
  215. * **RTP**
  216. * [ohrwurm](
  217. * ohrwurm is a small and simple RTP fuzzer, I tested it on a small number of SIP phones, none of them did withstand.
  218. * **Source Code Fuzzing/Bug Hunting**
  219. * **Articles/Talks/Writeups**
  220. * [Improving security with Fuzzing and Sanitizers](
  221. * A bug in Gstreamer could be used to own a Linux Desktop system. TCPDump released a security update fixing 42 CVEs. We have far too many security critical bugs in the free and open source software stack. But we have powerful tools to find them - we just have to use them.
  222. * [GitHub for Bug Bounty Hunters](
  223. * [Secure Code Review -](
  224. * [High-Level Approaches for Finding Vulnerabilities](
  225. * [Vulnerabilities 101 : How to Launch or Improve Your Vulnerability Research Game - Joshua Drake, Steve Christey Coley](
  226. * [Bug Hunting with Static Code Analysis - Nick Jones](
  227. * **Tools**
  228. * [Google - AddressSanitizer, ThreadSanitizer, MemorySanitizer, LeaksSanitizer](
  229. * This project is the home for Sanitizers: AddressSanitizer, MemorySanitizer, ThreadSanitizer, LeakSanitizer. The actual code resides in the LLVM repository. Here we keep extended documentation, bugs and some helper code.
  230. * **USB Bug Hunting/Fuzzing**
  231. * [Introduction to USB and Fuzzing DEFCON23 Matt DuHarte](
  232. * [Implementing an USB Host Driver Fuzzer - Daniel Mende - Troopers14](
  233. * [USB Fuzzing Basics: From fuzzing to bug reporting](
  234. * [Introduction to USB and Fuzzing DEFCON23 Matt DuHarte](
  235. * **Virtual Appliance Bug Hunting/Fuzzing**
  236. * [Hacking Virtual Appliances - DerbyconV](
  237. * Virtual Appliances have become very prevalent these days as virtualization is ubiquitous and hypervisors commonplace. More and more of the major vendors are providing literally virtual clones for many of their once physical-only products. Like IoT and the CAN bus, it's early in the game and vendors are late as usual. One thing that it catching these vendors off guard is the huge additional attack surface, ripe with vulnerabilities, added in the process. Also, many vendors see software appliances as an opportunity for the customer to easily evaluate the product before buying the physical one, making these editions more accessible and debuggable by utilizing features of the platform on which it runs. During this talk, I will provide real case studies for various vulnerabilities created by mistakes that many of the major players made when shipping their appliances. You'll learn how to find these bugs yourself and how the vendors went about fixing them, if at all. By the end of this talk, you should have a firm grasp of how one goes about getting remotes on these appliances.
  238. * **Web Application Bug Hunting/Fuzzing**
  239. * [Advice From A Researcher: Hunting XXE For Fun and Profit](
  240. * See web section.
  241. * **Windows Fuzzing/Bug Hunting**
  242. * **F**
  243. * **Tools**
  244. * [WinAFL]( - A fork of AFL for fuzzing Windows binaries
  245. * [!exploitable Crash Analyzer](
  246. * !exploitable (pronounced “bang exploitable”) is a Windows debugging extension (Windbg) that provides automated crash analysis and security risk assessment. The tool first creates hashes to determine the uniqueness of a crash and then assigns an exploitability rating to the crash: Exploitable, Probably Exploitable, Probably Not Exploitable, or Unknown. There is more detailed information about the tool in the following .pptx file or at Additonally, see the blog post at, or watch the video at
  247. * [DiffRay](
  248. * Tool for diffing Win7 & Win8 Libraries based on textfile outputs from IDA Pro.
  249. * [sandbox-attacksurface-analysis-tools](
  250. * This is a small suite of tools to test various properties of sandboxes on Windows. Many of the checking tools take a -p flag which is used to specify the PID of a sandboxed process. The tool will impersonate the token of that process and determine what access is allowed from that location. Also it's recommended to run these tools as an administrator or local system to ensure the system can be appropriately enumerated.
  251. * [CERT’s Failure Observation Engine (FOE)](
  252. * The CERT Failure Observation Engine (FOE) is a software testing tool that finds defects in applications that run on the Windows platform. FOE performs mutational fuzzing on software that consumes file input. (Mutational fuzzing is the act of taking well-formed input data and corrupting it in various ways looking for cases that cause crashes.) The FOE automatically collects test cases that cause software to crash in unique ways, as well as debugging information associated with the crashes. The goal of FOE is to minimize the effort required for software vendors and security researchers to efficiently discover and analyze security vulnerabilities found via fuzzing.
  253. * [Walkthrough of setting up CERT’s FOE fuzzer and fuzzing irfanview](
  254. * **Articles/Writeups**
  255. * [Running Windows 64-bit in QEMU Emulation Mode](
  256. * [Smart COM Fuzzing - Auditing IE Sandbox Bypass in COM Objects• Xiaoning Li • Haifei Li](
  257. * [Fuzzing for MS15-010](
  258. * This past Patch Tuesday Microsoft released MS15-010: Vulnerabilities in Windows Kernel-Mode Driver Could Allow Remote Code Execution. This patch addressed multiple privately reported vulnerabilities in win32k.sys and one publicly disclosed vulnerability in cng.sys. This post goes through identifying the patched vulnerability.
  259. * [What Happens In Windows 7 Stays In Windows 7 - Marion Marschalek & Joseph Moti - Troopers14](
  260. * Diffing libs in Win7 compared to Win8 to id vuln dlls.
  261. * [Fuzzing for MS15-010](
  262. * Is what it says on the tin.
  263. * **Patch Analysis**
  264. * [Microsoft Patch Analysis for Exploitation - Stephen Sims](
  265. * Since the early 2000's Microsoft has distributed patches on the second Tuesday of each month. Bad guys, good guys, and many in-between compare the newly released patches to the unpatched version of the files to identify the security fixes. Many organizations take weeks to patch and the faster someone can reverse engineer the patches and get a working exploit written, the more valuable it is as an attack vector. Analysis also allows a researcher to identify common ways that Microsoft fixes bugs which can be used to find 0-days. Microsoft has recently moved to mandatory cumulative patches which introduces complexity in extracting patches for analysis. Join me in this presentation while I demonstrate the analysis of various patches and exploits, as well as the best-known method for modern patch extraction.
  266. -----------------
  267. ### Non-Specific Tools(Don't explicitly fit into above sections)
  268. * **AFL**
  269. * [American Fuzzy Lop AFL](
  270. * American fuzzy lop is a security-oriented fuzzer that employs a novel type of compile-time instrumentation and genetic algorithms to automatically discover clean, interesting test cases that trigger new internal states in the targeted binary. This substantially improves the functional coverage for the fuzzed code. The compact synthesized corpora produced by the tool are also useful for seeding other, more labor- or resource-intensive testing regimes down the road.
  271. * **101**
  272. * **Articles/Writeups/Talks**
  273. * [How to fuzz a server with American Fuzzy Lop](
  274. * [Fuzz Smarter, Not Harder (An Afl-Fuzz Primer) BSides-SF 2016](
  275. * [How to: Fuzzing open source projects with american fuzzy lop (AFL)](
  276. * **Associated Tools**
  277. * [crashwalk](
  278. * Bucket and triage on-disk crashes. OSX and Linux.(automated triaging of AFL-based crashes)
  279. * [afl-dyninst ; AFL Fuzzing blackbox binaries](
  280. * American Fuzzy Lop + Dyninst == AFL Fuzzing blackbox binaries The tool has two parts. The instrumentation tool and the instrumentation library. Instrumentation library has an initialization callback and basic block callback functions which are designed to emulate what AFL is doing with afl-gcc/afl-g++/afl-as. Instrumentation tool (afl-dyninst) instruments the supplied binary by inserting callbacks for each basic block and an initialization callback either at `_init` or at specified entry point.
  281. * **Peach**
  282. * **101**
  283. * [Peach Documentation](
  284. * [Creating Custom Peach Fuzzer Publishers](
  285. * [Code](
  286. * **Articles/Talks/Writeups**
  287. * [Fuzzing with Peach tutorial](
  288. * [Part 2](
  289. * [Fuzzing Vulnserver with Peach 3](
  290. * **Miscellaneous/Other**
  291. * [Starting out with Joern](
  292. * [Kitty][]
  293. * Fuzzing framework written in python(Not a fuzzer)
  294. * [IDA Pro](
  295. * [PANDA ( Platform for Architecture-Neutral Dynamic Analysis )](
  296. * [QIRA (QEMU Interactive Runtime Analyser)](
  297. * [Fuzzapi]( - Fuzzapi is rails application which uses API_Fuzzer and provide UI solution for gem.
  298. * [Zulu Fuzzer](
  299. * The Zulu fuzzer
  300. * [honggfuzz](
  301. * Security oriented fuzzer with powerful analysis options. Supports evolutionary, feedback-driven fuzzing based on code coverage (sw and hw)
  302. * [Radamsa](
  303. * Radamsa is a test case generator for robustness testing, aka a fuzzer. It can be used to test how well a program can stand malformed and potentially malicious inputs. It operates based on given sample inputs and thus requires minimal effort to set up. The main selling points of radamsa are that it is easy to use, contains several old and new fuzzing algorithms, is easy to script from command line and has already been used to find a slew of bugs in programs that actually matter.
  304. * [binnavi]( - Binary analysis IDE, annotates control flow graphs and call graphs of disassembled code.
  305. * [Capstone]( - Capstone is a lightweight multi-platform, multi-architecture disassembly framework.
  306. * [Hodor Fuzzer]( - Yet Another general purpose fuzzer.
  307. * [libfuzzer-gv]( - enhanced fork of libFuzzer
  308. * [libFuzzer-gv: new techniques for dramatically faster fuzzing](
  309. * [FuzzManager](
  310. * With this project, we aim to create a management toolchain for fuzzing. Unlike other toolchains and frameworks, we want to be modular in such a way that you can use those parts of FuzzManager that seem interesting to you without forcing a process upon you that does not fit your requirements.
  311. ### Sorting
  312. * [dbusmap](
  313. * This is a simple utility for enumerating D-Bus endpoints, an nmap for D-Bus.
  314. * [Firmware Slap](
  315. * Firmware slap combines concolic analysis with function clustering for vulnerability discovery and function similarity in firmware. Firmware slap is built as a series of libraries and exports most information as either pickles or JSON for integration with other tools.
  317. * [AFL + QuickCheck = ? - Dan Luu](
  318. * [Automating Windows Kernel Analysis With Symbolic Execution - Spencer McIntyre(BSides Cleveland 2019)](
  324. Fuzzing
  326. * Add Descriptions/generals to types of fuzzing
  327. * [Basic fuzzing framework](
  328. * [Fuzzing 101 (Part 1)]()
  329. * [Fuzzing 101 (Part 2)](
  332. *
  333. *
  334. *
  335. *
  336. Binary Instrumentation
  337. *
  338. *