Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


ImportError: No module named burp_extender #7

dorneanu opened this Issue · 8 comments

3 participants



i've downloaded your package and tried to get it work. First I've compiled the sources:

$ javac -cp ../jython.jar java/src/.java java/src/burp/.java

Afterwards I tried to star burp by:

$ java -jar ../jython.jar -B burpsuite_pro.jar -i
Traceback (most recent call last):
File "", line 117, in
start_burp(opt, *args)
File "", line 15, in start_burp
from burp_extender import BurpExtender as MyBurpExtender, ConsoleThread
ImportError: No module named burp_extender

As you see there is "no module named burp_extender". Any ideas?!




I've solved this one by myself. Assuming your current working directory is "jython-burp-api" use:

$ java -jar ../jython.jar -Dpython.path=Lib/ -B burpsuite_pro_v1.5.14.jar -d -v -i

"-Dpython.path" specifies where to look for the class BurpExtender which is located at "Lib/".


Glad to hear you were able to resolve the issue. The Installation/Running section in the README notes to cd into jython-burp-api directory.

I'm going to keep this issue open as a reminder to update the README with steps on running jython-burp-api with the new Burp Extender API's introduced in 1.5.04+.


Thanks for the quick response! BTW: Really nice work!


I ran into dorneanu's issue as well when running it with the old style API, but also an equivalent issue when doing it with the new (1.5.04+) API.

When loading into Burp via the "Load Burp Extension" dialog, it errors out with:

Traceback (most recent call last):
  File "C:\Tools\Burp\BurpExtensions\jython-burp-api\Lib\", line 25, in <module>
    from gds.burp import HttpRequest
ImportError: No module named gds


That seems to indicated that Burp isn't actually adding the directory to the path, just that specific file. The result is that the method you describe in your otherwise very helpful and clear blog post ( doesn't actually work if followed.

One possible fix to that would be adding code like this near the beginning of, just before it starts trying to load stuff from gds:

# Patch dir this file was loaded from into the path
# (Burp doesn't do it automatically)

Let me know what you think, and I can submit a pull request if you like.

(As for why you wouldn't have encountered the issue yourself, I confess to being a bit puzzled. I'm using the latest Burp, 1.5.16, but I can't imagine they've changed the python path behavior since 1.5.04...)


Thanks @coffeetocode for that. I really am not sure why you guys are experiencing these issues. What directory are you launching Burp from, and under "Python Environment" in Extender > Options, did you specify a "Folder for loading modules"?


Thanks for the quick reply.

The "Folder for loading modules" will absolutely address it (that's what I went to before checking what code would need to be added to make it work without). So, if you were expecting people to be setting the python module folder to the jython-burp-api/Lib dir, then that's the disconnect right there (though, I don't believe I saw that in the instructions, so maybe double check where you think you mentioned it).

So, that will do it, but I'm not sure it's the right way.

I believe it's a Burp-wide setting, so requiring it for one extension to function means that others couldn't use it to load their stuff (especially relevant if one wants to use the introspection from the jython prompt provided by jython-burp-api to ease in developing a new extension; fantastic feature for that). I generally point the Burp module folder at my regular python (not jython) site-packages directory so that I can use regular pip-installed packages (requests, passlib, etc, which have obvious usefulness).

Seems like there are a few ways to address it:

  • Make jython-burp-api an installable python module, so that users can set the Burp module folder to their site-packages dir, and have access to both the modules for this extension, as well as anything else they want to use
  • Ask Portswigger to allow multiple module loading dirs
  • Have jython-burp-api patch the sys.path var to make sure it's able to load modules it expects
  • Let people loading multiple extensions with different required libs just figure out which modules need to be imported by their extensions and dump them copies of them all into a single dir, and use that as the Burp module folder (it appears this might have been what the Burp folks had in mind, but it's kinda janky)

Revisiting this issue, I think the easiest way to address this is by dynamically adding the jython-burp-api/Lib directory to sys.path.

I would ideally like to be able to import packages in both Jython and CPython, however that might not always be possible due to Java specific imports in some modules. This would have the added benefit of being able to write code that can be easily run outside of Burp. I think this would best be addressed by making jython-burp-api an install module.

I personally use virtualenv whenever working in Python, and install packages using easy_install/pip to that virtualenv's site-packages directory. However, using the Jython Standalone jar in Burp, there is no site-packages to install packages to.

Do you maintain a separate Jython install or are you just pointing the modules folder at CPython's Lib directory? The latter seems like it would raise issues whenever you attempted to import a c-based standard library...



Thanks for the reply.

I agree with you that the easiest way to make sure jython-burp-api works for everyone with no surprises is to have it add itself to the path. It might be considered hacky in some other contexts for a package to manipulate its own path, but I think this is exactly the sort of situation that workaround was intended for. Should be a small change; I think the example code in my comment above should do it.

As for making jython-burp-api an installable module for running outside of burp; it's potentially useful, but I wouldn't want you to sink too much time in factoring stuff out since I think much of the most useful stuff is going to be pretty closely tied to Burp classes anyway. Your call of course.

For virtualenv, totally agree; that's the way to go normally. I haven't figured out how to get Burp+Jython to play nicely with virtualenv/pip yet, so I haven't included that as part of my regular working process when doing Burp extension stuff. I also haven't figured out if Jython has any equivalent to site-packages, though I think it doesn't and that's what the modules field in Burp is intended to work around.

I personally don't maintain a separate set of modules for Jython, and instead just point Burp at my cpython site-packages (or a virtualenv would work too). It actually works pretty well because the standard library is drawn from the Jython implementation, and any packages that are pure python work just fine (in particular, requests :))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.