Simple Powershell Process Monitor for Fuzzing

While doing some fuzzing recently I ran into trouble with Sulley’s ( process monitor. For those who are unfamilar, when fuzzing, the process monitor hooks into the target process and grabs valuable information in the case of a crash (e.g. register values). It’s job is also to restart the process when it crashes.

In my use case I was doing remote fuzzing of a network service. On the target system, the service I was fuzzing had to be started by another executable. Confused? Think of the workflow like this,

C:\MyTargetMaster\> master_process.exe -startprocess mytargetProcess -port 9999 -username Administrator -password boomboom

As you can see above master_process was starting another listening service (mytargetProcess) on port 9999. In this case I already knew there was a crash possible in the service I just needed better information about the exploitability during automated testing, hence process monitor. Unfortunately, this scenario was not playing nice with Sulley so the workaround I chose was Powershell.

  $Running = Get-Process <MyTargetProcess> -ErrorAction SilentlyContinue
  if (!$Running) {
    $arguments1 = "-startprocess <MyTargetProcess> -port 9999 -username Administrator -password boomboom"
    Start-Process "C:\MyTargetMaster\master_process.exe" $arguments1
    Start-Sleep -s 10
    $arguments2 = "-pn <MyTargetProcess> -cf cmd.ini -loga results.txt"
    start-process "C:\Program Files\Debugging Tools for Windows 64-bit\cdb.exe" -UseNewEnvironment $arguments2
  Start-Sleep -s 3

The script above:

1. Checks to see if a specific process is running
2. If it’s not running, start the Process with relevant arguments
3. Hook the cmd line version of WinDBG (cdb) onto the process and run the script cmd.ini. Log the notes from each crash to results.txt; “-loga” appends to the log file so it will contain the results from all the crashes.
4. If the process is running, it sleeps for 4 seconds.

The cmd.ini script is simple but useful. In the case of a crash it runs the !exploitable ( WinDBG extension to determine the exploitability of the crash. It then records the register values at the time of the crash. If you are using Peach ( you are probably already doing something similar.

g;!load MSEC64;!exploitable;r;q

And that’s it! Tracking which packet caused the crash is an exercise left up to the reader but it’s not too difficult following the Sulley session and the order of crashes.

Share Button