codeneverdies!

Anti-Cheat: Stopping Memory Acquisition via Crash Dumps

Tue, 16 Jun 2026 00:00:00 +0000

It’s no secret that cheaters and security researchers want to get their hands on anti-cheat software. Many anti-cheat developers virtualize and pack their binaries, making static analysis harder. This forces adversaries to analyze the anti-cheat software dynamically, which could entail stepping through the unpacking process manually then dumping the anti-cheat driver from memory. Attaching a kernel debugger can also be a problem due to anti-debugging checks, so how are people dumping anti-cheat drivers? And how could they prevent this in the future? That leads us to our topic today.

Memory Acquisition via Crash Dumps

During a quick chat with a seasoned game hacker, dumping anti-cheat drivers from crash dumps has been around for a while. If the adversary isn’t skilled enough to conduct a BYOVD attack and dump the driver, they can resort to this easier method. Here’s some external research to help you understand what this article will be about. On april 7th, 2023 a clever person on the guided hacking website named MrMoo showed us How To Dump EA’s Driver by intentionally crashing the system. Once the system rebooted he analyzed the kernel crash dump with volatility to dump the anti-cheat driver. June 7th, 2024 a user on unknowncheats LabGuy94 posted about the same technique. Two years later on march 5th, 2026 a researcher named s4dbrd published his analysis on BattlEye’s anti-cheat driver utilizing this technique and NotMyFault to dump their driver from memory. Finally on june 16th, 2026 I published a tutorial on the guided hacking showcasing how you can crash the system with and without NotMyFault. After the kernel memory dump was generated, I transfered it to my host machine and dumped the anti-cheat driver from the crash dump using windbg. One thing these all have in common is that they generate a bug check (BSOD). It may seem like this is a full proof method of dumping the anti-cheat because once the system is crashing the anti-cheat has no control. I like to think that this is far from the truth, the rest of this article aims to back that up and show you how this can be stopped.

Stopping Memory Acquisition via Crash Dumps

Our journey starts at the manually initiated crash screen, we know that users are crashing their systems on purpose and a common bug check code seen is MANUALLY_INITIATED_CRASH.

If we search for this bug check code and snoop around MSDN, we’ll that find Microsoft allows drivers to register callback functions that run when the system bug checks and starts to generate the kernel crash dump. A driver can register a bug check callback routine by calling KeRegisterBugCheckCallback or KeRegisterBugCheckReasonCallback. KeRegisterBugCheckReasonCallback is what we’ll be using, this function is useful because in the KBUGCHECK_CALLBACK_REASON Reason argument we can specify KbCallbackRemovePages. This enum value tells the windows kernel that our callback will be removing pages from the crash dump. I’m sure you can do something with the KbCallbackDumpIo type as well but I feel that my method is more straight forward. When you’re writing bug check callbacks you’re pretty restricted from what you can do so it’s best to keep it simple. A bug check callback with type KbCallbackDumpIo can be called multiple times during the crash, so I just played it safe.

About Bug Check Callback Routines

To understand more about what we’re doing let’s look at the implementation of KeRegisterBugCheckReasonCallback, and other related data structures.

// https://doxygen.reactos.org/d3/d13/bug_8c.html#a73fca11ec74d2871e8981bbcd00f0f24
BOOLEAN KeRegisterBugCheckReasonCallback(PKBUGCHECK_REASON_CALLBACK_RECORD CallbackRecord, PKBUGCHECK_REASON_CALLBACK_ROUTINE CallbackRoutine, KBUGCHECK_CALLBACK_REASON Reason, PUCHAR Component) {
    
    KIRQL OldIrql;
    BOOLEAN Status = FALSE;
    KeRaiseIrql(HIGH_LEVEL, &OldIrql);

    if ( CallbackRecord->State == BufferEmpty ) {
        CallbackRecord->Component = Component;
        CallbackRecord->CallbackRoutine = CallbackRoutine;
        CallbackRecord->State = BufferInserted;
        CallbackRecord->Reason = Reason;
        InsertTailList(&KeBugcheckReasonCallbackListHead,&CallbackRecord->Entry);
        Status = TRUE;
    }

    KeLowerIrql(OldIrql);
    return Status;
}

First KeRegisterBugCheckReasonCallback raises the IRQL to HIGH_LEVEL, then it checks if the callback record was initialized by KeInitializeCallbackRecord (This is just a macro for PKBUGCHECK_REASON_CALLBACK_RECORD->State = BufferEmpty). If it was then the callback record is initialized, and it gets inserted into the KeBugcheckReasonCallbackList. In our case it should be in the KeBugCheckAddRemovePagesCallbackList.

But wait there’s two more bug check lists:

KeBugcheckCallbackListHead: Used by callbacks registered by KeRegisterBugCheckCallback
KeBugCheckTriageDumpDataArrayListHead: Used by callbacks of type KbCallbackTriageDumpData

Maybe you can remove a callback from these lists? I’m not sure if these are protected by patch guard (KPP) or not.

Hypervisor Detection Using Bug Check Callbacks

To give you more insight on how other people have used bug check callbacks in the anti-cheat space, let’s go back six years. On april 13, 2020 members from secret.club (daax, iPower, ajkhoury and drew) wrote about how anti-cheats detect system emulation. In the section named XSETBV, they talk about using the XSETBV instruction to intentionally generate a fault that will cause a VM-exit. Majority of public hypervisors used to analyze anti-cheat software will handle this in the host’s XSETBV handler. Because of this and the driver not being able to handle SEH (it’s manually mapped), the host will bug check (BSOD). This is why they registered a bug check callback routine using KbCallbackSecondaryDumpData, to add data to the crash dump and uniquely identify their crash data. Today we’ll be removing data from the crash dump.

Removing The Anti-Cheat Driver From The Crash Dump

Before we get started here’s a little recap/road map, we’ll call KeRegisterBugCheckReasonCallback to register our bug check reason callback so we can run code when the system bug checks. When calling this function we will supply KbCallbackRemovePages in the Reason argument, so the windows kernel knows that our callback will remove pages from the dump. Here’s how I registered my bug check callback.

callback_record = ExAllocatePoolWithTag(NonPagedPool, sizeof(KBUGCHECK_REASON_CALLBACK_RECORD), CARDINAL_MEM_TAG);
if (!callback_record)
    return;

cardinal_get_info();
UCHAR component[] = "Bugcheckin\n";
KeInitializeCallbackRecord(callback_record);
KeRegisterBugCheckReasonCallback(callback_record, cardinal_bugcheck_cb, KbCallbackRemovePages, component);

Each bug check reason callback routine has the following prototype.

typedef VOID (*bugcheck_cb_t)(KBUGCHECK_CALLBACK_REASON Reason, PKBUGCHECK_REASON_CALLBACK_RECORD Record, PVOID ReasonSpecificData, ULONG ReasonSpecificDataLength)

Reason will be one of the enum values for example.. KbCallbackDumpIo, KbCallbackRemovePages, KbCallbackAddPages, etc. Depending on the Reason, ReasonSpecificData can be cast to many other data structures. In our case we’ll be casting it to KBUGCHECK_REMOVE_PAGES. When this callback routine is called, the kernel will have already populated the BugCheckCode member of this struct. We’ll use that to determine what kind of crash it was.

VOID cardinal_bugcheck_cb(KBUGCHECK_CALLBACK_REASON Reason, PKBUGCHECK_REASON_CALLBACK_RECORD Record, PVOID ReasonSpecificData, ULONG ReasonSpecificDataLength) {
    PKBUGCHECK_REMOVE_PAGES bugcheck = (PKBUGCHECK_REMOVE_PAGES)ReasonSpecificData;
    if ( // Bug checks intentionally generated by the keyboard and NotMyFault
        bugcheck->BugCheckCode == MANUALLY_INITIATED_CRASH ||
        bugcheck->BugCheckCode == KERNEL_MODE_HEAP_CORRUPTION ||
        bugcheck->BugCheckCode == PAGE_FAULT_IN_NONPAGED_AREA ||
        bugcheck->BugCheckCode == DRIVER_OVERRAN_STACK_BUFFER ||
        bugcheck->BugCheckCode == DRIVER_IRQL_NOT_LESS_OR_EQUAL
    [..snip..]

If the bug check code was one of the following, then we can start to remove the anti-cheat driver from the crash dump. To do this we need to populate three more members of the KBUGCHECK_REMOVE_PAGES struct. First, KBUGCHECK_REMOVE_PAGES.Flags this member determines if the address that we supply next is going to be a virtual or physical address. I’ll be setting the KB_REMOVE_PAGES_FLAG_VIRTUAL_ADDRESS flag.

bugcheck->Flags |= KB_REMOVE_PAGES_FLAG_VIRTUAL_ADDRESS;

To finalize removing the anti-cheat from the crash dump, we need to populate two more members. First KBUGCHECK_REMOVE_PAGES.Address, this tells the windows kernel where in the crash dump to start removing pages. This will be set to the base address of our driver. Second KBUGCHECK_REMOVE_PAGES.Count, this determines how many pages need to be removed from the start address. To populate both of these members I wrote a function that locates the base address and size of the anti-cheat driver, then calculates how many pages need to be removed from the crash dump.

VOID cardinal_get_info() {

    [..snip..]

    PKLDR_DATA_TABLE_ENTRY entry = (PKLDR_DATA_TABLE_ENTRY)PsLoadedModuleList->Flink;
    while ( (PLIST_ENTRY)entry != PsLoadedModuleList ) {

        if ( !RtlCompareUnicodeString(&entry->BaseDllName, &drv_name, TRUE) ) {
            base = (ULONG_PTR)entry->DllBase;
            size = (ULONG_PTR)entry->SizeOfImage;
            break;
        }
        
        entry = (PKLDR_DATA_TABLE_ENTRY)entry->InLoadOrderLinks.Flink;
    }

    cardinal_pg_sz = (size + PAGE_SIZE - 1) / PAGE_SIZE;
    cardinal_base = base;

}

Once these global variables are populated we can populate the members inside of our bug check callback.

bugcheck->Address = cardinal_base;
bugcheck->Count = cardinal_pg_sz;

Now if we intentionally crash the system while the anti-cheat driver is loaded, we won’t be able to dump it to disk because the driver’s pages we’re removed from the crash dump! Rendering this method useless :). Let’s see this in action, I won’t be showing you how to crash the system you can find that information else where! What I did to test this was crash the system with the bug check callback registered. At first glance I didn’t think this worked because I was able to see it in the list of loaded modules (stupid of me), then I tried to view the base address of the driver in windbg’s Dissasembly tab and I was met with something interesting.

Trying to view the module in windbg also tells us that we can’t view the module’s info, because the pages aren’t present in the crash dump and that’s exactly what we want to hear :).

Bonus: Detecting Crash Dump Registry Keys

Instead of fighting during the crash, why not just check to see if the registy keys that enable these types of crashes are enabled? This way we don’t have to register a bug check callback routine if we don’t have to because we’ll know what to prepare for. The table below is a list of registry keys that can be used to bug check intentionally.

Path	Key	Value
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\crashdump	CrashOnCtrlScroll	0x01
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kbdhid\crashdump	CrashOnCtrlScroll	0x01

Remarks

I left out two methods of intentionally crashing the system from the bug check routine. I think it would be good for both sides to do the research themselves and find out what can be done next. I really enjoyed learning about this and I think that it’s a very niche technique. I can’t really see this being used anywhere else other than in rootkits and anti-cheats that are packed, and want to stunt analysis when they’re unpacked. You can view the full code for this article here.

Bug Check References

Anti-Cheat: Valve Anti-Cheat (VAC)

Sun, 20 Apr 2025 00:00:00 +0000

In 2002 Valve created an Anti-Cheat solution called “Valve Anti-Cheat” aka VAC. The first game they implemented VAC into was Counter-Strike. When VAC was introduced it only operated in User Mode (Still does) meaning it runs entirely in user space ¹ and has no kernel component.

Below is a list of games that use VAC.. ²

Call of Duty: Modern Warfare 2
Call of Duty: Modern Warfare 3
Counter-Strike (video game)
Counter-Strike: Condition Zero
Counter-Strike: Source
Counter-Strike 2
Day of Defeat
Day of Defeat: Source
Deathmatch Classic
Half-Life 2: Deathmatch
Half-Life Deathmatch: Source
Ricochet
Team Fortress
Team Fortress Classic

A longer list can be found here ³.

VAC-cident?

So.. if you don’t know VAC has been around for quite a while, at the time of writing it’ll be 23 years. Over the time they’ve made some mistakes but who doesn’t? (Taken from wikipedia) ⁴ ⁵

- In July 2010, [snip] Approximately 12,000 owners of Call of Duty: Modern Warfare 2 were 
banned when Steam updated a DLL file on disk after it had been loaded into memory by the 
game, causing a false positive detection. These bans were revoked and those affected received 
a free copy of Left 4 Dead 2 or an extra copy to send as a gift. 

- In October 2023, certain users of AMD graphics cards were banned from Counter-Strike 2 
after AMD added support for their "Anti-Lag+" feature via a driver update, which the game 
flagged as a cheat due to it detouring certain DLL functions. AMD subsequently withdrew the 
driver update and Valve pledged to unban any affected users.

This post isn’t created to bash Valve they clean up after their mistakes and listen to their community, gotta love devs when they do that. I also commend them because getting VAC banned isn’t such a slap on the wrist. Getting VAC banned has some stipulations such as:

Having the VAC ban show on your Steam profile
Being banned from all “GoldSrc” games
Being banned from all “Source engine” games (The Counter-Strike serise)
Not being able to refund the game you’re VAC banned on

Knowing what’ll happen if you get VAC banned is important to know because regardless if you’re cheating or not false bans are no good. People in the community took it upon themselves to reverse engineer the Anti-Cheat and understand what it does (some did it just to cheat).

VAC what?

The previous section brings us to a term you may have heard before, the infamous “VAC Bypass”. Searching online for information about bypassing VAC brings many blogs and repos that all seem to do/talk about something similar and that’s “Dumping the VAC modules”. Let me explain, VAC is NOT just one executable on the system it streams it’s Anti-Cheat modules (DLLs) from a server, once a module is recieved by some routine in steamservice.dll inside steamservice.exe (or steam.exe if ran as admin) it will be loaded using one of the two methods below. ⁶ ⁷ ⁸ ⁹ ¹⁰ ¹¹ ¹² ¹³

Reflectively load the DLL into memory
Use the WinAPI function LoadLibrary

By default the Anti-Cheat modules are reflectively loaded into memory. The goal is to force LoadLibrary into being used, then someone can hook that function and dump the modules (DLLs) to disk, allowing someone to analyse the dumped DLLs and understand what they’re doing to detect cheating.

Dumping VAC Modules in the big ‘25

To kick start the journey on dumping the VAC modules load steamservice.dll into Binary Ninja. Once the binary is fully analyzed go to “Triage Summary”

It is VERY important to take note that this is a 32-bit process, so all pointers will be 32-bits in size you’ll see why this is important later.

Next we’ll search for calls to LoadLibrary* I’ll save the reader some time and tell you that we should be looking for calls to LoadLibraryW it will be called in a very important function that we can use to back track.

Following the reference takes us to an interesting function sub_10086f80

Judging by the return value HMODULE and the calls to LoadLibrary* it’s safe to say this function’s job is to load some kind of module and return a handle to it. Following references to where this function is called leads us to another interesting function sub_10086c40.

The beginning of the sub_10086c40 function didn’t look too important (at the time) but we should remember that this function also returns a handle to a module. I looked at the references and it shows that this function is called once in the function sub_10059040.

We can see sub_10086c40 being called if we trace back the first argument passed to that function, we’ll see that it was used by another function sub_100859d0. If that function call is successful execution carries on, so it’s safe to say it’s important. Let’s take a look at this function.

This function makes two WinAPI calls

GetTempPathW

Retrieves the path of the directory designated for temporary files.
GetTempFileNameW

Creates a name for a temporary file. If a unique file name is generated, an empty file is created and the handle to it is released; otherwise, only a file name is generated.

The combination of these calls tells us that we need to be looking for any .TMP files being accessed, the names are usually in this format <uuuu>.TMP.

Now there’s a path to a DLL floating in memory how does it get used? Look no more.

100591f7   HMODULE eax_13 = sub_10086c40(edi_1, 0)
100591ff   *(esi + 4) = eax_13
100591ff   
10059204   if (eax_13 != 0)
10059215       int32_t eax_14 = sub_10086c20(eax_13, "_runfunc@20")
1005921d       *(esi + 0xc) = eax_14

The path edi_1 is used by sub_10086c40, this function is used to get a handle to a module eax_13 then it’s passing that handle to sub_10086c20. sub_10086c20 takes two arguments we know the first is a handle to a module the second is from what we can see here a string _runfunc@20, the return value int32_t looks a little weird but this is a 32-bit process remember ;) so this could be a pointer to something dont ya think? Here’s the function prototype

int32_t sub_10086c20(HMODULE arg1, PSTR arg2)

Place your bets on it being a GetProcAddress wrapper.. Drum roll please… It is…

So with this bit of information we know steamservice.dll recieves the VAC modules, it’s using a function sub_10086c40 which calls sub_10086f80 to load the Anti-Cheat module and return a handle, then that handle is passed to sub_10086c20 to get the address of a function named _runfunc@20. By default as said earlier the modules are reflectively loaded so this isn’t the regular control flow of steamservice.dll, this can be confirmed if you scroll up a bit in sub_10059040 you’ll see a flag being checked.

steamservice.dll will most likely take this path unless we can do something about it

Let’s look at it in assembly

Take a look at je 0x10059127 ( 0x74 0x47 )

0x74 is the jump if equal instruction and 0x47 is how many bytes forward to jump (71) in hex

What we wan’t to do is change the first instruction at steamservice.dll + 0x590DE (0x100590de)

to jne 0x10059127 ( 0x75 0x47 )

we’re changing the first byte of this instruction to be 0x75 which is jump if NOT zero/equal. (Inverting)

Now that we have a potential way of dumping the VAC modules let’s test it! first we start steam and launch x32dbg as admin we should remember the offset to our instructions steamservice.dll + 0x590DE.

Once x32dbg is loaded attach to steamservice.dll

Press CTRL+G and enter steamservice.dll + 0x590DE

Now we’re where we need to patch

Right click on that instruction and click “Assemble” then enter jnz 0x10059127 and hit ok

It should be changed

The next step is to open Procmon play a game that uses VAC (I chose CSGO) and wait for steamservice.exe to access some .TMP files.

Here are the Procmon filters

While loading the game we see our first TMP file C:\Windows\Temp\D54A.tmp

Let’s join a public match and see if there are others

And some more..

We can also look at these files in the temp directory..

I copied all of these files to a new directory and loaded D54A.tmp into PE-bear

We see something familiar _runfunc@20 this is the function that was found using sub_10086c20.

To be continued

In the next post we will be doing analysis on these Anti-Cheat Modules to get a better understanding of what’s going on. I hope you enjoyed this post and most importantly learned a thing or two. Stay tuned!

References

Game Hacking: BakkesMod

Thu, 17 Apr 2025 00:00:00 +0000

So i’ve been playing rocket league for as long as I can remember, and I have this mod called BakkesMod. I have BakkesMod to use skins I don’t have unlocked, you can basically call it a “skin changer” with one caveat, you can only see the skins client side. On the other hand it has loads of functionality.

It was only a matter of time before I thought to myself “How does this even work?” so I did what anyone else in the world would do, and that was go to their github repo :).

The Injectahhhhh

Upon visiting their profile I see many interesting repos but one catches my eye.

https://github.com/bakkesmodorg/BakkesModInjectorCpp

This is the code for their DLL Injector, i.e place an arbitrary DLL inside the address space of another (remote) process. Once that DLL is inside of the remote process it creates a remote thread to call DllMain of the DLL that was injected, once DllMain is called execution starts and BakkesMod can do it’s thing.

DLL Injection is not a new technique, it’s a widely known technique to get code to run inside of another process. Sometimes malware and cheats use DLL Injection to setup for things like hooking because once their DLL is loaded into the target process it has access to the memory of that target process as well, meaning it can manipulate the functionality of the process while it’s running which is a big win for someone who wants to do so.

Sidenote: (BakkesMod is considered a “Mod” not a “Cheat” hence the name, it does not give an unfair advantage)

Here’s a code snippet from ired-team demonstrating DLL Injection

int main(int argc, char *argv[]) {
	HANDLE processHandle;
	PVOID remoteBuffer;
	wchar_t dllPath[] = TEXT("C:\\experiments\\evilm64.dll");
	
	printf("Injecting DLL to PID: %i\n", atoi(argv[1]));
	processHandle = OpenProcess(PROCESS_ALL_ACCESS, FALSE, DWORD(atoi(argv[1])));
	remoteBuffer = VirtualAllocEx(processHandle, NULL, sizeof dllPath, MEM_COMMIT, PAGE_READWRITE);	
	WriteProcessMemory(processHandle, remoteBuffer, (LPVOID)dllPath, sizeof dllPath, NULL);
	PTHREAD_START_ROUTINE threatStartRoutineAddress = (PTHREAD_START_ROUTINE)GetProcAddress(GetModuleHandle(TEXT("Kernel32")), "LoadLibraryW");
	CreateRemoteThread(processHandle, NULL, 0, threatStartRoutineAddress, remoteBuffer, 0, NULL);
	CloseHandle(processHandle); 
	
	return 0;
}

Now that we know BakkesMod does DLL Injection we should be looking for these function calls inside the code

OpenProcess
WriteProcessMemory
VirtualAllocEx
VirtualProtect (maybe)
CreateRemoteThread

Looking around you’ll see a couple files but one should stick out like a sore thumb, DllInjector.cpp In this file you’ll find a function called InjectDLL

This function takes in a std::wstring processName which would most likely be RocketLeague.exe and a std::filesystem::path path which would most likely be the path to the DLL to be injected. Inside the function we can see it’s doing the same exact thing we saw from ired-team’s demonstration, the order of the functions are a little different but they both serve the same purpose and that’s Injecting a DLL into a remote process.

On lines 57-60 after it has a valid handle to the process it locates the address of LoadLibraryW using GetProcAddress

This is also done in ired-team’s demonstration here

PTHREAD_START_ROUTINE threatStartRoutineAddress = (PTHREAD_START_ROUTINE)GetProcAddress(GetModuleHandle(TEXT("Kernel32")), "LoadLibraryW");

Lines 61-64 handle allocating memory for the library name string and writing that to the allocation.

65-77 is where CreateRemoteThread is called to start execution, after execution has started BakkesMod waits and then does some cleanup.

looking at the CreateRemoteThread and LoadLibraryW documentation on msdn helps understand what’s going on.

HMODULE LoadLibraryW(
  [in] LPCWSTR lpLibFileName
);

LoadLibraryW takes in one parameter, a pointer to a widechar string that is the name of a DLL to be loaded.

HANDLE CreateRemoteThread(
  [in]  HANDLE                 hProcess,
  [in]  LPSECURITY_ATTRIBUTES  lpThreadAttributes,
  [in]  SIZE_T                 dwStackSize,
  [in]  LPTHREAD_START_ROUTINE lpStartAddress,
  [in]  LPVOID                 lpParameter,
  [in]  DWORD                  dwCreationFlags,
  [out] LPDWORD                lpThreadId
);

In our case lpStartAddress is the address of LoadLibraryW and lpParameter is dereercomp which is a pointer to the name of the DLL to be loaded. So a thread will be created and once it starts LoadLibraryW will execute with whatever string is held at the memory of dereercomp.

Gettin’ dirty

With all this information idk about you but this makes me wan’t to write my own DLL Injector, let’s get to it. First we’ll start with finding the process ID of rocket league, this is a special number the OS uses to identify a process. We need it to tell OpenProcess what process we wan’t a handle to.

Here’s my code to find the process ID of rocket league.

DWORD get_pid() {

    DWORD pid = 0;
    PROCESSENTRY32 proc_entry = { .dwSize = sizeof(PROCESSENTRY32) };
    HANDLE snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);

    if ( Process32First(snapshot, &proc_entry) ) {
        do {
            if ( strcmp(proc_entry.szExeFile, "RocketLeague.exe") == 0 ) {
                pid = proc_entry.th32ProcessID;
                break;
            }
        } while ( Process32Next(snapshot, &proc_entry) );
    }

    return pid;
}

Once our process ID is found we can use OpenProcess to get a handle

HANDLE rocket_league = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);

Now that we have a handle to the process we can allocate some memory for our widechar string

LPVOID allocated = VirtualAllocEx(rocket_league, NULL, path_sz, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);

Next step is to write our DLL string to the allocated memory

WriteProcessMemory(rocket_league, allocated, path, path_sz, NULL);

Last but not least get the address of LoadLibraryW using GetProcAddress


LPVOID loadlib = (LPVOID)GetProcAddress(GetModuleHandleW(L"kernel32.dll"), "LoadLibraryW");

and create a new thread inside rocket league pointing to LoadLibraryW with one parameter allocated

HANDLE thread = CreateRemoteThread(rocket_league, NULL, NULL, (LPTHREAD_START_ROUTINE)loadlib, allocated, 0, NULL);

I almost forgot to mention the dll we will be loading here it is.. Just a simple MessageBoxA payload

// loadme.c -> loadme.dll

#include <windows.h>

BOOL WINAPI DllMain(HMODULE hModule, DWORD reason, LPVOID lpReserved) {

        switch (reason) {

                case DLL_PROCESS_ATTACH:
                        MessageBoxA(NULL, "I was loaded", "I was loaded", MB_OK);
                        break;

                case DLL_THREAD_ATTACH:
                        break;

                case DLL_THREAD_DETACH:
                        break;

                case DLL_PROCESS_DETACH:
                        break;

        }

        return TRUE;
}

With all of this let’s see how it looks under the hood.

Debug time ( ͡° ͜ °)

When our injector is open inside of x64dbg we set a breakpoint on “OpenProcess”

Once we hit that break point and return, set a break point on VirtualAllocEx

Before we return out of VirtualAllocEx look at the RAX register that will be the return value, This is the address of our allocation inside of Rocket league.

Now set a breakpoint on “WriteProcessMemory” execute that and reread our memory region to see our payload

Same as before set a breakpoint on “CreateRemoteThread” but look at the arguments passed and remember the function prototype.

Is the process handle to the rocket league
the security attributes (NULL)
stack size (NULL)
lpStartAddress (address of LoadLibraryW)
lpParameter (first parameter to ^)
CreationFlags (0)
ThreadId output (NULL)

Once this remote thread is created we see something nice

Remarks

This post was aimed towards beginners/people who know little about game hacking/game security and want to learn more. I am so fascinated by the idea that malware and cheats share the same techniques and I will continue to try and document the things I find to support that idea. Thank you for reading.

References

https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createremotethread

https://pentestlab.blog/2017/04/04/dll-injection/

ired-teams’s dllinjection

BakkesMod - Github repo

Their injector repo

Land Of The PEB: Running from the debugger

Wed, 26 Mar 2025 00:00:00 +0000

Welcome to the second installment of “Land Of The PEB”. Last post we talked about what the PEB was and some ways it could be used to ones advantage. You can’t run from it trust me.. You can find it in your nearest neighborhood even the one you’re using to read this post (If you’re on windows), but one thing we may be able to run from is the debugger. Using the PEB for Anti-Debugging purposes is a fairly known technique but don’t let that fool you it’s still a good thing to know.

“You must learn to walk before you can run”

So.. you wan’t to learn how to detect debuggers? There are a couple of ways to do so the two simplest ways I’ve found are:

Check the BeingDebugged member in the PEB
Check NtGlobalFlag in the PEB (To see if the process was created by a debugger)

these two don’t do much justice compared to other Anti-Debugging methods but they sure are robust. We will start with the second method first. If you’ve followed my previous post you should already have some way of getting a pointer to the PEB so I will be going off that. I will be doing this in C/ASM.

Here is my assembly code to get a pointer to the PEB ¹


get_peb:
    push rdi
    mov rdi, rsp
    sub rsp, 0x20
    xor rax, rax
    mov rax, gs:[0x60]
    mov rsp, rdi
    pop rdi
    ret

Running to the (NtGlobal)Flag

Before we move on we should talk about what NtGlobalFlag is and how we can get to it.

In the windows registry we can see that the “GlobalFlag” key’s value is set to 0 This tells us that this is the default value.

This can be confirmed by starting any process like notepad.exe, attaching a debugger to it and looking at the NtGlobalFlag in the PEB. Notice how I said to start a process then attach, it will make much sense later.

Once notepad is open click “attach” in x64dbg and find notepad.exe in the list of processes.

Once you’re in x64dbg hit run until notepad is fully functional. This should look familiar, we are going to index 0x60 bytes into the TEB (gs) using this command.

mov rax, gs:[0x60]

Now the address of the PEB should be in the RAX register.

Can be confirmed if you right click on that address in the RAX register and click “Follow in Memory Map”

With this pointer we can grab the NtGlobalFlag value in the PEB which is at offset 0xBC on 64-bit systems with this command.

mov al, [rax+0xBC]

If you followed correctly earlier, the value in the RAX register should NOT change due to the fact that the notepad process was not created by a debugger we only started notepad and then attached the debugger to it.

Now we will write a small program to check this flag and we will start it with a debugger. ²

    ... snip ...
    
    xor rax, rax
    mov rax, gs:[0x60]
    
    mov al, [rax+0xBC]
    and al, 0x70
    cmp al, 0x70
    jz goodbye
    xor rax, rax

    ... snip ...

goodbye:
    xor rax, rax
    add al, 1
    mov rsp, rdi
    pop rdi
    ret

Once the binary is loaded into x64dbg we can see our function

Right before we execute the instruction mov al,byte ptr ds:[rax+BC] we can see again that a pointer to the PEB is in the RAX.

After that instruction is executed we can see that the al register changed which is the lowest byte of the RAX register it is now 0x70 why?

This is because when a process is created by a debugger three flags will be set:

FLG_HEAP_ENABLE_TAIL_CHECK = 0x10
FLG_HEAP_ENABLE_FREE_CHECK = 0x20
FLG_HEAP_VALIDATE_PARAMETERS = 0x40

It’s a good idea to check against these flags explicitly because just checking if NtGlobalFlag is not 0 shouldn’t mean there is a debugger running. In short we should only check for a combination of ALL of these flags 0x70 to prevent false positives.

Once that value is saved into the al register we do a bitwise AND on 0x70 and al, then we compare al and 0x70 to check if the combination of flags are set. We can see that after we execute cmp al, 0x70 the Zero flag (ZF) gets set (if the result of an operation is zero the Zero flag gets set to 1) this means that the value of NtGlobalFlag, was equal to 0x70. that most likely means this process was created by a debugger (we know it was).

I hate Being (De)bugged!!

The good ol’ BeingDebugged if the last technique was too much for you, this is one of the most trivial Anti-Debugging techniques out there. The BeingDebugged member of the PEB is used to check if the current process is being debugged or not. We can be see it in WinDbg using two commands r $peb -> dt [address] ntdll!_peb

We can see that it’s located at offset 0x02 and the value is set to 0x1 (true). With this information we can write a function to do this for us.

I’m going to stick to ASM because I think it’s good practice, we know we must do two things:

Get a pointer to the PEB
Get the BeingDebugged value

    ... snip ...

    mov rax, gs:[0x60]  // You should know this by now
    mov al, [rax+0x02]  // Grabbing the BeingDebugged value
    and rax, 0x000000FF // Clearing out everything except for al
   
    ... snip ...

Back to x64dbg! Again right after we execute the instruction mov rax,qword ptr gs:[60] we can see that a pointer to the PEB is in the RAX. If we right click on this address in RAX and select “Follow in Dump” we can see there’s an 0x1 two bytes in

Stepping two more times does the following:

Moves the BeingDebugged value to the al register
Clears the remaning bits except the lowest 8
After these steps RAX should contain 0000000000000001

Remarks

Those were two ways malware may detect if it’s being debugged there are numerous ways to do so. If you’re doing malware analysis It should also be known that these two methods can easily be bypassed by simply changing the values to 0 in memory before they are accessed, like so.

Click “Ok” and the value will change

The BeingDebugged value was changed to 0x0 (false)

References

aldeid.com - NtGlobalFlag

mahaloz - NtGlobalFlag bypass

msdn - heap-parameter-checking

msdn - heap-free-checking

msdn - heap-tail-checking

checkpoint research <3 - NtGlobalFlag

geoffchappell - peb

malgamy - Anti-debugging 0x03

https://github.com/codeneverdies/ws-loader/blob/main/asm/init.asm#L23 ↩
https://github.com/codeneverdies/ws-loader/blob/main/asm/init.asm#L36 ↩

Land Of The PEB: Modules and DLLs

Wed, 26 Mar 2025 00:00:00 +0000

Welcome to my first series called “Land Of The PEB” where I will be discussing various topics related to the Process Environment Block (PEB).

What is this thing?

The Process Environment Block (we will refer to as PEB) is a data structure in the Windows NT operating system that holds lots of useful information about the current process like..

Debug Flags
Process start command line arguments
Pointer to the process’s heap
The base address of the current process.
List of loaded modules (DLLs)

How can I use it?

In this post we will be focusing on the member that relates to loaded modules i.e, PEB_LDR_DATA and we will be using this structure to write our own version of GetModuleHandle. To accomplish this we must do the following..

Get a pointer to the PEB
Get a pointer to PEB_LDR_DATA
Get a pointer to the InMemoryOrderModuleList

Once we get to this list in memory we can loop through this list and compare each module name with the one we want for example we will do “ntdll.dll” this could be useful if you don’t want GetModuleHandle in your Import Address Table.

To the land of the PEB!

It must be known that the PEB is actually located inside of the Thread Environment Block (TEB) at offset 0x60 on 64-bit systems and 0x30 on 32-bit systems. There are two ways I know of getting a pointer to the PEB they both access the TEB located in the gs segment register. The first is very useful if you don’t wan’t to write assembly.

//64-bit systems
PPEB peb = (PPEB)__readgsqword(0x60);

These are intrinsic functions that do something close to this.. ¹

    push rdi
    mov rdi, rsp
    sub rsp, 0x20
        
    xor rax, rax
    mov rax, gs:[0x60]

    mov rsp, rdi
    pop rdi
    ret

Now that we have a pointer to the PEB lets look for our module, we can start with getting a pointer to PPEB_LDR_DATA ²

PPEB_LDR_DATA ldr = peb->Ldr;

Once we have both of those pointers we can get our last needed pointer which is to the InMemoryOrderModuleList. This points to the first entry in the list, each entry is of type LIST_ENTRY which means each entry has a forward link pointing to the next module in the list. For each entry we will compare it’s name with “ntdll.dll” if the names match we have found ntdll.dll and we grab the base address. ³


entry = &ldr->InMemoryOrderModuleList;
next_entry = entry->Flink;

for ( LIST_ENTRY *e = next_entry; e != entry; e = e->Flink ) {

    data_tbl = (LDR_DATA_TABLE_ENTRY *)((BYTE *)e - sizeof(LIST_ENTRY));

    if ( wcscmp(data_tbl->BaseDllName.pBuffer, "ntdll.dll") == 0 ) {
        mod = (HMODULE)(data_tbl->DllBase);
        break;
    }
}

https://github.com/codeneverdies/ws-loader/blob/main/asm/init.asm#L23 ↩
https://github.com/codeneverdies/ws-loader/blob/main/src/util.c#L48 ↩
https://github.com/codeneverdies/ws-loader/blob/main/src/util.c#L50 ↩