Exorcising the Ghosts of Dependencies Past: A Deep Dive into Binary Resurrection

By Stephen Lee Bancroft

In the trenches of enterprise infrastructure, you often find yourself inheriting systems that operate like black boxes—rigid, monolithic, and silently harboring a cocktail of severe vulnerabilities. Recently, I found myself staring down the barrel of exactly this kind of beast: the BindPlane Agent (bpagent.service), specifically its embedded Java metrics collector.

What started as a routine vulnerability scan quickly devolved into a multi-layered architectural puzzle involving rigid Go binaries, obsolete Java runtimes, and the dark arts of manifest manipulation. Here is the war story of how we took a system riddled with Critical CVEs and modernized its entire runtime without access to a single line of proprietary source code.

The Initial Reconnaissance

A standard Grype scan of the /opt/bpagent directory lit up the dashboard like a Christmas tree. We were looking at 58 vulnerability matches in the Java layer alone. We had the notorious commons-text “Text4Shell” (CVE-2022-42889), high-severity deserialization flaws in jackson and gson, and a whole suite of network vulnerabilities tied to an outdated undertow-core web server.

The naive approach? Swap out the .jar files. I deleted commons-text-1.6.jar, dropped in commons-text-1.11.0.jar, and restarted the service.

Crash.

java.lang.NoClassDefFoundError.

The vendor hadn’t just bundled the libraries; they had hardcoded the exact filenames—version numbers and all—directly into the Class-Path attribute of the bpagent-metrics-collector.jar’s MANIFEST.MF.

Phase 1: The Masquerade and the Manifest

Our first workaround was a pragmatic masquerade: we downloaded the modern, secure binaries but renamed them to match the legacy filenames. It worked. The application booted, completely unaware it was running modernized code. But as an engineer, relying on filename spoofing leaves a bad taste in your mouth. It’s brittle.

We needed a permanent fix. We extracted the MANIFEST.MF from the fat jar, wrote a custom parser to unwrap and rewrite the rigid 72-byte-line format, and injected the true, modernized filenames. Using the jar umf command, we surgically repacked the binary. The masquerade was over; the system was now cleanly loading the patched libraries.

But we hit a wall.

Phase 2: The Java 10 Dead End

Some libraries refused to be upgraded. The undertow-core network engine was stuck on the 2.0.x branch. Why? Because upgrading it to the fully patched 2.3.x branch required a newer version of the xnio-api. And the newer xnio-api was compiled with class file version 55.

It required Java 11 or higher.

The BindPlane agent was shipping with a bundled, ancient OpenJDK 10.0.2 environment. We couldn’t patch the network layer without upgrading the entire Java runtime.

Phase 3: The Proxy Wrapper

“Just upgrade the JRE,” you say. If only it were that simple.

The Java process isn’t spawned by a friendly shell script; it’s spawned by a compiled Go binary (bpagent-manager). When I dropped OpenJDK 17 into the directory, the Go manager faithfully tried to execute it, passing along its hardcoded JVM arguments.

Crash.

Unrecognized VM option 'AggressiveOpts'.

The Go binary was hardcoded to pass -XX:+AggressiveOpts and -XX:+UseBiasedLocking—flags that Java 17 had completely removed. Without source code to recompile the Go manager, we were locked out.

To bypass this, we employed a classic proxy maneuver. We renamed the real Java 17 executable to java.orig and replaced it with a Bash wrapper script. When the Go manager called java, our script intercepted the execution, stripped out the obsolete garbage flags, injected the --add-opens java.base/sun.nio.ch=ALL-UNNAMED reflection flags required by the legacy network libraries, and seamlessly passed the baton to the real Java 17 binary.

The Go manager was none the wiser. The agent booted perfectly on Java 17 LTS.

Phase 4: Unleashing the Upgrades

With Java 17 unleashed, the dominoes fell.

1. The Network Stack: We immediately upgraded undertow-core to 2.3.21.Final and xnio-api to 3.8.14.Final. Because the modern XNIO engine required new transitive dependencies, we downloaded jboss-threads and wildfly-common and explicitly injected them into our custom MANIFEST.MF.
2. The Logging Stack: The agent was vulnerable to log4j-core flaws but was trapped because it used a deprecated slf4j18-impl bridge that Apache had deleted. With our manifest-rewriting pipeline perfected, we ripped out the entire logging stack, dropped in the modern SLF4J 2.x API, wired it to the new log4j-slf4j2-impl bridge, and upgraded log4j-core to 2.23.1.

The Final Boss: The Ghost CVE

After this exhaustive modernization, running a final Grype scan yielded a massive reduction in vulnerabilities. We had secured the deserialization, the web server, the core utilities, and the logging framework.

But one critical alert remained: commons-text 1.6.

How could this be? We specifically patched commons-text to 1.11.0 in the manifest. The answer lies in the dark side of Java packaging: “shaded” dependencies.

The vendor utilized a library called scoop-1.0.0-rc8.jar. This wasn’t a normal library; it was a “fat jar.” The vendor had compiled the vulnerable commons-text 1.6 classes directly into the bytecode of the Scoop library. No amount of manifest manipulation or classpath overriding can dynamically excise vulnerable classes that are baked directly into a third-party binary. It is a “Ghost CVE”—a phantom of poor packaging practices that will haunt the system until the vendor issues a cleanly compiled rebuild.

Conclusion

We didn’t just apply a patch; we performed a total binary resuscitation. We broke the constraints of a rigid Go manager, vaulted over a 7-year gap in Java runtimes, and re-engineered the dependency tree of a closed-source application.

If you’re interested in examining the final reconstructed binary, you can download the modernized archive here: gcve-observability-agent-v0.1.3.tar.gz

It is a testament to the fact that with enough tenacity, a deep understanding of the JVM, and a willingness to intercept the execution chain, you can secure almost anything.