Many of you probably know LMAOBOX Premium, a video game cheat for team fortress 2. It costs 23$. I’d classify it as one of the more popular cheats in tf2’s cheating ecosystem. In this post we will be covering some of LMAOBOX’s inner workings.

Intro

LMAOBOX uses Digital Rights Management to restrict who can use their products. In order to make analysis more comfortable, i decided to modify certain behaviours of both cheat loader and payload. It was also important to me that people i shared those builds with couldn’t just run around using it in online matches. Do note that i have taken these measures while it was still working in the latest version of Team Fortress 2.

You could call much of these obsolete now, because right now you can’t even use it on the latest game build.

My patches don’t necessarily make it instantly bannable, but you will most certainly get caught using it in multiplayer.

  • The hardware locking mechanism was neutralized. It will succeed on any machine profile.
  • The network exchanges between loader and LMAOBOX.NET were carefully replaced with I/O operations on pre-captured material. You will therefore not receive automated updates.
  • The restart check has been removed. You can use LMAOBOX immediately without rebooting.
  • The steam termination on loader launch has been removed.
  • Instead of using process hollowing technique to hide their second stage in svchost.exe, loader will instead map the later stage into itself.
  • The email of this cracked build have been replaced.
  • The watermark is forced to be always visible.
  • ASLR + random offset into an allocation has been disabled, the cheat payload will effectively be mapped at 0x0000400000000000. if that address isn’t available, it might end up near it.
  • Some features like radar have been intentionally crippled. Some changes were made to make analysis more comfortable, others are designed to restrict the extent of damage an user of this specific cracked build might cause.

Certain behaviour designed for anti-cheat evasion has been removed from the cracked build. This doesn’t mean that you’ll get instantly banned. On a honest note though, cheating in Team Fortress 2 is lame. There is enough cheaters present and you’re not special for evading an anti-cheat that is as weak as TF2’s VAC.

You can download the cracked loader here. It doesn’t require an internet connection in order to run.

UPDATE 02/06/2026: The video game this cheat was written for has received an update a few days ago. You will therefore be unable to use it in-game. Of course, it still might be useful as an historical artifact. Check out the files that are present/later dropped on disk if you care about the cheat payload itself. You don’t need to run it if you want to examine the cheat payload, just check hagg.bin.

Detection

It isn’t that hard to detect somebody who is using LMAOBOX. Especially if you have the ability to run code on their machine, for example in form of a client-side extension that players have to obtain. I know this might sound scary, but if you think about it, you’re already running some form of third-party extension on major anti-cheat products, let’s take EAC as an example. Not only are you having those EAC modules on disk loaded, but also a second module is manually mapped directly into the game process.

You could argue that these are professional, commercialized companies and they wouldn’t need to do anything nefarious as they’re making money through legitimate anti-cheat solutions. And yes, you’re absolutely right on that. The biggest issue with such system that could detect a wide range of TF2 cheats isn’t really the detection itself, as that’s pretty much a walk into the park. Let’s consider how many game cheats in this specific ecosystem actually operate:

  • most of the time, they are using the following operating system API’s, or higher level equievalents.
    • NtOpenProcess: used to open a so called Handle to the game process. depending on the requested permissions, this lets them query information about a process, and perform remote virtual memory operations if permissions allow it. Handles can also be enumerated externally through multiple different ways. Although then it would likely turn into a race to catch the cheat loader trying to inject, depending on how long it has a handle open to the game. (and more…)
    • NtWriteVirtualMemory: used to access the virtual address space of the game process. used to interact with its memory from an external process, like a game cheat loader.
    • NtProtectVirtualMemory: used to manipulate the VAD permission of certain memory, for example in order to place code patches, or modify memory that would otherwise be protected from writes.
    • CreateRemoteThread: used to execute code, mostly either for a manually mapped module, or a standalone shellcode stub remotely. can also be used for injection of dependency modules, by setting thread-start parameter to LoadLibraryA/W, and parameter to a remote allocation which holds the path of the dependency module to remotely map.
  • in many cases, they will manipulate certain valve/game interfaces. to be more precise, they will target the VMTP. An object instance can have multiple VMTP’s which will be placed from the very beginning of the backing memory allocation of an individual instance, and increment in 8-byte steps on x64 / 4-byte steps on the x86 platform. so you will have the first VMTP at object+0x0, while the second one will be at object+0x8,0x10,0x18 and so on.
    • many compilers highly favour placing its virtual method tables within the .rdata section. when taking a look at the characteristics of this section in a PE-Image, you will notice that it contains exactly (IMAGE_SCN_MEM_READ | IMAGE_SCN_CNT_INITIALIZED_DATA ).
    • cheat developers however, like to redirect said VMTP to a manual allocation through windows memory management API’s. you can pretty much bet on the fact that many cheats will not meet these criteria while cloning a VMT and swapping the VMTP of an instance:
      • Memory type of the VMTP destination will likely be MEM_PRIVATE, vs. MEM_IMAGE which is the case when it points to .rdata within an image that is present in LDR.
      • Memory characteristics will not have IMAGE_SCN_CNT_INITIALIZED_DATA flag, which means that most likely it is not pointing to a legitimate .rdata section of an LDR-backed module. if it contains IMAGE_SCN_MEM_WRITE, that’s also something to think about. Apex’s anti-cheat is already using this in production, by the way. And let me tell you, it clapped a decent amount of some people i knew, and thought they would know for the better.
  • the later loader states are acquired through a network request to authv2. I couldn’t find any signature verification or more primitive, returned payload hash measuring on the client. LMAOBOX will allocate these later stages within memory regions containing ERW permission.

The most effective way is just measuring the integrity of virtual method tables, and instances of valve interfaces + their virtual method table pointer. I will discuss other methods too, you can find all of this below.

VMT/P and analysis of game interface instances

I built a small project named TFAC that does exactly that. It was made while Team Fortress 2 still ran on the x86 platform, so it won’t work for the last game build. However, i’m planning to release a much more comprehensive tool for this purpose, here on my blog.

I’ll update this post if it ever comes that far. I’d also recommend analyzing the hook handlers of TF2 cheat software, as that can give you valuable insights into how the cheat alters the game/engine and its overall logic within intercepted code paths.

Control Flow / Execution of cheat payload

If you go ahead and monitor some tactical code paths within certain game modules, you will quickly realize that LMAOBOX doesn’t make an effort to hide its execution. You can observe it a lot of times in any call stacks that you have captured while monitoring some of these hot execution paths.

There is also an interesting pattern of how LMAOBOX seems to overly rely on the dynamic CRT runtime, and frequently calls into the code of that module. Here are some API’s that are often executed:

KERNEL32.lstrcmp
MSVCR100.operator delete

As you can see, this is just a pretty minimal list. I just wanted to illustrate that there is functions which LMAOBOX will frequently invoke during its normal operation. You can reverse the cheat payload further and discover many other candidates that could be monitored.

Memory Allocation

In case of LMAOBOX, their cheat loader will use NtAllocateVirtualMemory or higher level wrappers, in order to allocate memory inside the game process. It requires this because it needs some form of memory that is:

  1. writable, in order to write its cheat payload into the game client.
  2. executable, because logically it needs to run the cheat payload as well.

Can you guess what permission LMAOBOX requests from windows MM? Take your time to make the guess.

They use ERW. There is no integrity check on the cheat payload, meaning you can freely overwrite its code and mess around with it, without anything happening. Unless you suck at patching and corrupt it yourself. You could simply look for things that stay constant even in between different subscriber accounts. You could also focus on runtime behaviour rather than just using something primitive like fingerprinting of certain memory patterns within the cheat payload.

drof.space is currently in a phase of inactivity! we hope to be back soon.