Uninformed: Informative Information for the Uninformed

Vol 5» 2006.Sep

Next: Part II Up: Implementation Previous: Part I   Contents

Analyzing the output

Pedram has developed a set of Python scripts to support the .bpl and recorder output file, such as adding register metadata to the graph, filtering generated breakpoint lists, additional GDE support for difficult graphs, combining multi-function graphs into a conglomerate graph, highlighting interesting blocks, importing back into the IDA changes made directly to the graph, adding function offsets to breakpoint addresses and optionally rebasing the recording addresses, and much more. Pedram provides detailed descriptions and usage of his python scripts in his manual. The Python scripts used for formatting the .gml files (for block based coverage) are ps_process_recording and ps_view_recording_funcs. The ps_process_recording script is executed first on the pluto.sys.0 which will produce another file called pluto.sys.0.BadFuzz-processed. The ps_view_recording_funcs is executed on the pluto.sys.0.BadFuzz-processed file to produce the file called BadFuzz.gml, which is the chosen name for the initial testing technique. More information on Pedram's Python scripts, reference the Process Stalking Manual. Opening the resulting .gml file will enable us to view the following graph.

Executed blocks are available in pink, unexecuted blocks are shown as grey, paths of execution are green lines, and unexecuted paths are red lines. At this point it is important to note that the code block starting at address 00011169 does not get executed. This is detrimental to our testing process because it appears that fuzzer supplied data is passed to it and it does not appear to get executed. Based on this evidence, we can conclude that a readjustment of our testing methodologies needs to be put in place so that we can hit that unexecuted block.

Analysis indicates that the device driver does not execute block 00011169 because a comparison is made in the block at address 00011147 which reveals that [eax] does not match a specified value. Since eax is pointing to the fuzzer supplied data, we should be able to adjust the fuzzer to meet the requirement of the 00011161 cmp dword ptr [eax], 0DEADBEEFh instruction, which will allow us to get into block 00011169. BetterFuzz.exe was improved to do complete the previous description.

Next: Part II Up: Implementation Previous: Part I   Contents