Inside the MQL4 Vault: 5 Surprising Discoveries from the .ex4 v504 Binary Format

MetaTrader 4 remains the fortress where the world’s proprietary trading alpha is locked away. For years, the compiled .exx files produced by the MQL4 compiler have been treated as impenetrable black boxes, shielding the logic of millions of Expert Advisors from prying eyes. But to a forensic analyst, no box is ever truly sealed.

Version 504 of the .exx format represents a peak in the technical evolution of this container. It isn’t just a file; it is a complex, layered ecosystem designed to mislead, deter, and occasionally trap the unwary. During a recent binary autopsy of this format, we uncovered five specific structural “clues” that reveal how MetaQuotes engineers balanced execution speed against the need for intellectual property protection.

1. The Infinite Nested Queue

While scanning the binary, we encountered a structure that defied linear logic. Rather than a flat sequence of data, the v504 format utilizes a “Russian Doll” container architecture. Any block with a type ID of 0x40 or higher—most notably the Nested Container (0xAC9B6120)—acts as a recursive wrapper.

When the loader encounters these high-type blocks, it doesn’t just read them; it enqueues them. This creates a recursive extraction loop where an outer container reveals nested sub-blocks, which in turn may contain further compressed or encrypted layers.

The decompiler/loader processes sub-blocks as a queue: after decrypting the outer container, blocks may re-enqueue other blocks. The queue runs for up to 100,000 iterations before stopping.

This 100,000-iteration safety valve is a testament to the potential complexity of the format. By allowing almost endless nesting, the compiler can bury the actual trading logic (the bytecode) under dozens of cryptographic and architectural shells, ensuring that only a sophisticated, state-tracking decompiler can ever hope to reach the core.

2. Encryption at the Gates: The 64-Byte Rule

Security in the .exx format is often a game of “good enough.” This is most evident in the “Pass 1” XOR encryption mechanism. One might assume that a financial binary would encrypt its entire payload, but the forensic evidence shows a remarkably “lazy” approach designed for maximum performance.

The system employs a symmetric XOR operation using a 4-byte rotating key. However, the encryption is only applied to the first 64 bytes of a block’s body. Everything beyond that 64-byte threshold is stored as plain text.

This is a classic deterrent. By locking only the “gate” (the header and initial instructions), the format breaks standard file-type scanners and simple hex editors. It prevents a casual observer from identifying the file’s contents at a glance, while allowing the MetaTrader VM to process the bulk of the bytecode without the heavy computational overhead of full-stream decryption. It is a strategic trade-off: security at the perimeter, performance in the interior.

3. The Secret Math of Builtin Functions

One of the most elusive “signatures” of the MQL4 compiler was found while analyzing how the binary calls builtin functions like Alert, OrderSend, or MarketInfo. These aren’t stored by name; they are referenced by a raw bytecode index, N.

Empirical discovery revealed that these indices don’t map directly to any visible table. Instead, a specific “Critical Index Formula” must be applied. To find the true identity of a function, the analyst must subtract exactly two from the index (N – 2).

Verification Table (Raw Index to Function):

• Raw Index 3 → (3 – 2) = Table Index 1: Alert
• Raw Index 13 → (13 – 2) = Table Index 11: MarketInfo
• Raw Index 329 → (329 – 2) = Table Index 327: StringConcatenate

This quirk is likely a relic of the compiler’s internal table alignment, perhaps skipping over a version ID or a header entry. We located the ground truth for these names at virtual address 0x714434 within the decompiler binary itself. This is a prime example of why reverse engineering is more than just reading code; it is about finding the specific “mathematical keys” that align a program’s logic with its data.

4. Deciphering the Variable Alphabet

When a program is stripped of its debug symbols, the original variable names vanish. However, the v504 format leaves behind a “Global Frame Layout” that allows us to reconstruct the program’s DNA. The decompiler generates names using a rigid alphabet based on storage class and data type:

• Prefixes: L (Local), G (Global), A (Argument).
• Type Characters: i (int/bool), d (double), s (string), and t (datetime).

A variable named Lt_16, for instance, is instantly identifiable as a Local timestamp at frame offset 16. But there is a crucial threshold: the 76-byte rule. The first user-defined “extern” variable always begins at offset 76. Any variable with a number lower than 76 is a “Predefined Global” (such as Ask, Bid, or Bars) and is exempt from the standard naming rules. By mapping these offsets, we can reconstruct the entire memory map of an EA, even if the developer intended for it to remain anonymous.

5. The “Dead Beef” Validation Gate

The final layer of the forensic puzzle is the anti-tamper mechanism found in the processing pipeline. Before the decompiler will fully emit the reconstructed source code, it must pass a “Tamper Pass” validation.

This check is a sophisticated logic gate involving two keys (0xA5 and 0x5A) and a specific XOR constant: 0xC001C0DE. If the internal checksum of the IR (Internal Representation) tree does not match the expected value of 0x1EAC7E31, the system refuses to set a specific sentinel flag: 0xDEADBEEF.

The irony is profound. This “Dead Beef” marker is an internal seal of authenticity. If this gate is not cleared—suggesting the binary has been modified or corrupted—the decompiler will trigger a failure state, labeling functions with the dreaded comment: //???/*broken function*/. It is the binary’s last-gasp effort to protect the integrity of its logic from being scrutinized by a modified or unauthorized tool.

The Future of MQL4 Forensics

The technical sophistication of version 504 highlights a relentless arms race. Even when a developer strips their function table to hide their logic, the forensic specialist can still locate entry points by scanning for the 0xFD (FUNC_ENTRY) opcode marker within the bytecode.

As we have seen, the boundary between “compiled” and “recoverable” is remarkably porous. From the recursive 100,000-iteration “Russian Dolls” to the specific mathematical offsets of the builtin table, every layer of protection eventually leaves a signature. In the high-stakes world of algorithmic trading, where proprietary logic is the ultimate asset, we must conclude: is any code truly beyond recovery once it is “sealed” for the market?