Mordhau: From reversing Unreal Engine 4 to breaking animations

There was a time where you could do a lot of funny glitches, like flying around. This was by far when I had the most fun with people. The game was so broken that you could fly anywhere, clip into stuff, and do much more.

You might think that people were using it to take advantage of people, but that was not the case. Instead, everyone was teaching glitches to each other, and goofing around. If someone was abusing a glitch, someone else could just use another glitch and kill them, or simply vote kick them.

However, they ended up patching most of the funny glitches, and even removing vote-kicks entirely. You could still clip into stuff and do other glitches, since the developers did such a bad job, but it was not the same.

The game is only available for Windows (and consoles), but you can still run it on GNU/Linux through Proton. A friend I met while playing told me about this, and it’s in fact what made me definitely switch from Windows to GNU/Linux on my main computer.

This means that any memory inspecting (more on this below) has to be done within the same wine prefix. I personally use this tool to accomplish that.

The developers of this game are terrible. In plenty of ways. They are bad at programming, they are bad at promoting their game, they are bad at basic decision making, and they are bad at moderating. Basically, they are not mature enough to handle a big game like this.

The game has no anti-cheat at all. You can read and write any values in memory, and change whatever you want as if this was Half-Life 1. I heard they had an anti-cheat at some point, but they removed it for some reason.

Not only do they lack an anti-cheat, but they look like they want people to cheat in their game. Years ago I noticed that they published an update with a PDB file, which contains very useful debugging information. I remember copying it quickly after noticing, because I obviously thought it was a mistake. Well, let’s have a look at the binaries folder now.

There it is, the third file on the list. They have been shipping the debugging information along the game for years. This is a big mistake, that allows anyone (with some reversing knowledge) to basically browse the source code of the game. I am assuming they don’t know what the file is, so they just leave it in the output folder because they assume that the game needs it.

You might also notice the suspicious .i64 files. In case the reader is not familiar with reversing, these are 64-bit IDA Pro databases, and they will be covered below.

As a side note, I think it’s very funny that this could happen to the developers to begin with. I don’t know what they used to compile this program, but I think the compiler/IDE should only generate this .pdb file when compiling in debug mode, and not in release mode. I am not sure if this means that they are shipping the debug version or not.

In any case, this is very funny, and it reminded me of how I didn’t know what object files were when I first started with C/C++, so I was not sure about including them on my git projects or not.

This article was been written in May of 2024, so keep in mind that they might have actually removed the .pdb file after I spoon-fed this information to them. If it’s still there, you can import it from IDA Pro, although the rest of this article doesn’t asume you have imported it.

I like reverse engineering, and I enjoy a few video-games. That’s why, if I really enjoy playing a game, I might try to reverse engineer it, to see how it was done. Since I use GNU/Linux, I mainly enjoy reversing native Linux programs and games. Even if I really enjoy a Windows video-game, the reversing interest is usually not big enough to make me switch to Windows.

However, since I had been playing Mordhau for such a long time, I decided to give it a try and, through Proton, see if I could find something interesting. I did find a lot of interesting stuff. I already knew how bad the game was, but noticing how many things were client-sided definitely made me realize that the developers were clueless.

I knew I could get banned, because I found things that I had never seen anyone do before, but I decided that I had played the game long enough, and that I didn’t care if I got banned. I rather have fun my way, than just play normally to avoid getting banned. I even took notes on writing this article once I got banned.

I don’t particularly enjoy cheating, as in, getting an unfair advantage over other players. I like reversing and making cheats because I enjoy the low-level aspect of understanding a game enough to do something that the developers are actively trying to prevent you from doing. That was a long sentence, by the way.

And indeed, I started reversing the game on January 2024, and I didn’t get banned until May of 2024. I think I saw a moderator in-game once… and it was before starting reversing the game. In the end, it was a jealous kid who reported my account because I wouldn’t tell him how to T-pose in game. They immediately banned me exclusively based on my screenshots.

Anyhow, this is good news, since now I am able to explain the reverse engineering process without being worried about bans, which was something I have wanted since I started reversing the game, just like I did with Devil Daggers or TF2.

Remember to open the Mordhau-Win64-Shipping.exe file, not Mordhau.exe files. We will also use this executable with UEDumper below.

Also, you will need some settings in order to find the required offsets.

First, open the Strings subview with View > Open subviews > Strings, or by pressing Shift+F12. From there, right click on the string list and press Setup. Make sure all C-style string types are allowed.

You can then press Ctrl+F in the Strings view to search for strings.

Search for the string MulticastDelegateProperty, and choose the one with C type, not 16-bits.

Double-click the string, then open the cross-references window by right-clicking the aMulticastdeleg symbol, or by pressing the x key. Jump to its only xref.

You are now in a big subroutine that handles a lot of strings. I opened the decompiler window so it’s easier to tell what’s going on, but it’s not necessary. From the assembly view, scroll to the top of the subroutine and list its cross references.

Jump to the first one, the Direction of the xref should be Up. The function where the MulticastDelegateProperty string was located is being called with the GNames structure as its argument, so we should be looking for something like this.

As you can see, the address of stru_57BEE80 is being loaded into rcx, which according to the Windows x64 calling convention, is used for the first parameter when calling a function. Note that the function call appears highlighted because I marked the location from IDA.

However, 0x57BEE80 is not the real offset of GNames. This is the “absolute” offset that IDA shows us, which would be accurate if we were loaded at 0x0. However, we want to get the relative offset to where the executable was mapped in memory. To get this relative offset, we will need to subtract the ImageBase, which we can obtain by typing get_imagebase() in the IDA command prompt.

Search for the string CloseDisregardForGC, and jump to its only xref. In the assembly, you will see that the string is being used as a function parameter.

Right before that function call, you can see that it’s checking for a byte_57D7AEC value. This is the assembly generated when compiling the following Unreal Engine code.

if (GUObjectArray.OpenForDisregardForGC())
{
    SCOPED_BOOT_TIMING("CloseDisregardForGC");
    GUObjectArray.CloseDisregardForGC();
}

The OpenForDisregardForGC value being checked is a 4-byte padded boolean. In the GUObjectArray structure, it’s located right before the ObjObjects array. Therefore, we can simply add 4 bytes to that byte_57D7AEC value, and we will get the offset of GObjects. Again, remember to also subtract the ImageBase.

Search for the string Failed to load package '%s' into a new game world., and jump to its only xref. Once you are in the subroutine, press F5 to decompile it.

In this case, we were lucky and the function call with our string has no labels near it, and the the decompiled subroutine looks pretty clean.

We are looking for that qword_590DC40 line at the bottom. That’s the UWorld global variable, but remember that we still need to subtract the ImageBase.

Although this was the ideal scenario, the decompiler might not always interpret the branches this way, and might show a bunch of jumps across labels. The function might look something like this:

  // ...
  // Label mess, qword gets assigned somewhere over here

LABEL_123:
  sub_1822B30(&PerformanceCount, L"Failed to load package '%s' into a new game world.", v124);
  if ( v6 == &PerformanceCount )
  {
      v7 = PerformanceCount;
  }
  else
  {
      // ...
  }

  // ...
  // Subroutine returns, qword assigment is not here

  return 0;
}

In that case, we would have to jump to the xref of that LABEL_123 and look for the same qword assignment below the jump.