Вопрос Injecting DLL into EAC-protected process (Arc Raiders) from Kernel Driver

[Un1xCr3w]

Hey guys , iam trying to be inject a DLL into EAC-protected process (ARC RAIDERS) from Kernel Driver

but i keep getting BSODs and failures everytime i try something

Here is what I tried



### Test 1: Manual Map + InstrumentationCallback + Free VAD after DllMain
- **Method**: Manually map DLL (resolve imports, relocations, etc.), use IC to call DllMain, then free the entire allocation after DllMain returns
- **Allocation**: Section-based (ZwCreateSection PAGE_READWRITE + ZwMapViewOfSection → MEM_MAPPED VAD)
- **Execution**: NX bits cleared via PTE manipulation from kernel, IC set via ZwSetInformationProcess
- **DLL**: No-op test DLL (DllMain returns TRUE, does nothing else)
- **Result**: SURVIVED — **Survived 5 minutes** (only test that survived)
- **Note**: The memory was freed immediately after DllMain — there was no persistent allocation. This is the only configuration that didn't get detected.

### Test 2: Manual Map + InstrumentationCallback (persistent allocation)
- **Method**: Same as Test 1, but memory stays allocated after DllMain (normal injection — DLL stays loaded)
- **Allocation**: Section-based (MEM_MAPPED, PAGE_READWRITE VAD)
- **Execution**: NX cleared via PTE manipulation from kernel
- **Result**: DETECTED — **Game closes within seconds**
- **Analysis**: EAC detects the persistent MEM_MAPPED region with execute capability. Even though VAD says READWRITE and it's section-backed, EAC likely walks PTEs or probes execution.

### Test 3: Manual Map + IC + VAD Protection Spoof
- **Method**: After mapping, spoof the VAD flags to look like PAGE_READONLY
- **Allocation**: Section-based, then modify MMVAD.Flags to change protection bits
- **Result**: DETECTED — **Still detected, game closes**
- **Analysis**: EAC doesn't rely solely on VAD protection flags.

### Test 4: Manual Map + IC + VAD Unlinking
- **Method**: Unlink the MMVAD node from the AVL tree entirely (remove our allocation from the VAD list)
- **Result**: FAILED — **BSOD**
- **Analysis**: Unlinking VAD nodes causes crashes on process teardown or when the memory manager walks the tree.

### Test 5: Manual Map + IC + Physical Page Remapping
- **Method**: After mapping, remap the physical pages backing the allocation to different physical pages, effectively hiding the content
- **Result**: DETECTED — **Still detected**
- **Analysis**: EAC likely detects the allocation itself (VAD entry exists), not just the content.

### Test 6: Private memory allocation (VirtualAllocEx-style)
- **Method**: Allocate with MEM_COMMIT | MEM_RESERVE instead of section-based
- **Result**: DETECTED — **Detected faster than section-based**
- **Analysis**: Private (MEM_PRIVATE) allocations with execute permissions are even more suspicious to EAC.

### Test 7: Section-based + NX-clear only (no execute in VAD)
- **Method**: Allocate section with PAGE_READWRITE only (no execute permission anywhere in VAD or section object). Clear NX bit in PTEs from kernel to allow execution.
- **Allocation**: ZwCreateSection(PAGE_READWRITE) + ZwMapViewOfSection
- **Result**: DETECTED — **Game still closes instantly**
- **Analysis**: We confirmed NX was cleared and code executed (DllMain returned 1). EAC must be detecting the VAD itself — ANY new VAD with unusual characteristics seems to trigger detection.

### Test 8: LdrLoadDll Hook (ntdll code patching)
- **Method**: Completely different approach. Instead of manual mapping:
1. Allocate small 2-page buffer for hook context + PIC shellcode
2. Save first 12 bytes of ntdll!LdrLoadDll
3. Write 12-byte trampoline (`mov rax, <pic>; jmp rax`) over LdrLoadDll
4. PIC unhooks LdrLoadDll (restores bytes), forward original call, then calls LdrLoadDll for our DLL
5. Windows loader loads our DLL normally (file-backed section, module list entry)
6. Free the hook buffer after completion
- **Trampoline install**: Via kernel — ZwProtectVirtualMemory(PAGE_EXECUTE_READWRITE) to trigger COW, then MmCopyVirtualMemory to write 12 bytes, then restore protection
- **Result**: DETECTED — **Game crashes within ~2 seconds, then BSOD on cleanup**
- **Analysis**: EAC checksums ntdll code pages. The 12-byte trampoline was sitting on LdrLoadDll for the entire time we waited for the game to naturally call LoadLibrary. EAC detected the code modification and killed the process. BSOD was secondary — caused by cleanup running on a dead process.



here is what i asked the ai about the EAC detection
Based on the test matrix, here's what I can infer:

1. **ANY persistent VAD with execute capability** -- Even if VAD says READWRITE, even if it's section-backed (MEM_MAPPED), even if execute comes only from PTE-level NX clearing from kernel. The only surviving test was one where the VAD was **freed immediately** after DllMain.

2. **ntdll code integrity** -- Modifying even 12 bytes of LdrLoadDll was detected within seconds (Test 8).

3. **VAD manipulation** -- Spoofing VAD flags or unlinking VAD nodes doesn't help (Tests 3, 4).

4. **Physical page remapping** -- Doesn't bypass detection if the VAD still exists (Test 5).



please take in mind that the account i was trying the injection with got banned without even try any cheat on it i just got ban because i was try the injection methods on it , so lets say the detected things got my account banned


Any insights on what detection vector is getting us and how to evade it would be appreciated.



if u wanna suggest any articles or posts related to this and will solve my problems please share them here with me


last thing to state here that i dont need code i just need to understand to create my own

Thanks a lot, guys <3

 

[Fals3R]

all these tricks were prob ud back in like 16-17. no luck in 26.

mapping random unsigned memory into the game is a huge red flag for AC. even if you hide it like nx. do not forget about stackwalk & NMI. same with patching known modules.

also do not forget about your ring0 part, even if you properly did the injection you still has your kernel worker that did it for you, AC also care about it.

 

[Un1xCr3w]

so there is no way to get it work ?

some people has injectors but i dont like to use them cuz they might not be safe so iam trying to create my own do u think i will be able to ?

 

[Fals3R]

i can tell you have no idea what you are doing & recommend to investigate more about windows internals, anticheats and reverse engineering

the easiest way for you that won't need a deep knowledge is to buy EV cert, create simple I/O bridge and move to external instead of what you're trying to do.

as long as you the only person that exploiting it you will prob stay ud for long

 

[morphe-ya]

Hey guys , iam trying to be inject a DLL into EAC-protected process (ARC RAIDERS) from Kernel Driver

but i keep getting BSODs and failures everytime i try something

Here is what I tried



### Test 1: Manual Map + InstrumentationCallback + Free VAD after DllMain
- **Method**: Manually map DLL (resolve imports, relocations, etc.), use IC to call DllMain, then free the entire allocation after DllMain returns
- **Allocation**: Section-based (ZwCreateSection PAGE_READWRITE + ZwMapViewOfSection → MEM_MAPPED VAD)
- **Execution**: NX bits cleared via PTE manipulation from kernel, IC set via ZwSetInformationProcess
- **DLL**: No-op test DLL (DllMain returns TRUE, does nothing else)
- **Result**: SURVIVED — **Survived 5 minutes** (only test that survived)
- **Note**: The memory was freed immediately after DllMain — there was no persistent allocation. This is the only configuration that didn't get detected.

### Test 2: Manual Map + InstrumentationCallback (persistent allocation)
- **Method**: Same as Test 1, but memory stays allocated after DllMain (normal injection — DLL stays loaded)
- **Allocation**: Section-based (MEM_MAPPED, PAGE_READWRITE VAD)
- **Execution**: NX cleared via PTE manipulation from kernel
- **Result**: DETECTED — **Game closes within seconds**
- **Analysis**: EAC detects the persistent MEM_MAPPED region with execute capability. Even though VAD says READWRITE and it's section-backed, EAC likely walks PTEs or probes execution.

### Test 3: Manual Map + IC + VAD Protection Spoof
- **Method**: After mapping, spoof the VAD flags to look like PAGE_READONLY
- **Allocation**: Section-based, then modify MMVAD.Flags to change protection bits
- **Result**: DETECTED — **Still detected, game closes**
- **Analysis**: EAC doesn't rely solely on VAD protection flags.

### Test 4: Manual Map + IC + VAD Unlinking
- **Method**: Unlink the MMVAD node from the AVL tree entirely (remove our allocation from the VAD list)
- **Result**: FAILED — **BSOD**
- **Analysis**: Unlinking VAD nodes causes crashes on process teardown or when the memory manager walks the tree.

### Test 5: Manual Map + IC + Physical Page Remapping
- **Method**: After mapping, remap the physical pages backing the allocation to different physical pages, effectively hiding the content
- **Result**: DETECTED — **Still detected**
- **Analysis**: EAC likely detects the allocation itself (VAD entry exists), not just the content.

### Test 6: Private memory allocation (VirtualAllocEx-style)
- **Method**: Allocate with MEM_COMMIT | MEM_RESERVE instead of section-based
- **Result**: DETECTED — **Detected faster than section-based**
- **Analysis**: Private (MEM_PRIVATE) allocations with execute permissions are even more suspicious to EAC.

### Test 7: Section-based + NX-clear only (no execute in VAD)
- **Method**: Allocate section with PAGE_READWRITE only (no execute permission anywhere in VAD or section object). Clear NX bit in PTEs from kernel to allow execution.
- **Allocation**: ZwCreateSection(PAGE_READWRITE) + ZwMapViewOfSection
- **Result**: DETECTED — **Game still closes instantly**
- **Analysis**: We confirmed NX was cleared and code executed (DllMain returned 1). EAC must be detecting the VAD itself — ANY new VAD with unusual characteristics seems to trigger detection.

### Test 8: LdrLoadDll Hook (ntdll code patching)
- **Method**: Completely different approach. Instead of manual mapping:
1. Allocate small 2-page buffer for hook context + PIC shellcode
2. Save first 12 bytes of ntdll!LdrLoadDll
3. Write 12-byte trampoline (`mov rax, <pic>; jmp rax`) over LdrLoadDll
4. PIC unhooks LdrLoadDll (restores bytes), forward original call, then calls LdrLoadDll for our DLL
5. Windows loader loads our DLL normally (file-backed section, module list entry)
6. Free the hook buffer after completion
- **Trampoline install**: Via kernel — ZwProtectVirtualMemory(PAGE_EXECUTE_READWRITE) to trigger COW, then MmCopyVirtualMemory to write 12 bytes, then restore protection
- **Result**: DETECTED — **Game crashes within ~2 seconds, then BSOD on cleanup**
- **Analysis**: EAC checksums ntdll code pages. The 12-byte trampoline was sitting on LdrLoadDll for the entire time we waited for the game to naturally call LoadLibrary. EAC detected the code modification and killed the process. BSOD was secondary — caused by cleanup running on a dead process.



here is what i asked the ai about the EAC detection
Based on the test matrix, here's what I can infer:

1. **ANY persistent VAD with execute capability** -- Even if VAD says READWRITE, even if it's section-backed (MEM_MAPPED), even if execute comes only from PTE-level NX clearing from kernel. The only surviving test was one where the VAD was **freed immediately** after DllMain.

2. **ntdll code integrity** -- Modifying even 12 bytes of LdrLoadDll was detected within seconds (Test 8).

3. **VAD manipulation** -- Spoofing VAD flags or unlinking VAD nodes doesn't help (Tests 3, 4).

4. **Physical page remapping** -- Doesn't bypass detection if the VAD still exists (Test 5).



please take in mind that the account i was trying the injection with got banned without even try any cheat on it i just got ban because i was try the injection methods on it , so lets say the detected things got my account banned


Any insights on what detection vector is getting us and how to evade it would be appreciated.



if u wanna suggest any articles or posts related to this and will solve my problems please share them here with me


last thing to state here that i dont need code i just need to understand to create my own

Thanks a lot, guys <3

the easiest way to make an undetected hack is hypervisor with NPT/EPT hook. you can just decline EasyAntiCheat packets which contains info about detections. you can easily identify report functions. eac uses PRNG which based on KUSER_SHARED_DATA information

 

[Un1xCr3w]

i can tell you have no idea what you are doing & recommend to investigate more about windows internals, anticheats and reverse engineering

the easiest way for you that won't need a deep knowledge is to buy EV cert, create simple I/O bridge and move to external instead of what you're trying to do.

as long as you the only person that exploiting it you will try to stay ud for long

thanks

the easiest way to make an undetected hack is hypervisor with NPT/EPT hook. you can just decline EasyAntiCheat packets which contains info about detections. you can easily identify report functions. eac uses PRNG which based on KUSER_SHARED_DATA information

thanks a lot mate i will try that i didnt really know that u can do that but with this data in mind i will try to debug it and will let u know if i have any results but thank you so freaking much dude <3

 

[brobrosti]

the easiest way to make an undetected hack is hypervisor with NPT/EPT hook. you can just decline EasyAntiCheat packets which contains info about detections. you can easily identify report functions. eac uses PRNG which based on KUSER_SHARED_DATA information

бросая пакет, что, очевидно, вызывает таймаут пульса. Я подключаюсь к генерации телеметрии до того, как PRNG вычисляет MAC, удаляю флаги обнаружения из полезной нагрузки и позволяю AC зашифровать и отправить поддельный «чистый» пакет с действительным номером последовательности.

 

[Un1xCr3w]

dropping the packet, which obviously causes a heartbeat timeout. I connect to the telemetry generation before the PRNG calculates the MAC, remove the detection flags from the payload, and let the AC encrypt and send a fake "clean" packet with a valid sequence number.

lol ok thats also nice :D
will combine it with the previous suggestion too :D