Decrypting 19th Century Covert Channels: Lessons in Signal Book Cryptanalysis

TLDR: This research into 19th-century newspaper advertisements reveals how historical actors used public, obfuscated channels for private, global communication. By identifying the underlying Marryat signal code and applying manual cryptanalysis, researchers successfully recovered plaintext from these "encrypted" ads. For modern security professionals, this serves as a masterclass in identifying covert channels and the necessity of understanding the underlying encoding schemes to break them.

Historical cryptography often feels like a relic, but the techniques used to hide information in plain sight remain startlingly relevant to modern red teaming. When we look at the 19th-century "Agony Columns" in newspapers like The Times, we aren't just looking at history; we are looking at the precursor to modern steganography and covert channel exploitation. The recent research into these ads, specifically those linked to the Franklin Expedition, demonstrates that even when an encryption system is "broken," the real work of intelligence gathering—deciphering the intent and context—is where the actual value lies.

The Mechanics of a 19th-Century Covert Channel

The ads in question were not protected by modern AES-256 or RSA. Instead, they relied on a combination of substitution ciphers and, more importantly, proprietary codebooks. The researchers identified that the messages were not just random strings of characters; they were structured data points mapped to specific entries in a signal book.

In a modern pentest, we often encounter similar obfuscation. Developers frequently implement "security through obscurity" by using custom encoding schemes or non-standard serialization formats to hide API traffic or internal communication. The lesson here is simple: if you can identify the "codebook"—the schema, the library, or the documentation—the encryption becomes trivial. In this case, the researchers realized that the ads were using the Marryat signal code, a system originally designed for maritime flag signaling. By mapping the four-digit groups in the ads to the corresponding entries in the signal book, the plaintext emerged.

Technical Execution: From Ciphertext to Plaintext

The decryption process demonstrated by the researchers highlights the importance of "cribbing"—guessing known plaintext to break a cipher. When the initial substitution tables failed, the team looked for common patterns. They identified that certain four-letter groups appeared with high frequency, which they hypothesized were common English words like "in," "at," or "the."

The team released a decryption tool that automates this mapping process. It uses client-side JavaScript to apply the codebook logic directly in the browser. For a researcher, this is the ideal workflow:

// Simplified logic for mapping ciphertext groups to plaintext
function decryptGroup(group, codebook) {
    if (codebook.hasOwnProperty(group)) {
        return codebook[group];
    }
    return "[UNKNOWN]";
}

The tool handles the heavy lifting of OCR-based codebook ingestion and manual cleanup. This is a critical step that many automated tools miss. When you are dealing with legacy data or custom obfuscation, the "noise" in the data—typos, OCR errors, or non-standard formatting—is often where the most interesting information is hidden.

Real-World Applicability for Modern Pentesters

Why should a modern bug bounty hunter care about 19th-century maritime codes? Because the concept of a "covert channel" is alive and well in modern web applications. We see this in SSRF vulnerabilities where an attacker uses an internal service as a proxy to communicate with an external C2 server. We see it in data exfiltration where sensitive information is encoded into DNS queries or ICMP payloads to bypass traditional egress filtering.

During a red team engagement, you might find an application that uses a proprietary, obfuscated format for its internal RPC calls. Instead of trying to brute-force the encryption, your first step should be to find the "codebook." Look for client-side JavaScript files, leaked internal documentation, or even comments in the source code that reveal the serialization logic. Once you have the schema, you have the keys to the kingdom.

Defensive Considerations

Defending against these types of covert channels is notoriously difficult because they often look like legitimate traffic. If an attacker is using a standard protocol—like HTTP or DNS—to tunnel their data, traditional signature-based IDS/IPS will likely fail.

The most effective defense is anomaly detection based on behavioral baselines. If your internal services are suddenly communicating with an external endpoint using a non-standard, high-entropy payload, that is a red flag, regardless of whether the traffic is encrypted. Implement strict egress filtering and monitor for unusual traffic patterns that deviate from the expected application behavior.

The work done on these 19th-century ads is a reminder that the fundamentals of cryptanalysis haven't changed. Whether you are dealing with a 150-year-old newspaper ad or a modern obfuscated API, the process remains the same: identify the channel, find the codebook, and apply the logic. The next time you hit a wall with an encrypted payload, stop looking for a brute-force attack and start looking for the documentation that explains how the data was structured in the first place. You might find that the "encryption" is just a thin veil over a system that is waiting to be understood.