Before You Read:
This blog will be heavily edited and does not guarantee any intelligence included!

🚀 Goal and Requirements: Setting the Foundation

First things first: let’s talk goals.
We’re building a tool/framework with scalability at its core. One of the key features I’m focusing on is extensibility. The idea is for the end user to write their own scripts and extensions to exchange almost every component of the tool.

Sure, tools like Burpsuite and ZAP offer these capabilities, but they often remain underutilized. I want to create something fundamentally built around extensions and plugins. The vision? A standardized interface that lets plugins work seamlessly, with unlimited access to the tool’s resources and capabilities.

The user experience I’m aiming for is inspired by Burpsuite and ZAP because they do a lot of things right. But whenever I use them for a project, I feel like they lack some functionality that I really need and doesn’t seem to exist. For example, when using ZAP, I often feel like I need global rate limiting to stay hidden in a red team assessment. I want to run multiple tools and scripts at the same time against the target, but I don’t want to configure each program. Even then, 10 scripts firing one line per second can still add up to quite a bit of traffic.

Another big feature I’m missing is the ability to configure multiple proxies, including backup proxies in case one gets blocked. For instance, if my usual proxy fails to establish a connection, it should automatically switch to Tor. What I’m trying to say is that these tools need to be polished! And rather than polishing them, I’ll just write my own little crown jewel.

🛠️ Supported Languages

Now, let’s talk tech. The end product should be extendable in every language. That means the documentation needs to be detailed enough to support writing APIs for multiple languages.

For the beginning, I’m starting with Python, even though the main engine will be written in Rust for performance. (Yeah, I know, Rust—I’ll probably hate myself later, but it’s for the greater good of speed!) This means I’ll also need to write a library in rust for python that makes it possible to access functions or replace key components. This will have to wait until I completely settle on the fundamental structure of the program.

My current vision is to write a base engine in Python and then implement extensions as libraries that are dynamically imported into the program.
For this to work, we need to write an interface that can read in python files and supply the necessary information to the base engine.

🌟 Must-Have Features

Now we’re getting to the good stuff—features that really need to be included. These will be extension-defined but are absolutely essential.

Here’s my personal non-negotiable list:

  • Pause/Shutdown and Resume: I need to be able to stop the system and return to the exact same point in the task.

That means we need these four core functionalities:

pause: pauses the task while keeping the systems running 
resume: resumes the task after being paused 
save: writes the current state to disk and prepares for shutdown (e.g. triggered by pause) 
restore: restores the saved state and gets the system ready for resume
  • import entrypoint: Extensions need to follow a standard. They are required to tell the base engine what they are and how to use them.

🏗️ Structure

The structure is one of the most important parts of the planning process. I’ve already thrown around some buzzwords without diving into the details.

What I mean by “base engine” is the functionality to extend the program and load/interpret additions.
Also, what I want to include in the base engine is the basic functionality of this proxy—being able to send requests, manage traffic, and act as a full-fledged proxy tool. The basic main service provided by the programm should be already included. Everything elso, from fuzzers to osint tools should be implemented as an extension. In addition, every component should implement a possibility to extract it’s entire data structure for other components to use.

âť—Problems

I want to develop this proxy tool because traditional tools like Burp Suite and OWASP ZAP share similar structures, which leads to comparable challenges. While these tools can be configured to proxy content for an entire team, only one operator can interact with the platform at a time.

Additionally, both products are built in Java, which introduces significant overhead and can result in slow performance. During my experience scanning a large target with numerous subdomains, I noticed that these scans tend to retain requests in memory, adversely affecting the overall performance of the system.

In my opinion, a more efficient approach would be to return the resulting data whenever a request is made. This data could then be processed by middleware and stored in a database. By doing this, we can avoid saving multiple copies of the same request/response data. For instance, if the only variation is a Date: header, it may not be worth saving that data again.

Of course, such features should be customizable, allowing operators the option to save all requests if they choose to do so.