A very typical security assessment and penetration test for ivision involves a device, multiple RF communications interfaces (cellular, WiFi, Bluetooth, ZigBee, some mutant 802.15.4 based stack, etc.) and one or more back-end services. Getting access to all of these interfaces takes a bit of work at times but the payoff makes it worth it, in most cases. Developers seem to assume that esoteric interfaces are more secure but at least in my experience the more bizarre the interface the more likely it is to be vulnerable to attack.

Getting proper access to these interfaces can be challenging at times because the tools that you might otherwise use aren’t directly compatible with whatever protocol is in use. A recent project introduced me to an annoying protocol I had not yet worked with before: WAP Binary XML (WBXML). This party-like-it’s-1999 era standard provides a binary size-reduced encoding of arbitrary XML documents. Your cell phone likely has an implementation of WBXML supporting ActiveSync and perhaps over-the-air device management. When US carriers brick all of those hapless Galaxy Note 7 phones WBXML will likely deliver the fatal commands.

Sticking the Burp proxy into a WBXML conversation is possible but the binary XML representation limits the usefulness of tool. To help the matter I’ve created a mitmproxy script that will handle WBXML and XML translation as needed. I created the script for mitmproxy because Burp’s Jython scripting can not be used with Python modules that require C libraries.

The proxy is deployed as two instances. One goes in front of Burp to translate WBXML to XML. The other goes after Burp to translate XML to WBXML before transmission to the server.

All of this proxying does slow transaction speed a bit, of course. Overall the result was favorable and implementation was quick. mitmproxy’s auto-reload feature on script updates is a huge time saver that I wish Burp would copy.

See: webxml.py