(A)I reverse engineered Burp Suite's project format and built a tool that exports Proxy history, Repeater messages, and Target Site Map traffic. See parsiya/prub and the documented format.
I did not "hack" Burp; this is not a crack. The tool only extracts data from existing project files.
One of my biggest gripes with Burp's extension API is the lack of access to Repeater tabs. You can export all the proxy history with an extension (or manually in Burp), but you cannot do the same for Repeater tabs.
In the past, I've used gimmicks to capture all my traffic:
string to extract requests/responses.Tokens are still cheap and AI is good at reversing, so I am working through my bucket list1.
Clear that project backlog before the end of the free token era.
The target version is Burp Pro 2026.7.1.
I am hands-on with AI. I like to steer extensively, review everything, and start fresh sessions to keep the context window small.
There were many false starts. Maybe (A)I could have done this autonomously with a good eval harness, but prompting specific things was easier and faster. See the activity log for detailed tracking.
This section documents what I tried, what didn't work, and other issues I had during this process.
Originally I wanted to use Ghidra, like when (A)I reversed my keyboard utility but normal decompilers worked here.
| Class Statistics | Num | Notes |
|---|---|---|
| Classes in the JAR | 55,120 | Includes Burp and bundled dependencies |
Classes in the burp package | 20,609 | Important stuff |
| Top-level Burp input classes | 20,491 | Baseline used for source filename coverage |
| Focused JADX source files | 19,030 | 92.87% top-level coverage; 1,461 missing |
| Vineflower source files | 20,502 | 99.81% top-level coverage; 39 missing |
burp package. Both JADX and
Vineflower went OOM.As models become more intelligent, they invent extra objectives and repeat
useless tasks: running git diff after every file change outside Git
repositories, getting stuck on Markdown warnings, line endings, and empty lines,
or, worst of all, making up goals.
For example, I asked AI to move a file from the parent directory to
prub/ai-docs and then edit it. Instead of doing a normal mv (I realize I
should've done the move myself), it copied the file from memory and then ran
three different commands (cmp, 2x diff) to check if the file has been moved
correctly.
...
Generating patch (230 lines) in ...
Ran terminal command:
cmp -s ai-docs/activity-log.md prub/ai-docs/activity-log.md
&& printf 'activity logs match\n'
The byte-for-byte check did not report a match, likely because the source
Markdown uses Windows line endings while the new file uses repository-standard
Linux line endings. I’ll confirm content equivalence while ignoring CRLF, then
make the link and inventory edits.
Ran terminal command:
diff --strip-trailing-cr --brief ai-docs/activity-log.md prub/ai-docs/activity-log.md
Ran terminal command:
diff --strip-trailing-cr --unified=1 ai-docs/activity-log.md prub/ai-docs/activity-log.md
Clopus 4.6 would never, RIP friend 😭.
AI also repeatedly wandered beyond goals. My initial goal was Repeater and Proxy, but it kept trying to investigate Scanner and specifically Logger. I had already mentioned that Logger information is not persisted in the project file. It's like talking to a cat!
But AGI is here!!1!
Image credit: Mark Vomit @ Tumblr
Discussing the format is useless in the age of AI. Just pass ai-docs to your
favorite LLM and go from there. Instead, here are interesting things (A)I saw in
the format.
Each compact object begins with metadata describing its own fields:
+0 flags
+1 object type
+2 subtype/schema
+3 descriptor count
+4 descriptor table
Each three-byte descriptor contains a field ID and a signed relative offset:
field_id: uint8
offset: int16 big-endian
Example:
00 01 00 02 0F 00 0A 12 00 12 ...
This says:
0.1, subtype 0.15 begins at object offset 10.18 begins at offset 18.For a Proxy item, fields 15 and 18 can contain addresses of raw request and
response records. A parser searches the descriptor table by field ID instead of
assuming fixed byte positions.
Projects store an installation ID. If you've opened projects on a different machine you might have seen the "take ownership" part. I think this is correlated with that. If the current Burp sees a different installation ID and you ask it to "take ownership" it probably overwrites the installation ID in the file.
The installation ID does not appear to contain personal identifiers. It is
random and not derived from license data. Burp reads Java preference
burp.suite.installationId. If it is missing or invalid against
^[a-z0-9]{20}$, it generates 20 random lowercase alphanumeric characters and
saves them back to preferences.
If PortSwigger knows this ID and sees a Burp project in the wild, they will know it was you. But then again, the contents of the project file are far more important and now you have bigger problems.
I have done Repeater and History, but you can add more. Scanner is probably
the most popular target and should be doable with a couple of sample projects
and the existing ai-docs.
It would also be nice to edit projects. That would allow us to create a wrapper for Burp Community to save and load projects.
My manager (oops, he asked me not to call him that), I mean, my teammate (oh, he told me not to quote him, either), OK an anonymous wise man also told me "Let's do great things together while we are here."
Me and the anonymous wise man
Well, this was fun. If you want to continue the project, feel free to do so. The MIT license is magic. If you have any feedback, you know where to find me.