During the second day at Black Hat, somewhat depressed by yet another futile attempt to locate coffee and fighting human gridlock, I decided that it was no longer worth the effort and simply sat down in the nearest conference. And I am glad I did as that random selection of presentations turned out to be one of my favorites of the week. The presentation was called Visual Forensic Analysis and Reverse Engineering, presented by Gregory Conti and Erik Dean. I would offer a link for you, but I have been unable to find the slide deck on line. It is on the CD that was included in the Black Hat goodie bag for those of you who attended, and some of the discussion points are located here (http://lcamtuf.coredump.cx/oldtcp/tcpseq.html)

The Conti & Dean presentation shows how, by using different graphing techniques, to identify the contents and even reverse engineer binary files. By performing ?dot plots? and ?byte plot? examples of binary files, you can very quickly detect certain patterns within the binary file that tell you what is contained within the file. Much like a human fingerprint, uuencoded content, text, Word documents, bit mapped images, jpegs, compressed files and encrypted files each had a unique visual signature. For files that may contain several items, it was easy to pick out the begining and ending points of blobs within the file, and then examine specific binary objects in more detail. They showed a couple of examples of extracting out image files from a huge binary file in less than 30 seconds.

You know you are a geek when:

I remember in the early ’90s that when debugging code or core dumps I was often just winging it. You really did not have a valid stack trace, so you were rummaging around memory looking for something unusual, or some pattern that gave you a clue as to what went wrong. It was more art than science, and it was usually some visual clue or something that just did not look right when you found the root cause of the bug. Again in the mid-90s I can remember loading binary files into a text editor to attempt to, ahem, circumvent and ?no-op? out the licensing module which could often be located through a visual inspection. Of course, this was purely for academic purposes. This same technique was effective in hacking video game binaries and save files (slide 46 of the presentation shows a Neverwinter Nights database file as an example). And it was all based upon looking at the binary structure for patterns and experimenting with value substitutions to alter game functionality.

But the graphic tools take this to a whole new level. How do you know your PRNG is producing random numbers? During the presentation, the evolution from these early generation tools and methods was discussed, and then they showed off tools that provide different 3 dimensional graphic representation of what data looks like. One of the examples that I was most impressed with was the graphs that show a distribution for numbers. These are examples of PRNG output (http://lcamtuf.coredump.cx/newtcp/). Random? It is not particularly easy to demonstrate the pseudo-random number generator you are producing random numbers, or collecting entropy to see your random number generator. But by graphing them in this way, you can very quickly see if you have reasonably good randomness ? or not close at all.

Anyway, I thought this was a very cool forensic tool for binary files. Check out the graphs as they are very impressive.