Grinder是比较有名的浏览器FUZZ框架，采用ruby语言编写，主要是作为测试框架来使用，在《白帽子讲浏览器安全》一书中作者使用了Nduja生成测试样本来配合Grinder使用。根据网上的资料，nduja、fileja的自动化部署默认都以Grinder作为支撑环境。

我个人觉得Grinder存在的意义在于能够快速部署我们想要的Fuzz样例而无需操心异常捕获、进程管理这些细节。

Grinder分为

Node：负责实际的FUZZ工作

Server：负责收集结果，主要是为了管理多台Fuzz机器

我这里只搭建了Node

1. 安装ruby2.0环境，在Windows下我使用了RubyInstaller进行一键集成化的安装。
2. 把.\grinder\node\data\x86\grinder_logger.dll放到c:\windows\system32\目录下
3. 创建一个符号路径
4. 修改config.rb把上面创建的符号路径和浏览器路径填进去
5. 在FUZZ目录下制定测试的例子
6. 运行ruby grinder.rb  --browser=BROWSER

Grinder是动态生成样本的。对于其它的fuzz来说是先生成待测试的样本，再由浏览器打开。但是Grinder会直接打开规则模版，动态生成样本。这样一来就需要对每次导致crash的值进行记录，Grinder通过向浏览器注入grinder_logger.dll，hook住Javascript中的parseFloat函数。在调用logger.log时，grinder_logger.dll设置的hook回调函数就可以记录下来其内容，并存储为log文件。因为要Hook javascript函数，也就是说要解析jscript9.dll，所以需要这个模块的符号。这就是我们第3布操作的作用。当成功进行Hook之后，会给出提示。

[+D+] Hooked JavaScript parseFloat() to grinder_logger.dll via proxy @ 0x99B0000

此外记录下来的log文件不是直接的样本，需要使用testcase.py进行解析。

.\grinder\node>ruby testcase.rb [--config=c:\path\to\CONFIG.RB] --log=c:\path\to\XXXXXXXX.XXXXXXXX.log --save=c:\path\to\XXXXXXXX.XXXXXXXX.html

About Nduja

根据上面的内容，我们可以看出Grinder其实只是提供了一些用于变异样本的语法，关键的内容还是要依靠自己来进行编写从而生成。

在这个基础上Rosario valotta开发了一套实际的fuzz策略称为Nduja Fuzzer

根据作者的介绍，得知Nduja的开发背景是在市面上已有DOM level1的fuzzer的情况下，去试图fuzz DOM level2和level3以获取更多的成果。

作者原话如下，我标注了一些重点出来：

The usual approach in browser fuzzing leverages on DOM Level 1 interfaces for performing DOM mutations: 

1. a big quantity of random HTML elements are created and randomly added to the HTML document tree 
2. the DOM tree is crawled and element references are collected for later reuse 
3. elements attributes and function calls are tweaked 
4. random DOM nodes are deleted 
5. garbage collection is forced  
6. collected references are crawled and tweaked again

This approach is effective but suffers from some design limitations: 

1. every DOM mutation (e.g. element tweaking, deletion, etc) is performed on a single HTML element, no mass mutations are managed
2. the execution workflow  can only be altered by the cardinality and the type of randomly generated DOM nodes (e.g different tag names, attributes, etc).

The entropy of a browser fuzzer can be taken to a further level introducing some new functionalities defined in DOM Level 2 and Level 3 specifications.

即通过对DOM2和DOM3中的新特性进行Fuzz来增墒。 为此作者举了几个例子作以说明。

Working with aggregations of nodes (DOM Level 2)
DOM Level 2 specifications introduces several new interfaces that allow to perform mutations on collections of DOM elements.
For instance interfaces like DocumentFragment, Range, TextRange, SelectionRange allow to create logical nodes aggregations and execute CRUD mutations on them using a rich set of APIS. 
A quick list of these methods: createRange, deleteContents, extractContents, cloneContents, cloneRange, removeRange, createTextRange, pasteHTML, etc
The expectation is that each of the methods provided for the insertion, deletion and copying of contents can be directly mapped to a series of Node editing operations enabled by DOM Core. 
In this sense these operations can be viewed as convenience methods that also enable a browser implementation to optimize common editing patterns.
It turns out that implementation bugs in this methods can lead to serious memory corruption errors when not correctly mapped to atomic-safe node operations.

Using document traversal data structures (DOM Level 2)
In the classic fuzzer approach, crawling the DOM tree is performed walking the physical tree from the top level node (DOCTYPE or HTML) to the leaves using DOM Level 1 methods (.children, .parentNode, .nextSiebling, etc).
In DOM Level 2 several data structures are available to create logical view of a Document subtree (eg. NodeList, TreeWalker, NodeIterator); we refer to these as the logical views to distinguish them from the physical view, which corresponds to the document subtree per se. 
These logical views are dynamic, in the sense that they modify their structure to reflect changes made to the underlying document.
That's why some memory corruption scenarios arise when DOM mutations performed on the physical tree are not correctly managed on the logical counterpart.

Introducing events (DOM Level 3)
In order to add more entropy to the fuzzer workflow, events firing and propagation can be used. DOM Level 3 specification defines a standard way to create events, fire them and manage event listeners for every DOM node. On top of that, specification defines a standard for event propagation model.
From the spec page (http://www.w3.org/TR/DOM-Level-3-Events/#dom-event-architecture):
"Event objects are dispatched to an event target. At the beginning of the dispatch, implementations must first determine the event object's propagation path."
The propagation path of an event include 3 steps:

1. capture phase: the event propagates through the target's ancestors from the document root to the target's parent. Event listeners registered for this phase handle the event before it reaches its target.
2. target phase: the event arrives at the final target element. Event listeners registered for this phase  handle the event once it has reached its target.
3. bubble phase: the event  propagates through the target's ancestors in reverse order, starting with the target's parent and ending with the document root element. Event listeners registered for this phase must handle the event after it has reached its target.

From the spec page: "The propagation path must be an ordered list of current event targets through which the event object must pass. For DOM implementations, the propagation path must reflect the hierarchical tree structure of the document. The last item in the list must be the event target; the preceding items in the list are referred to as the target's ancestors, and the immediately preceding item as the target's parent. Once determined, the propagation path must not be changed; for DOM implementations, this applies even if an element in the propagation path is moved within the DOM. or removed from the DOM. Additionally, exceptions inside event listeners must not stop the propagation of the event or affect the propagation path."

So the idea here is to let an event fire and alter the DOM tree structure after the propagation path has already been defined. This can be easily obtained attaching random eventListeners to every DOM element, setting the "capturable" flag to true. Whenever an event targeting a node is intercepted by a node's anchestor, some random operations on DOM tree are performed, removing o inserting whole sets of elements. Then the propagation of the event goes on.
Note: this technique proved to be  dramatically effective in crashing IE9/10, probably because IE9 is the first IE version to support standard W3C event model and is not still "bullet-proof".

The listeners map of a node can be altered during dispatch, but is immutable once the dispatch reached that node .

Once determined, the propagation path must not be changed, even if an element in the propagation path is moved/removed within the DOM 

作者给出了Nduja的操作流程概述

• Initialization

• create a given number of random HTML elements
• for each element tweak random attributes/functions/styles
• for each element add a given number of event listeners
• append the elements in a random position in the document tree
• create logical views of a random DOM subtree (nodeIterator, treeWalker)

• Crawling
• Crawl DOM tree
• Create random Range (or similar DOM Level 2 structure) and apply random mutatios on it (delete, insert,surround, etc)
• Crawl DOM logical views

• Event management: events are managed accordingly to the dispatching phase 
• if the event is in the capture/bubble phase:
• remove some random event listeners from the current target
• create random Range (or similar DOM Level 2 structure) and apply random mutatios on it (delete, insert,surround, etc)
• crawl physical tree and logical views
• if the event is in the target phase
• add some other event listeners to the event target node

参考资料：

node
  -browser
     chrome.rb
     firefox.rb
     internetexplorer.rb
     safari.rb
  -core
    debug
      debugger.rb
      debuggerexception.rb
      heaphook.rb
      hookedprocess.rb
      logger.rb
      processsymbols.rb
    configuration.rb
    crypt.rb
    debugger.rb
    logging.rb
    server.rb
    webstats.rb
    xmlcrashlog.rb
  -crashes
  -data
  -fuzzer
    *.html
  -lib
    metasm
  -source
    --部分dll的源码
  config.rb
  crypto.rb
  grinder.rb
  reduction.rb
  testcase.rb
server
  --主要用于分布式节点的漏洞结果汇总，这里不再详述

http://www.freebuf.com/sectool/93130.html

http://blog.nsfocus.net/web-browser-fuzzing/