Reverse Engineering a Remote Code Execution Vulnerability in Modern Warfare 2 (PC)

Introduction:

Reverse engineering is the process of analyzing a compiled program (like a game) to understand its inner workings without having the original source code. In the context of video games, reverse engineers often use specialized tools (such as IDA Pro, Ghidra, or x64dbg) to disassemble or decompile game binaries, revealing functions and logic hidden inside. This practice is common in the modding and security community, whether to create mods, cheats, or to discover vulnerabilities. One especially dangerous type of vulnerability is a Remote Code Execution (RCE). An RCE allows an attacker to execute arbitrary code on another player's machine simply by exploiting the game's network communication. In a multiplayer game, this means a malicious player could potentially run any program or command on your PC just by being in the same lobby, a worst case scenario for security. As the Plutonium mod project notes, such RCE exploits “can be used to compromise your computer, steal sensitive information, or just ruin your gaming experience”.

In recent years, Call of Duty: Modern Warfare 2 (2009) for PC has gained notoriety for containing a known RCE vulnerability that went unpatched for a long time. This blog post will explore that vulnerability from a reverse engineering perspective. We'll cover how the vulnerability works, how it was discovered and analyzed, and how one can patch or mitigate it. We will also discuss the ethical implications of such vulnerabilities and the importance of responsible disclosure.

The MW2 RCE Vulnerability: Overview and Discovery

Call of Duty: Modern Warfare 2 (MW2) still has an active player base even many years after its 2009 release. Unfortunately, for a long time it also had a serious RCE flaw lurking in its multiplayer code. The issue was ultimately traced to the game's handling of compressed network data specifically a function related to Huffman compression (a method used to compress/decompress messages in the Quake engine lineage that Call of Duty is built upon).

Back in late 2017, security researcher Maurice Heumann (known online as momo5502) detailed this vulnerability. He explained that “users playing a Call of Duty match could cause a buffer overflow on the host’s system inside a stack allocated buffer within the game’s network handling. In consequence, this allows full remote code execution!”. In simpler terms, by sending a specially crafted network packet to an MW2 player (who is hosting a match), an attacker could overflow a buffer in the game and inject their own code to be executed on the host’s PC. This was not just a theoretical issue it could be (and reportedly was) abused to do things like inject malware into players’ machines or take over control (people have reported hackers opening web pages or applications on victims' computers). The community widely warned that “someone who uses RCE exploits on MW2 can infect anybody in the lobby with malware... and steal passwords, log keystrokes, access your files, etc.” RCE Exploits are back... Call of Duty: Modern Warfare 2 (2009). Clearly, this is a very severe security problem for any online game.

How was this vulnerability discovered or disclosed? According to Heumann, he was not the first to discover it; the issue was known in certain circles of the modding/hacking community before he got involved. However, he took the initiative to analyze and publicly document it as a proof of concept. In December 2017, he published a blog post explaining the exploit in broad terms and released a proof of concept code. Eventually, this vulnerability was assigned an official identifier CVE-2018-10718, and Activision (Infinity Ward) released a patch in late April 2018 to fix it. The CVE description summarizes it as a “stack based buffer overflow in ... Modern Warfare 2 before 2018-04-26 [that] allows remote attackers to execute arbitrary code via crafted packets.”. This indicates that as of April 26, 2018, a title update was issued to address the flaw (at least for MW2 on Steam).

Despite the patch, not all players updated their games or were aware of the fix, and similar vulnerabilities persisted in other older Call of Duty titles for years. Fast forward to the 2020s, and many players of the old CoD games were still at risk, leading the community to develop custom fixes and modified clients. But before we discuss those fixes, let's reverse engineer what was actually happening under the hood in MW2's code to cause this RCE.

Breaking Down the Vulnerability: Huffman Compression Overflow

The offending bug in MW2 occurs during the processing of network packets, specifically in a function known as SV_ExecuteClientMessage This function is part of the server side logic (which in peer to peer games like MW2 means the host player's client acts as the "server" for that match). SV_ExecuteClientMessage is responsible for reading and handling messages sent from a connected client. These messages can contain various commands or data some of which may be compressed to save bandwidth. MW2 (like its predecessors on the id Tech/Quake engine lineage) uses Huffman coding to compress certain network messages.

inside SV_ExecuteClientMessage, the game allocates a fixed size buffer on the stack to hold decompressed data. However, the vulnerability lies in the fact that the game did not properly validate the size of the incoming compressed data before decompressing it into that fixed buffer. According to the vulnerability documentation, “the length of the compressed data is not checked to be smaller than the allocated buffer on the stack before the call to MSG_ReadBitsCompress.” In other words, the game would trust whatever length was indicated by the packet and attempt to decompress that many bytes into a buffer that wasn’t big enough. The result is a classic buffer overflow data spills past the buffer’s boundary and overwrites adjacent memory on the stack, including the function’s return address. Once an attacker can overwrite a return address or other control data on the stack, they can redirect execution to their own code that they included in the overflow payload. This is how remote code execution is achieved.

Here’s a simplified version of the vulnerable code in SV_ExecuteClientMessage (pseudocode for conceptual understanding):

void SV_ExecuteClientMessage(client_t *cl, msg_t *msg) {
    char decompressedData[1024];  // fixed size stack buffer
    int compLen = MSG_ReadShort(msg);  // read the length of compressed payload (attacker controlled)
    // ... (some code omitted) ...
    // Vulnerable call: decompress 'compLen' bytes from the message into the fixed buffer
    MSG_ReadBitsCompress(msg->data + msg->readcount, compLen, decompressedData, sizeof(decompressedData));
    // ... continue processing using decompressedData ...
}

In the above sketch, MSG_ReadBitsCompress is the routine that performs Huffman decompression. The bug is that there's no check that compLen is at most sizeof(decompressedData) (1024 bytes in this example). If compLen is larger (or perhaps if the compressed data expands beyond that size during decompression), the function will overflow decompressedData. An attacker can craft a packet with an absurdly large compLen value (and corresponding data) such that when the game tries to decompress it, it overwrites memory beyond decompressedData’s boundary. The attacker would arrange the overflow data so that the saved instruction pointer (return address) on the stack gets overwritten with an address that points to their code (malicious code) injected elsewhere in the payload. When SV_ExecuteClientMessage returns, it will jump to the attacker's code and execute it giving them control of the game process on the victim's PC.

Disassembly Perspective: If we were to open the MW2 game binary (for example, iw4mp.exe for multiplayer) in IDA or Ghidra, we could locate SV_ExecuteClientMessage and see this logic in assembly. It might look roughly like this:

; (pseudocode-ish assembly for the vulnerable snippet)
push    0x400             ; push the size (1024) of the destination buffer
lea     eax, [esp+0x??]   ; load address of decompressedData buffer on stack into EAX
push    eax               ; push pointer to decompressedData buffer
mov     ecx, [msg]        ; ECX points to the msg structure
add     ecx, readcount_offset  ; ECX = pointer to current read position in msg data
push    [ecx]             ; push pointer to compressed data (msg->data + msg->readcount)
push    compLen           ; push the attacker-controlled length
call    MSG_ReadBitsCompress

In a patched/fixed version of the game, we would expect to see an added check before the call, something like:

cmp     compLen, 0x400    ; compare compressed length with buffer size 0x400 (1024)
jge     handle_overflow   ; if compLen >= 1024, jump to an overflow handling routine

The handling might disconnect the client or safely skip processing to avoid overflow. In the vulnerable version (before April 2018), this check was missing. The lack of that cmp instruction is essentially the bug.

Reverse Engineering the RCE: Tools and Methodology

So how did researchers figure this out? This is where reverse engineering skills come into play. A combination of static analysis (inspecting the game’s code) and dynamic analysis (observing its behavior at runtime) was used.

1. Setting up the environment: To analyze MW2, a researcher would use a PC with the game installed (preferably an older unpatched version of the game from before the official fix, to replicate the vulnerability). Tools used include:

• IDA Pro or Ghidra: to disassemble the iw4mp.exe (the MW2 multiplayer executable) and look for functions related to network message handling. Knowing the Quake engine roots, one might search for familiar strings or function patterns. In fact, community maintained lists of functions (e.g., via leaked symbol names or the modding scene) helped identify SV_ExecuteClientMessage and MSG_ReadBitsCompress in the binary.
• Debugger (x64dbg or similar): to set breakpoints and watch how the game processes incoming data. A researcher could run the game, attach a debugger, and then simulate a malicious packet to see where it crashes or how the overflow occurs. However, caution: running the game in a debugger or with modified behavior could trigger anti cheat (MW2 uses VAC) reponses.
• Network packet capture/injection tools: you can use tools like WinDivert (a packet capture/filter driver for Windows). Instead of modifying the game code to send malicious packets (which would be detected by anti cheat), you can let the game run normally and intercept the network traffic at the OS level. By analyzing real game packets and then injecting your own crafted packets with WinDivert, you can effectively make the game act as if another player was sending the malicious data. This can allow you to test the exploit without tampering with the game binary in memory.
• Wireshark or similar: to capture network traffic for analysis of the communication protocol. Understanding the packet structure (where in the packet is the length specified? how is data encoded?) is crucial to crafting a working exploit. In the case of MW2, the protocol is based on UDP and a custom message format inherited from the Quake engine. It wasn’t documented, so reverse engineers had to infer it from the code and experimentation.

2. Locating the vulnerability in code: Using IDA/Ghidra, one could search for references to the Huffman functions. MW2’s engine has a function named MSG_ReadBitsCompress In fact, community driven reverse engineering (and open source code from similar engines) helped here. For example, the Quake 3 engine (and by extension, the Call of Duty engines derived from it) had known implementations of Huffman compression. By searching for those patterns or constants, one could locate the function in MW2’s binary. Once found, you would look at how it's used. Seeing MSG_ReadBitsCompress being called inside SV_ExecuteClientMessage with a parameter that looks like a length from the message is a red flag if no bounds check precedes it. The GitHub repository of momo5502’s proof of concept confirms exactly this: the game calls MSG_ReadBitsCompress on a packet without ensuring the data will fit in the buffer.

3. Crafting an exploit: With the knowledge of how the packet is structured (say, a command that includes a length and compressed payload), the researcher would craft a malicious packet. This typically involves:

• Choosing a return address to hijack (possibly an address that jumps to the start of the payload or a jmp esp gadget, depending on what’s available in the binary classic overflow exploitation).
• Writing shellcode (e.g., something innocuous like opening a Windows calculator, or more malicious code) to include in the packet.
• Calculating the compressed data or even bypassing compression (one trick might be to mark the data as "already compressed" or use the function in a way that just memcpys data if possible).
• Ensuring the packet does not get dropped by any sanity checks (maybe a checksum or sequence number needs to be correct).

Heumann’s approach, interestingly, was to avoid writing his own network stack to send the packet from scratch. Instead, he manipulated the game itself to send the packet by diverting function calls, essentially using MW2’s own networking code to generate the malicious packet, but intercepting it locally. His blog describes hooking certain game routines or crafting a scenario in memory so that the game’s next outbound packet was actually the exploit. This clever method meant he didn’t have to fully implement the protocol himself he let the game do it, after tricking it into loading his custom data.

For our purposes, however, one could also write a small C program with a socket to send a UDP packet that mimics what MW2 expects, containing the malicious payload. The proof of concept code on Exploit DB (authored by Heumann, EDB-ID 44987) basically did just that, automating the exploit injection.

Technical Details: Disassembly Snippets and Pseudocode

To give a concrete sense of the reverse engineered vulnerability, let's consider a snippet of decompiled pseudocode for SV_ExecuteClientMessage (simplified for clarity):

// Inside SV_ExecuteClientMessage in the vulnerable version
int msgType = MSG_ReadByte(msg);
if (msgType == 0x5A) {  // hypothetical message ID that indicates a compressed packet
    int compSize = MSG_ReadShort(msg);    // attacker-controlled size
    char dest[1024];                      // local buffer for decompression
    // ... (maybe some other local variables and setup) ...
    MSG_ReadBitsCompress(msg->data + msg->readcount, compSize, dest, 1024);
    // process 'dest' data ...
}

And here is an IDA assembly excerpt corresponding to that logic:

.text:00612345  movzx   eax, byte ptr [esi]       ; read a byte (message type) into EAX
.text:00612348  cmp     eax, 5Ah                  ; compare with 0x5A (just an example ID)
.text:0061234B  jne     NOT_COMPRESSED            ; if not that type, jump elsewhere
.text:00612351  movzx   ecx, word ptr [esi+1]     ; ECX = compSize (next 2 bytes from message)
.text:00612355  add     esi, 3                    ; advance message pointer by 3 (1+2 bytes read)
.text:00612358  lea     edx, [ebp-400h]           ; EDX = address of dest buffer (0x400 = 1024 bytes)
.text:0061235E  push    400h                      ; push 0x400 (dest buffer size = 1024)
.text:00612363  push    edx                       ; push dest buffer pointer
.text:00612364  push    ecx                       ; push compSize (attacker controlled)
.text:00612365  push    esi                       ; push pointer to compressed data in message
.text:00612366  call    MSG_ReadBitsCompress      ; decompress data into dest buffer
; No checks before this call in the old version! Overflow possible if compSize >= 0x400.

(Note: The above addresses and values are illustrative, not actual MW2 disassembly. But they convey the structure.)

From this reverse engineered view, the flaw is glaring: after reading compSize from the packet, the code goes straight into calling the decompress function with that size, without verifying it against the buffer length (0x400). The correct fix here would be to insert a check like:

if (compSize > 1024) { drop packet / disconnect client }

before the call. Indeed, after the vulnerability became known, the community confirmed that was the essential change. The GitHub README for the exploit states succinctly: “Overflowing the buffer using a modified client message enables arbitrary code execution.”.

Exploit in Action: What Could Attackers Do?

When successfully exploited, this vulnerability gives the attacker the same privileges as the game process on the victim’s machine. This means the attacker could perform any action that the user running the game could. Examples include:

• Inject and execute malicious code (malware, ransomware, etc.).
• Steal sensitive information from the victim’s PC.
• Manipulate the game session (e.g., executing unauthorized commands).
• In one anecdotal report, victims described the attacker opening inappropriate content (like random websites or media) on their computer via the exploit as a form of harassment.

The seriousness of this cannot be overstated. It’s a game turned into a malware delivery vector. That's why the discovery of this bug prompted an urgent need for patching and why players were warned to avoid public matches in vulnerable games for a time.

Patching the Vulnerability: Safely NOPing and Binary Patching

If you have an old copy of MW2 and want to play it safely, the best solution is to update to the latest official version (Steam should provide the patched executable after 2018). However, let's assume you only have the vulnerable version (for example, if playing on a LAN or an unofficial server) how could you manually patch it? We’ll discuss two approaches: binary patching the game and using community fixes (DLL patches).

Manual Binary Patch

With reverse engineering, once we've identified the problematic instructions, we can patch the binary itself. One straightforward patch would be to disable the vulnerable call entirely or insert a check. Without source code, inserting new logic is tricky, but we can NOP out instructions or alter constants via a hex editor.

For instance, to prevent the overflow, one could simply prevent any attempt to decompress a large packet. This could be done by patching the game so that MSG_ReadBitsCompress is never called with untrusted data:

• One crude way: find the call to MSG_ReadBitsCompress in SV_ExecuteClientMessage and replace it with NOP (0x90 bytes) so it doesn’t execute. The code would then skip decompression. This might result in the game ignoring that packet entirely (since the data is not processed further). The downside is if that message was legitimate (e.g. a voice chat or large game state update), it might break something. However, since attackers exploit an abnormally large size, skipping only those might be okay.
• A more elegant way: patch in a size check. If there is unused space or a short function that’s not used, a skilled reverser can redirect code flow (using a JMP) to a code cave where they insert something like:

cmp   ecx, 400h      ; compare compSize (in ECX) with 1024
jge   skip_decompress
call  MSG_ReadBitsCompress
skip_decompress:

• This is more involved because it requires writing new bytes and possibly moving things around. But it’s doable in many cases by an experienced binary patcher.

As an example, the official patch likely implemented a check similar to the above. If we had two versions of the binary (vulnerable vs patched) and did a diff, we’d probably see a few bytes difference around that function (the inserted compare and conditional jump).

For those not comfortable with assembly level patching, a simpler method was popular: use an anti-RCE DLL that patches the game in memory. The Reddit community shared DLL fixes that could be injected at runtime to automatically patch these vulnerabilities without permanently modifying the game file. Essentially, these DLLs (often open source) hook the relevant function and add the missing validation or disable the dangerous code path. To use them, one would:

• 1. Download the anti-RCE DLL fix.
• 2. Use a DLL injector (like K2 injector or something similar) to inject it into iw4mp.exe after the game launches.
• 3. The DLL would then hook the vulnerable function and apply the patch in memory, preventing the overflow from occurring.
• 4. Play the game as normal, but now with the vulnerability mitigated.

One guide from mid 2023 confirms this process, advising players to “use a DLL injector to use the anti-RCE DLL” and providing links to the fix. Players reported that this approach stopped the in game attacks, though it only protects against known exploits and does not make the game 100% secure from all possible exploits.

Third-Party Client Fixes

Beyond DIY fixes, there are community maintained versions of the game that have security improvements baked in:

• IW4x is a popular community client for MW2 which allows player run dedicated servers and mods. The IW4x team took security seriously and patched many vulnerabilities in the engine. They announced that an RCE was fixed in the r4773 release of their client. Essentially, if you play MW2 via IW4x, you inherit their fixes which include closing this Huffman overflow hole (and others like the "Steam Auth" exploit, etc.). Always ensure you’re on the latest version of such clients; IW4x even details how to check your version and update.
• Plutonium is another project that provides a modern client for older CoD titles (including MW3, Black Ops 1 & 2, World at War). The Plutonium developers likewise state that they have “taken steps to patch these vulnerabilities that still exist on the Steam versions”. On Plutonium, the game exes are modified and the vulnerable code paths have been secured. So playing on Plutonium’s servers, you’re safe from those specific exploits (though obviously, stay up to date as new issues can be found).

Both these projects effectively apply the needed patches and even additional hardening. For example, if MW2 originally lacked certain sanity checks, these clients add them. They also often disable useless legacy functionality that could be risky. For users, the takeaway is: if you want to play older Call of Duty games, consider using these community clients for a safer experience.

Responsible Disclosure and Ethical Considerations

It’s worth discussing the ethics around these kinds of vulnerabilities. When Maurice Heumann learned of the MW2 exploit, he chose to disclose it publicly in a controlled manner, providing a proof of concept and notifying the proper channels. This led to a CVE assignment and an official patch. This is an example of (relatively) responsible disclosure: even though the blog post came before the official patch, it did not include fully weaponized code targeting unsuspecting players; it was aimed at the security community. Ideally, one would first report the issue privately to the game developer (Activision in this case) and give them time to patch. It’s not clear if Activision was notified earlier through other channels (possibly, since the patch was out a few months later), but either way, once a patch exists, publicly sharing the details helps raise awareness so players can protect themselves.

Ethically, if you are a researcher and find a similar flaw in a game, the best practice is:

• Notify the vendor (game developer/publisher) or platform (like Steam) through their security channels. Many companies have dedicated security teams and bug bounty programs or at least contact emails for vulnerability reports.
• Do not use the exploit on real players or servers except in controlled testing with consent. Causing harm to random players is illegal and immoral.
• Wait to disclose technical details until a fix is available or a reasonable time has passed with no action. This is to avoid zero day exploitation in the wild.
• When disclosing, include an educational write up (like this post aims to be) and necessary disclaimers.

In the case of MW2, once the vulnerability was widely known, a troubling scenario unfolded: the exploit was used by malicious actors in public games to literally infect other players with malware. In early 2023, there were reports of self spreading worms in other old CoD games abusing similar flaws ('Call of Duty' Players Are Being Hit With Self Spreading Malware) (Call of Duty players taken out by dangerous self spreading malware). This was a wake up call to the developer (Activision), who eventually pushed updates to some of those titles. For example, Black Ops 3 on PC received a patch in 2023 after 8 years of vulnerability, following community outcry. Modern Warfare 2 (2009) also received a summer 2023 update that reportedly fixed another RCE the "JoinParty" exploit, CVE-2019-20893 (RCE Exploits are still alive PLAY AT YOUR OWN RISK!) (CVE-2019-20893 Detail - NVD). It's a bit confusing, but it appears multiple distinct RCEs have been identified over time:

• CVE-2018-10718: The Huffman compression overflow - subject of this post
• CVE-2018-20817: A Steam authentication blob overflo – another flaw in older CoDs involving Steam online authentication data
• CVE-2023-34362: A new RCE in MW2 (2022) that was patched in 2023. This one is not related to the older games but shows that RCEs are still a concern in modern CoD titles.
• CVE-2019-20893: The "JoinParty" exploit - a different RCE that was also patched in 2023. This one allowed remote code execution via a crafted joinParty packet.

The fact that these remained in the games so long shows how undervalued security was in older titles, and how persistent the community had to be in advocating for fixes.

Conclusion

Reverse engineering the MW2 RCE vulnerability gave us a glimpse into the kinds of security issues that can lurk in game code and how attackers can abuse them. We saw that a simple oversight, a missing length check on a network packet, opened the door for arbitrary code execution. Through tools like disassemblers and network sniffers, researchers uncovered the bug and demonstrated its impact, which ultimately led to patches both official and unofficial.

If you’re a player, the lesson is to stay informed: when a game is said to have an RCE exploit, take it seriously. Either abstain from playing it online until it’s fixed, or use community patches/mods that address the issue. If you’re a developer (even a mod developer maintaining an old game), make sure to audit your network code carefully, especially any place data is copied or decompressed, ensure there are proper bounds checks.

Modern Warfare 2 is a classic that many of us have nostalgia for. Thanks to the efforts of the reverse engineering community and responsible hackers, we can continue to enjoy these older games with a bit more peace of mind. Just be sure to apply the latest fixes, and game on safely.

Sources:

• Heumann, Maurice. "Game Hacking reinvented? - A COD Exploit" – Personal blog detailing the discovery of the MW2 buffer overflow and RCE (Dec 2017).
• CVE-2018-10718 – Description of the MW2 vulnerability (stack buffer overflow via crafted packets, fixed April 2018).
• momo5502 (Maurice Heumann) on GitHub – COD Exploits repository with proof of concept code and README explaining the Huffman overflow in SV_ExecuteClientMessage.
• Plutonium Project Documentation – Notes on improved security and patching of old CoD engine vulnerabilities in community clients.
• Reddit / Community Discussions – Various threads confirming the exploit and discussing DLL fixes for the issue.
• AlterWare (IW4x forum) – Security notice confirming RCE vulnerabilities and their fixes in the IW4x client (community patch for MW2).