Abstract: Tools are fucking arrogant. By their rigid nature, they say you're only supposed to do X, Y and Z. But you can't do A, B or C-- that's just not what the tool was designed for, man! You can't do that! "Go find another tool that does that," the tool says, dismissively brushing you off to go find some other guy that wrote some other tool that does some other thing that puts you in some other box that still doesn't accomplish some of what you're trying to do-- at least some of the time.
This isn't to say that tools are completely useless-- there are common tools that we just can't live without when we go about our daily routines of penetration testing, reverse engineering and even programming. Tools solve problems. Without tools, we'd be collectively going at a slower pace than LIGATT's hacking lessons. However, the ease of use of a given tool abstracts you from potentially necessary concepts that will make you a better Whatever That Tool is Trying to Make You Better At. This talk aims to present an argument as to why you should (and shouldn't) learn to write tools yourself and how the process of doing so benefits you more than simply learning to use the tool.
For over twenty years, frank^2 has worked in the legal department of LIGATT Security International at his role of spin doctor. He obviously fucking sucks at it, though. But I mean, even Karl Rove couldn't spin this company out of the bog of plagiarist shit its gotten itself into. You can't get blood out of a stone, much in the same regard the World's Number One Hacker couldn't pop a shell on an MS08-067 vulnerability. I mean, what the fuck: "to completely hack a machine you must get passwords associated with usernames and increase permission level." How the fuck do you spin that into something intelligent? Dollars to donuts if Karl Rove actually worked for these guys he would probably just spin them out of their finances and run away laughing, sacks full of cash clad with cartoonish dollar signs and all.