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.