How to instrument redcarpet

[CaptainTux]

I want to fuzz redcarpet using afl-ruby.
I patched the original afl binary as required and saved the binary as afl-fuzz-rb. After setting everything up I tried running afl with the command afl-fuzz-rb -i afl_in -o afl_out -m 500M -- ruby redcarpet @@ where redcarpet contains the following code:

require 'afl'

unless ENV['NO_AFL']
  AFL.init
end

lib_path = File.expand_path('../../lib', __FILE__)
$:.unshift(lib_path)

AFL.with_exceptions_as_crashes do

  require 'redcarpet'

  testcase = File.read(ARGV[0])

  renderer = Redcarpet::Render::HTML.new(render_options = {})

  markdown = Redcarpet::Markdown.new(renderer, extensions = {})
  markdown.render(testcase)

end

And it works. However, it does not seem to instrument the libraries. I have to admit I know close to nothing about ruby. But since I am running the code in an interpreter, I do not see how I can instrument the rest of the code at all. Do I just have one path only? Because afl is going through the cycles pretty fast. Is it in this case even useful to fuzz ruby with afl?

[richo]

Hi there,

Sorry I missed this until now. I would expect this to find coverage, what did you have in your initial testcase?

ruby-afl under the hood uses TracePoint to hook the VM to report branches and function invokcations so you'll get instrumentation from native ruby code. Is redcarpet primarily a C extension? That could be affecting your instrumentation (You'll see the calls into C methods, but not whatever the C stuff does under the hood unless it's invoking methods via the VM)

[CaptainTux]

Since it's been a while, I have reinstalled everything. I am still getting the same problem, see the image below My test case was this: https://raw.githubusercontent.com/mxstbr/markdown-test-file/master/TEST.md

[richo]

ok so first of all, that's a pretty huge testcase. I would for sure minimize it substantially.

Secondly, I just flipped through the source of redcarpet and it's almost entirely implemented as a C extension, so you would need to build the c extension with the afl-* suite of compilers in order to instrument the C code. with that said, at the point where you have a C entry point it's probably going to be way faster to bypass the ruby VM entirely and just drive it directly would be my hunch.