Why Offensive Tool Development?

Offensive tooling is one of those fields where its usability purely depends on the environments you find yourself in. For REplay, I chose to integrate the idea of developing offensive tools for reverse engineering to get you a good picture of some of my own personal experiences- mainly where user mode blocks existed and where 90% of frameworks including backup ones were blocked from the program and where some security systems were just a complete mess to break past.

Why offensive tooling is helpful

Developing or knowing how to engineer applications such as auto exploit frameworks or parsers on the spot can be useful for so many different reasons. Lets take a scenario where I was reverse engineering an IoT device that used proprietary files and many different network protocols and special and unique codes sent to the device to execute commands.

During this research- I needed to develop tools to...

• Automate research: Automating the research from some of the devices API endpoints to help me easily interact with the device remotely. Mainly for interrogability and for fuzzing and other wide testing.

• Parsing, Generating, and Analyzing Proprietary File Formats: This was a HUGE one. Because the servers and other systems on the device used this file format as some form of data storage during transmission as both the response and requests needed this format, a tool was needed to be built as there were no pre-existing ones for this. Utilizing the tools to generate, parse and analyze this file format was HUGE because it allowed me to interact with many system services and servers more efficiently.

• PoC/Exploit Dev: Exploit dev is an obvious one- at some point, especially on IoT devices where many use porprietary systems or hybrid builds of existing systems you will need to proof to people that you can exploit something. Sometimes, you may even need to build a custom program to automate this and show how easy or how hard said flaw was to exploit.

• Making My Life Easier: A lot of the times it just made my life easier as a researcher and could be used in the future on other devices produced by the same vendor if the vendor used the same algorithms or formats on other devices. Having these tools pre-developed just helped thrive my research in both information gathering and exploitation phases of the research.

Why I Included It

I included this in REplay to introduce people to a different realm of logic. As reverse engineers, we are going to find many moments where we need to apply deep logic- however, in some scenarios, it needs to go even deeper.

Being able to analyze a program is one thing- but being able to implement the reversed logic into code is another. By integrating this into the writeups and REplay, it gives people another way to look at things and also a way to understand how such logic can be automated external to the program you are reversing.

This of course depends on the person, but this was very helpful to me and a few other security researchers I asked around the community! So I figured why not include it? What is the harm?