Recently, during a red team engagement with my colleague Maurizio, we came across a website that seemed very outdated. Quickly analyzing the HTML, we noticed something that brought a smile to our faces: a Java Applet.

First thought: the backend will definitely not work anymore… But what if it works!

First, we needed to run the applet. A possible solution would be to run it in an old browser in a VM, but we would leave this option as a last resort. Instead, we installed a version of OpenJDK 8 and used the appletviewer binary to run the applet. We preferred to use a not-very-recent version of OpenJDK to minimize compatibility issues with the old Java version probably used to compile the applet, and if I’m not mistaken, the appletviewer binary is no longer available in the latest Java versions.

Of course, making it work and routing the traffic through Burp Proxy took some time and required fixing various issues related to signatures, certificates, TLS ciphers, proxies, and so on. Without delving into the details of all the issues, this is a summary of how we managed to make things work in our scenario.

First, we created the following Java policy to disable the security manager in the applet (saved in file “java.policy”):

Hi,

Last year (I know, I’m “a little” late with this article ) I tested a couple of applications that employed the Protocol Buffers data format (aka “Protobuf”) to serialize data transmitted using the HTTP protocol. Protobuf serializes data in binary format, not the ideal situation from a penetration tester’s perspective. So, as usual, I first searched for a Burp Suite extension able to deserialize/serialize Protobuf messages, in order to be able to inspect and tamper requests and responses in a more comfortable way.

In the BApp Store there is an extension named protobuf-decoder created for this purpose. I installed and tried it. Unfortunately, this extension has a lot of bugs and many functionalities are only partially implemented, which seems to indicate that something went wrong probably in the code added in the last releases. Furthermore, it is not clear who the maintainer is, because the PortSwigger’s fork of the extension is 37 commits ahead of the forked repository of a potential owner/maintainer (that is in turn a fork of another repository).

By the way, my target applications were quite complex and I really needed to overcome the Protobuf inspection/tampering problem. So I fixed many bugs in the extension and implemented some new features that I needed. The code is in my protobuf-decoder fork. I will not open a pull request because my code was developed quickly for a specific need, and some of the changes I made were tested only during a couple of engagements and may not work in every situation (and probably the extension has no maintainer at the moment anyway). My advice is to use my version if possible, because the one currently in the store has too many bugs to be reliable.