Alright, let’s set the stage. I’m trying to get LogRhythm’s network monitor to parse a proprietary industrial control system protocol—let’s call it “WidgetNet.” The vendor swears it’s “just like Modbus” and provided a 200-page spec PDF that reads like it was translated through three languages. Naturally, the out-of-the-box decoders are useless.
I’ve built a custom XML decoder, following the usual steps: define fields, offsets, data types. The agent ingests the traffic, but the decoded fields are either gibberish, empty, or it’s silently dropping the packets entirely. Packet capture confirms the traffic is hitting the right interface. I’ve tried both the “raw” and “binary” parsing methods. No joy.
So, the million-dollar question: has anyone actually succeeded in decoding a truly proprietary protocol with this thing, or is that just a marketing slide feature? The case studies always show it working perfectly on standard stuff. I’m particularly suspicious of how it handles variable-length fields within a TCP stream when there’s no clear header length marker. Did you have to write a pre-processor script to normalize it first? Or is this where we’re supposed to admit defeat and start budgeting for a “partner engagement”?
cg
cg
> The vendor swears it's "just like Modbus"
I've been burned by that exact line before. "Just like Modbus" usually means they copied the frame structure but changed the byte order, added a payload offset, or threw in a 4-byte magic number that isn't documented in the spec. I'd bet a lot of the gibberish you're seeing is an endianness mismatch or a fixed header the decoder isn't skipping.
The variable-length field problem is a killer with LogRhythm's XML decoder. I've had success by writing a small Python script that runs as a pre-processor - basically a lightweight proxy that sniffs the traffic, reshapes the packets into a fixed-length pseudo-protocol, and then feeds it to the agent. It's ugly, but it works. You can stand up a simple TCP relay with `scapy` or `dpkt` to strip the variable parts and inject a length prefix. Not ideal for production, but it proves the concept.
Also check the wire format with a hex dump. The spec PDF might say "little-endian 16-bit" but the actual bytes could be big-endian with a swapped nibble somewhere. I've seen vendors "copy" Modbus and then accidentally flip the register order. Have you tried dumping a few packets and manually matching the fields against the spec?