Burp Suite User Forum

Create new post

JRuby + Swing: Stderr doesn't go to UI until extension reload

Jonathon | Last updated: Jul 06, 2015 02:19AM UTC

Burp 1.6.20, tried JRuby 1.7.12 and In registerExtenderCallbacks, I instantiate a class that creates a Swing UI for my extension's configuration. The config UI creates a DefaultTableModel to hold my config data and JButtons for adding and removing rows. The JButton add/remove actionlisteners call a method in a Ruby class that reads the table data from the config UI's DefaultTableModel. So far, so good. Here's the weirdness: When an exception is triggered in the config UI class or in a downstream method (e.g. the method called by the JButton action listener), the exception's output does not appear in the Burp UI. To get it to show up in the Burp UI, I need to pass the Burp OutputStream callbacks to the config UI initializer (i.e. J::System.setErr(J::PrintStream.new(caller.callbacks.getStderr()))) and then reload the extension. If I restart Burp, exceptions won't show up in the Burp UI until I reload the extension again. This could very well be caused by my inexperience in programming swing GUIs. I've been banging my head on this for two days, so any help would be appreciated.

PortSwigger Agent | Last updated: Jul 07, 2015 07:56AM UTC

To send exception stack traces or other debug information to the UI tab for your extension, you need to explicitly pass it to the output/error streams provided for your extension. If there are unhandled exceptions in a background thread of your code (as it sounds like was the case for you), then Java will just send these to the normal console. The solution you tried of setting global standard error to the error stream for your extension means that all stderr generated by Java will be directed to your extension. This includes any unhandled exceptions generated by other extensions or by Burp itself, so this probably isn't a good idea. The reason for the problem/challenge is that once your extension starts background threads, Burp can't determine that any unhandled extensions "belong" to your extension, and so they just get handled like any other. Probably the best solution is for your extension to explicitly set the unhandled exception handler on any background threads that it starts, using Thread.setUncaughtExceptionHandler(): http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#setUncaughtExceptionHandler(java.lang.Thread.UncaughtExceptionHandler) You can provide a custom handler that outputs any exceptions to the error stream provided for your extension. That should hopefully do the job.

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