Wrapping or modifying?

Customizing open source security tools to suit your bug hunting workflow.

Sometimes, wrapping may not be the best choice.

There are a lot of open source security tools out there: whatever you’re trying to do, there’s probably one that promises to do it for you.

Top 10 Security Tools for Bug Bounty Hunters

But as many options there are out there, it could sometimes be difficult to find a tool that does exactly what you want, in addition to fitting in seamlessly with your existing workflow. In that case, you’ll either have to

• Create a wrapper for existing tools, or
• Modify the tool yourself, or
• Sometimes both.

Picking the method that best suits your needs is key to building an efficient and maintainable security toolbox. Today I am going to discuss the choice between creating a wrapper script or directly diving into the codebase and some pros and cons of either approach.

The case for wrapper scripts

Creating wrapper scripts is the easiest way to integrate a new tool into your existing workflow.

If the open-source tool does most of what you want, all it takes is a few lines shell script and you have a new method in your arsenal. Here are some pros of wrapper scripts:

• It’s a lot less work and will save you tons of effort.
• You can still use the tool even if you don’t have the time to learn the language.
• You can use the tool even if the codebase is convoluted and hard to understand.
• It’s easier to keep organized: you won’t have to worry about maintaining documentation for your custom code and it’s easy to update to new versions of the tool.

However, from my personal experience as a security researcher, it’s not often the best choice. You miss out on the potential for optimization and the learning opportunity of modifying the tool yourself.

The problem with automation.

The case for code modification

Obviously, wrapper scripts are almost always the most practical and realistic way to go. But as security researchers, there are great rewards to be reaped by doing things the hard way: dive into the code base and modify it to your liking. Here are some reasons why you might want to take this approach if you have the time:

• You can still use the tool even if it is built very specifically and does not fit with your environment. Many security tools now thrive to be as user-friendly and simple to use as possible. While this is a good thing, it also means that they are often without too many built-in customization options.
• Customize and fine-tune how the tool works: don’t like how the tool is handling certain requests? Not a fan of its report generation aesthetics? The power is in your hands to change it.
• Opportunities for optimization: you’ll have the opportunity to make the tool more efficient, for example by implementing parallelism or by pruning redundant components.

In addition, here are a few ways that you might benefit in addition to the practical benefits above:

• Gain in-depth security knowledge by learning how the tool works: it’s a unique learning experience to see how other security researchers implemented a specific feature. You can often gain insight into the thought process behind their recon and testing methodology.
• Practice: modifying an existing tool is a lot different than writing one from scratch yourself. You have the existing code base as a guide to draw from, and it’s a gentle way to getting more experience building security tools.
• You sometimes get to learn a new language or technology!
• You get to contribute to the development of a tool you love.

Lessons learned

In short, when you need something up and running immediately, the wrapping route is the way to go. It’s a lot simpler, more practical and there are fewer complications.

But if you do have the time, there are amazing benefits when you dive into the codebase. The hidden treasure is a unique learning experience beyond regular black or white box engagements: a window into another hacker’s thought process when they were faced with the same technical problem.

Automation is a labor of love and it always amazes me how much thought and ingenuity is behind many open source security tools that I use. Through my process of integrating these tools into my workflow, I learned that:

• Automation saves time. A well-crafted tool will save you hours of manual labor, especially for mostly repetitive tasks like searching for new targets to expand your attack surface.
• Sharing saves time. Sharing knowledge and tools will encourage others to do the same and in turn, strengthen the security community and your own personal toolbox.
• When writing code that is to be shared, try to make the use cases as general as possible and avoid making assumptions about the user’s environment. This will allow your tools to be used by a wider audience.
• Write well-documented code so others can understand the code and contribute to it in the future.

Next up:

I really enjoyed the process of diving into commonly used security tools. Next time, let’s talk about the best tools used by bug hunters out there, how to outfit them for specific testing environments, and some ways to speed up the development process.

Thanks for reading! What are your thoughts about open source security tools? What are some of your favorite tools that you use?