The cheat exposes an API that is reachable via HTTP(S). It mostly relies on requests of type POST. Both loader and cheat payload make requests to LMAOBOX’s API. For lobby sharing, the cheat payload will use WinInet library functions, such as:

  • InternetConnectA
  • InternetSetOptionA
  • HttpOpenRequestA
  • InternetReadFile

Below you will find a brief explanation on the interfaces that have been discovered by me.

POST | lmaobox.net/v/authv2/ Sent by their loader to authenticate a cheat customer, using a combination of ( %CUSTOMER_EMAIL% + %PASSWORD% + %VOLUME_SERIAL% ). Requests are encoded using a basic BITWISE NOT transformation for the identity provider used to prove identity to their backend server. Importantly, for protection of the response, LMAOBOX decided to use a basic xor transformation. It will also contain the final loader stage in a slightly modified PE Format, and the actual cheat payload that is later injected into TF2.
POST | lmaobox.net/sl/v/ Sent by the cheat payload for Share My Lobby: Fetching the match registration table.
POST | lmaobox.net/sl/ Sent by the cheat payload for Share My Lobby: Registration of the local client with LMAOBOX Premium: Share my Lobby service.
GET | lmaobox.net/lua/store/ Sent by the cheat payload to request a .csv file which acts as a directory of scripts using LMAOBOX’s Lua scripting system. Its structure is defined publicly (check csv) If a LMAOBOX user looks into their Lua tab inside the cheat menu, it will flow like this: cheat payload -> WinInet API -> lmaobox.net/lua/store/ -> raw.githubusercontent.com/…/repo.csv


Some of these API methods require a valid cheat subscription which the client must prove using a very simple identity provider. I will explain it in more detail below… If you’d like to read some of the code that was responsible for the networking of this cheat, feel free to check out this repository. It contains a sample of decompiled code from the LMAOBOX cheat payload that is specifically related to this topic. It also ships a handful of useful scripts for interacting with the cheat backend.

/v/authv2/ | Authenticate & Receive Stage2 & Payload

As previously explained, this network request is made in order to authenticate with LMAOBOX’s backend server. In event of a successful request, you will receive the second loader stage and the cheat payload in an encoded form. Its encoded using the Password you used when registering on LMAOBOX’s website. It submits your customer E-Mail, Password, and a product identifier which in case of TF2, is “hl2”. It also submits your volume ID, queried by GetVolumeInformationA.

/sl/ | Register with “Share my Lobby” Service

LMAOBOX itself advertises this feature as “Share my lobby – Share my lobby with other lmaobox users”. It basically is a LFG (Looking-for-Group) platform which allows users of LMAOBOX to find each other. During registration, it transmits various metadata to its backend server:

  • Your Steam32-ID encoded in hexadecimals
  • Your region estimate (likely based on public IP)
  • Number of players present in your lobby (1/6)
  • Your current in-game name (In tf2, cheats can make it different from your real profile name.)

/sl/v/ | Fetch “Share My Lobby” Registration Table

The cheat payload makes a HTTP/POST request to https://lmaobox.net/sl/v/ through WinINET API. Without obfuscation, it uses the following format (this is passed to sprintf in later code stages):

Raw formatted buffer: i=47A2BE&u=lboxuser@gmail.com
u = customer email address
i = some hardcoded string within the cheat payload (could be user identity related and embedded by their custom pipeline, no idea) ** this one stays persistent per cheat build or possibly per account. it didnt change between relaunches and can be recovered by inspecting the cheat payload.

It would help if we could take a look at how the cheat payload is parsing the response from its lobby sharing backend. Luckily enough, we can view it without much hassle. Let’s see what it does:

char __fastcall LB::GetShareMyLobyyList(__int64 a1)
{
  // ...
  lpParams = 0;
  memset();
  v2 = LB::DecodeString(&v18, byte_4000001366F6);
  ((void (__fastcall *)(char *, char *, __int64, __int64))sprintf)(&lpParams, *v2, 0x47A2BE, v3);
 
  v4 = *(_DWORD *)(*(__int64 (__fastcall **)(__int64, char *))(*(_QWORD *)AVCSteamUserV019 + 16i64))(
                    AVCSteamUserV019,
                    &v19);
 
  if ( LB::ShareMyLobbyResponse )
  {
    *(_DWORD *)(a1 + 64) = 0;
    free(LB::ShareMyLobbyResponse);
  }
  v5 = (__int64 *)LB::DecodeString(&v18, byte_40000013670E);
  //
  // fourth argument determines the final operation.
  // 0 - register your own lobby
  // 1 - fetch the table of already opted in lobbies 
  //
  LB::ShareMyLobbyEndpoint(*v5, &LB::ShareMyLobbyResponse, (__int64)&lpParams, 1);
 
  LOBYTE(v6) = LB::DecodeString2(&v18);
  v7 = (char *)LB::ShareMyLobbyResponse;
  if ( LB::ShareMyLobbyResponse )
  {
    if ( *(_BYTE *)LB::ShareMyLobbyResponse ) 
    {
      do // v7 => LB::ShareMyLobbyResponse ;
      {
        v8 = *v7++;
        *(v7 - 1) = ~v8; // bitwise-NOT transform
      }
      while ( *v7 ); // decode the response
      v7 = (char *)LB::ShareMyLobbyResponse;
    }

In my opinion, this is a quite clean execution of an entire cheat-coordination/LFG concept. It basically uses LB::ShareMyLobbyEndpoint to fetch the lobby table from lmaobox.net, using WinInet API to make the underlying web request. It then decodes the response by applying a bitwise-NOT transform over the response buffer.

You might have noticed that it passes a second parameter to the network wrapper, LB::ShareMyLobbyResponse. It pretty much is just a C-style string buffer where the encoded response of the lobby fetch request is copied into, by their network request wrapper. In the same code snippet though, it is later decrypted in-place, meaning you can just inspect it in something like ReClass if you were interested in the already decoded response.

Tracking

If you’re wondering whether this could be used to track LMAOBOX Premium users: Yeah, absolutely! But only those who are opted into their lobby sharing system. I built a tracker that does exactly that. Its a standalone ASP.NET CORE API with two jobs. One is to regularily poll LMAOBOX’s backend server at this endpoint /sl/v/. Then it stores that data in a SQL-Database for both currently active, but also previously seen clients.

Because you cannot interact with this API without having a valid LMAOBOX Premium cheat license, it’s rather unlikely to end up being tracked as a legitimate player. For the most part it requires an active instance of LMAOBOX that has infected a TF2 game client. Or something that emulates it, which again is very possible, especially once it becomes more widely known.

I know that going public with this will likely burn the method, so i decided to track the ecosystem for a couple of Weeks and then shut my tracker down, right before going public. All information i was able to gather can be downloaded in SQLITE3 Format by clicking here. I also built a grafana dashboard to visualize all of this data.

While it might not be too useful, it still gives us valuable insight into the psychology of cheaters. I know this sounds ridiculous, but let me try to explain all variables. So with this system, we’ve got:

  • a stable identity via Steam.
  • the current in-game username (can be overriden by cheats).
  • an estimated region of the user.
  • number of players grouped together in that lobby.
  • lobby type, a self selected variable consisting of Rage Hacking, Mann vs Machine (PvE), Competitive, and Casual.

If you make use of longitudinal tracking here, then you would also end up with a list of all names ever used by that Steam persona.

Conclusion

I began tracking this cheat user coordination system around Feb. 2026. This whole operation lasted all the way until April 19, 2026, which is the day my license key for this specific cheat was revoked by their staff team. Allegedly, some of what i’ve talked about in this post was also changed by their developer. It might also be possible that your license will be terminated if you are doing mistakes while attempting to imitate the cheat client while contacting its backend server. I have no evidence on this, so you should take it with a grain of salt.

Well, their move of revoking my access is quite understandable actually. If you think about it, i have just:

  • cracked their video game cheat,
  • posted a documentation for parts of their production backend online,
  • and also hosted a demo relay that would allow anybody to track who is currently sharing their lobby on LMAOBOX
    • this relay was in on-demand mode for a long time, sometimes toggled on, sometimes toggled off. including from Apr 7 – Apr 18 2026.
      • meaning, it would:
      • A.) only poll LMAOBOX’s backend when somebody sends a request to my demo endpoint
      • B.) if the external polling request were to be received within <15s of the last fetch from actual LMAOBOX origin, then a cached version of the data would be served instead.
    • no data was persistently collected during the operation in this mode. i did make use of persistent tracking in the entire time frame of March 2026. And late February possibly, however at that time it was mostly just for debugging purposes and well, obviously figuring out whether lobby sharing was even significant enough to talk about.

You can see in their license agreement that the cheat provider forbids sharing your license with other players. While it is possible to request a hardware unlock, it usually isn’t intended for continuous sharing, and what i did was completely disarm any license or hardware binding enforcement. The artifact that i published didn’t speak to lmaobox.net at all. Earlier versions of my crack were fully offline, and later builds used my simple content delivery endpoint.

I’m not interested at all in continuing this, because i consider my goals within the scope of this project as fully met. I was able to gain insights into how a real-world cheat user coordination/social system was structured. There was also a lot of interesting behavioural patterns that I could observe while sifting through months of my collected logs and visualized dashboards. For example, tracking all name changes within a discovered LMAOBOX player identity would give you valuable insight into how they’re trying to portray themselves.

I figured that it would also be a good idea to expand on my previous statement regarding publicity. I published this post on April 7 2026. By that time i already had a moderately large data set of collected cheat user identities. It could be considered peanuts for some, however to me it was plenty and certainly enough to answer all my questions:

  • how much of a role cheating plays in 2026 / Team Fortress 2 Ecosystem
  • whether people even use LMAOBOX nowadays,
    • and how they behave ingame
      • what gamemodes do they prefer
      • can any trends be observed, such as in region estimates, or self selected intent labels regarding play-style
      • how do ban rates look, are there any patterns, for example higher ban rates for RAGE intent label, VAC vs Game ban (different ban types)
  • what their impression management strategies are, and how developed their psychological arsenal is.

After i published the blog post, the method obviously became public which had a significant impact on data quality. I have injected a couple of fake identities myself into LMAOBOX’s lobby sharing table, however it was strictly for testing, and at no point did i intend to troll anybody or do anything that was nefarious with it.

One day i woke up and checked my tracker, and i saw something funny. It seems like somebody has attempted to replicate what i did previously, and they managed to succeed with just one catch: It seems like they failed to correctly handle the SteamID format that LMAOBOX backend and cheat payload expects. See, it uses a Steam32-UID, decimal converted to hexadecimal.

I stared at my logs for hours, trying to determine whether it was a bug in my code. But i haven’t been able to find any entries like this for days after these obviously synthetic records in the lobby sharing table appeared.

The broader meaning of all that is just: Once something is well documented in a public manner: The direct operational impact might decline steeply. The entire point of my project was that LMAOBOX users and their staff team didn’t know that my tools were able to track anybody who opts into their lobby sharing service. Once it becomes public knowledge, you could try to chase it further but it usually isn’t worth it anymore.

After you have already tracked people for months, the novelty also dies eventually, and it just fills your server disks with brainrot cheat user IGN’s. Additionally, people already started injecting fake entries independently from my testing into it, however it was mostly isolated incidents. Still, it reduced the reliability of my dataset. This was obviously expected because i had published everything regarding my project, like even straight up scripts for fetching and injecting fake entries.

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