Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Odd inconstancy in extension behaviour

Thomas | Last updated: May 30, 2018 09:30AM UTC

Hello, I wrote an extension that fails for one of my user throwing an exception: --- Traceback (most recent call last): File "E:\BurpSuite Settings and Extensions\Extenders\OurExtensions\Radar\main.py", line 220, in registerExtenderCallbacks self.includeUI = BtnList("includes", self._callbacks, self) File "E:\BurpSuite Settings and Extensions\Extenders\OurExtensions\Radar\main.py", line 85, in __init__ self._list = JList(self._data_list) TypeError: javax.swing.JList(): 1st arg can't be coerced to java.lang.Object[], javax.swing.ListModel, java.util.Vector --- self._data_list is initialized as a Python list with the [] constructor like so: --- self._data_list = [] --- We used the diagnostic tool of Burp to check the difference in our configurations and they are the same. I double checked the Jython jar which is also the same. He tried to restart Burp as well as unload/reload the extension but without success. Do you have any ideas what I should look at or consider to solve this ? Thank you,

PortSwigger Agent | Last updated: May 31, 2018 07:52AM UTC

Hi Thomas, Thanks for your message. I'm not quite sure why you're seeing different behavior on different systems. If I try similar code on my Mac, it works correctly. You could try using an explicit Java array instead of a Python list: jarray.array(['a', 'b', 'c'], String) You'll need these imports: from java.lang import String import jarray Please let us know if you need any further assistance.

Burp User | Last updated: Nov 13, 2018 11:27AM UTC

Hello, In case the response helps someone I leave it there. The symptoms were that a user of my extension had the above mentioned issue of type despite having the same Python settings,OS and configurations as anyone else. The reason is this list was saved in the java preference store. For some reason when the extension was corrected with the correct types, the data in pref store were kept the same despite the call to override them (savePreferences~~ish method) being perform. Hence keeping the same exception despite update of the extension's code. Solution was to remove the pref stored in registry. Cheers,

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.