NoPE Proxy: Intercepting Non-HTTP Traffic Inside Burp Suite

Hook

Burp Suite dominates web application security testing with 65% market share, yet it's almost useless against the binary protocols that power most mobile apps, IoT devices, and thick clients. NoPE Proxy fixes that glaring blind spot.

Context

Security researchers face a fundamental problem: the tools don't match the targets. Burp Suite revolutionized web security testing by providing an intercepting proxy that lets you view and modify HTTP traffic in real-time. But modern applications increasingly communicate over custom binary protocols—Protocol Buffers for gRPC services, MessagePack for mobile apps, proprietary formats for IoT devices, and even WebSockets that carry non-HTTP payloads. When you try to proxy these protocols through Burp's standard HTTP listener, you get garbage. The traffic passes through unreadable, unmodifiable, and ultimately untestable.

Traditionally, security testers resort to Wireshark for passive analysis (no modification capability), write custom proxy scripts in Python or Go (time-consuming and outside the Burp workflow), or use specialized tools like mitmproxy (which means learning a completely different ecosystem and losing Burp's powerful features like Scanner, Intruder, and Repeater). NoPE Proxy—short for Non-HTTP Proxy Extension—bridges this gap by embedding TCP and UDP interception directly into Burp Suite. It gives you the same intercept-modify-forward workflow you know from HTTP testing, but for arbitrary binary protocols. The extension has gained traction in the security community precisely because it lets pentesters stay in their primary tool while expanding their testing scope to the protocols that HTTP-focused tools ignore.

Technical Insight

NoPE Proxy's architecture centers on three core components: configurable listener proxies, a SQLite persistence layer, and an embedded Jython interpreter for protocol manipulation. When you configure a new listener in NoPE, you're essentially creating a man-in-the-middle proxy that binds to a local port, accepts connections from your target application, and forwards traffic to the actual backend server. The extension captures every byte that flows in both directions, stores it in a SQLite database, and presents it in Burp's UI for inspection and modification.

The real power emerges when you need to manipulate binary protocols. Consider a mobile app that communicates using Protocol Buffers over TCP. Without NoPE, you'd see hex dumps in Burp that are technically accurate but functionally useless—you can't meaningfully modify a serialized protobuf by changing random bytes. NoPE solves this through Python scripting. Here's a practical example of a Python script that deserializes a protobuf message, modifies a field, and re-serializes it:

import sys
from google.protobuf import text_format
from user_pb2 import UserRequest  # Your compiled protobuf

def manipulate(data, direction):
    # direction: 0 = client->server, 1 = server->client
    if direction == 0:
        try:
            request = UserRequest()
            request.ParseFromString(data)
            
            # Modify the user ID to test authorization
            original_id = request.user_id
            request.user_id = 1  # Admin ID
            
            print("Modified user_id from %d to %d" % (original_id, request.user_id))
            return request.SerializeToString()
        except Exception as e:
            print("Error: %s" % str(e))
            return data
    return data

This script hooks into NoPE's request/response pipeline. Every message passes through your manipulate() function, which receives the raw bytes and a direction indicator. You can import protobuf definitions (or any Python 2.7-compatible library), deserialize the binary data, modify fields programmatically, and return the re-serialized bytes. NoPE handles the socket management, SSL/TLS termination, and UI integration—you just write the protocol logic.

The SSL/TLS interception deserves special attention because it showcases NoPE's integration with Burp's existing infrastructure. When you enable SSL for a listener, NoPE doesn't generate new certificates or require separate CA installation. It leverages Burp's CA certificate that you've already installed in your test environment. This means transparent SSL interception works immediately for TCP protocols—the same certificate that proxies HTTPS also proxies SSL-wrapped protobuf, MQTT over TLS, or any other encrypted TCP protocol. The extension uses Java's SSLContext to create server sockets with Burp's certificate chain, seamlessly terminating SSL from the client and re-establishing it to the backend server.

The SQLite persistence layer is architecturally significant because it addresses a pain point in security testing workflows: data loss. When you close Burp, standard Proxy History disappears unless you explicitly save it. NoPE automatically commits every intercepted message to a local SQLite database. This means you can close Burp, restart it days later, load NoPE, and still access the complete history of non-HTTP traffic you intercepted. The schema is straightforward—tables for listeners, connections, and messages—but the impact on workflow efficiency is substantial. You can run long-term testing, correlate traffic patterns across sessions, and maintain audit trails without manual exports.

The DNS server component is a clever usability feature. When testing thick clients or mobile apps, you often don't know which backend servers the application contacts until you run it. NoPE includes a simple DNS server that logs all DNS queries from your target application. Run the app, check NoPE's DNS log, and you immediately see which hostnames need proxying. You can then configure NoPE listeners for those specific hosts and ports, or use the DNS server to redirect traffic to your NoPE listeners by returning localhost addresses for specific domains. This discovery-then-intercept workflow is far more efficient than blind network sniffing.

Gotcha

The Jython dependency is NoPE's most significant limitation, and it's not just a minor inconvenience—it's a fundamental constraint that affects what you can accomplish. Jython provides Python 2.7 syntax support in Java, which means you're locked to a language version that reached end-of-life in 2020. Modern Python libraries like asyncio, type hints, f-strings, and the vast majority of protocol-handling libraries built for Python 3.6+ are completely unavailable. If you want to manipulate a protocol using a library that only exists for Python 3, you're out of luck. You'll need to either port the library yourself (rarely practical) or find a Python 2.7-compatible alternative (increasingly difficult). This limitation is particularly painful for protocols like gRPC, where the official tooling strongly favors Python 3.

Performance becomes a concern with high-volume binary protocols. Each intercepted packet triggers SQLite write operations, Jython interpretation overhead if you're using scripts, and UI updates in Burp's interface. If your application exchanges thousands of small messages per second—common with IoT protocols or gaming applications—you'll experience noticeable latency and potential message loss. NoPE was designed for typical security testing scenarios where you intercept, pause, modify, and forward individual requests. It's not built for high-throughput packet manipulation or real-time protocol fuzzing at scale. The architecture prioritizes inspection and manual modification over performance, which aligns with Burp's general philosophy but may surprise users coming from lower-level packet manipulation tools.

Configuration complexity is another practical hurdle. Unlike Burp's HTTP proxy, which often requires minimal setup because browsers automatically respect proxy settings, getting non-HTTP applications to route through NoPE requires understanding the application's network configuration. You might need to modify host files, use iptables rules for transparent proxying, configure the application's network settings directly, or use the DNS server feature. Each application behaves differently, and there's no universal approach. Mobile apps on iOS are particularly challenging because they often include certificate pinning that prevents SSL interception even with Burp's CA installed. While NoPE provides the proxy infrastructure, you still need to solve the same certificate pinning and anti-proxy detection challenges that exist in standard mobile app testing.

Verdict

Use NoPE Proxy if you're already working in Burp Suite and need to test applications that communicate over non-HTTP protocols—specifically mobile apps using Protocol Buffers, IoT devices with custom TCP protocols, thick clients that don't use REST APIs, or WebSocket implementations carrying binary payloads. It's the right choice when you want to leverage Burp's ecosystem (Repeater, Intruder, extensions) for non-HTTP traffic and need persistent traffic history across testing sessions. The learning curve is minimal if you're comfortable with Burp, and the Python scripting provides sufficient flexibility for most binary protocol manipulation tasks. Skip NoPE if you're testing pure HTTP/HTTPS applications (use standard Burp), require Python 3 libraries for protocol handling (use mitmproxy instead), need high-performance packet manipulation with thousands of messages per second (build custom tooling), or work primarily outside the Burp Suite ecosystem. Also skip it if you need automated protocol detection or dynamic proxy configuration—NoPE requires manual listener setup for each protocol and port combination, which becomes tedious for applications with dozens of backend endpoints.