Slopping a Burp extension with DeepSeek and pi
I’ve been meaning to try out the DeepSeek models for a while now after giving in to the hype that is its cheap pricing compared to those offered from frontier companies. As I’m playing with agents, LLMs, I thought: why not pick something that I wrote for web pentesting before, and turn that into a Burp extension. Should be a pretty simple task for a clanker.
Setting up a project template
Why Jython? The script I wrote was in Python and I figured it’d be a lot easier than trying to translate it to Java. I’ve also had bad results using LLM to write python extensions before, as the LLM would always mix up Python3 syntax and make up stuff that didn’t exist in Extender API.
I went ahead and copied the Burp starter project template to get started. The starter project comes with a CLAUDE.md that provides context to Claude Code for working with the project. This is done by feeding documentation of the Montoya API and sample extensions to the agent in docs/. Since this was setup for writing Java extensions, I needed the documentation to be rewritten for writing Jython extensions.
First task, ask pi to convert the agent instructions for use with Python and the legacy Extender API.
look in docs/ of jython-template these markdown files were taken from ExtensionTemplateProject for Burp but these were originally for MontoyaAPI which uses Java. I want to convert these for use with Python (Jython) for writing Burp extensions through the Extender API
The results looked OK to me? The only things I added manually were some sample blogs for additional context. You can look at the template project here.
The extension we’re building
A while ago at $WORK, I was having troubles with WAFs while building a POC for XSS on a target application. After reviewing the client-side JavaScript, I knew it was vulnerable to XSS but the WAF was dropping all requests that contained injection payloads, which included <> characters. I was able to bypass this using unicode denormalisation, the code snippet used look somewhat like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
import sys
import unicodedata
def find_unicode_comparisons():
less_than = []
greater_than = []
for i in range(sys.maxunicode + 1):
char = chr(i)
try:
name = unicodedata.name(char).upper()
if "LESS-THAN" in name:
less_than.append(char)
elif "GREATER-THAN" in name:
greater_than.append(char)
except (ValueError, TypeError):
continue
return less_than, greater_than
lt_list, gt_list = find_unicode_comparisons()
with open("less_than.txt", "w", encoding="utf-8") as f:
for item in lt_list:
f.write(f"{item}\n")
with open("greater_than.txt", "w", encoding="utf-8") as f:
for item in gt_list:
f.write(f"{item}\n")
I lost my stuff so I had LLM reproduce it. You get the idea.
So, I wanted a Burp extension that generated wordlists for unicode denormalisation attacks instead of doing it manually everytime.
Slop, slop, slop
I placed my basic project requirements in PLAN.md and had pi iterate on it as it worked if it thought there were improvements to be made.
1
2
3
4
# PLAN for unicode fuzzing wordlist extension
- [] Extension panel for generating wordlist given a character.
- [] Ability to highlight a character from UI, right click and forward it to the extension panel
Here’s the initial prompt and it’s off to work while I go doomscroll:
1
Implement a burp extension that generates wordlists for unicode equivalent characters for fuzzing. There is a PLAN.md, iterate on it as you work, adding missing QoL features if needed, right now those are the main requirements.
Does it work?
After 10 minutes, pi built the first iteration of the extension.
Do I understand what it wrote? Absolutely not The code was horrendous and I didn’t bother. We’re not building enterprise software, code quality is the least of our worries. As long as it works, it’s good enough for me :)
Outside of a few UI bugs that were fixed after prompting pi again, I had a working extension that did what I wanted, while I was goofing off.
Closing
With DS4 Flash, the whole thing costed $0.066 which I think was pretty good. The main problem I have was how the agent wasted time (and tokens) writing unit tests and running them. For a quick Burp extension, I don’t think I’d care about maintenance so testing is redundant. Moving forward, I’d add those to the agent instructions so that it doesn’t get stuck on unit testing.
I exported my session and you can read it here.