[RELEASE]CCHook:Reloaded - Open Source Enemy Territory Cheat


New member
Today I released a small project I worked on in the past few weekends and vacations.
It is a client hook that is mod independent, currently works on 2.60b and Legacy (2.79.0).

You can find the github link here: GitHub - Ch40zz/CCHookReloaded: A modern, mod independent open source cheat for Enemy Territory
Latest compiled release: Download

Don't forget to copy cch.pk3 into the etmain folder. You should also rename the file and adapt the name in config.h


# CCHook:Reloaded - A highly customizable and open source Enemy Territory cheat

## General
This cheat is the result of a previous Proof-of-Concept made to showcase an alternative way to hook the Quake VM system in an undetected way.
The rest of the cheat then followed the same rules to stay undetected, without compromising the ease of use of engine functions.
This is the only cheat I know of that does not patch any read-only memory or leaves any other nasty detections such as spawned threads or incorrectly implemented hooks.

## Hooking
The cheat utilizes the LdrRegisterDllNotification() API to gain code execution on every DLL load/unload without the need to create any threads.
Because every mod will load their own new copy of cgame_mp_x86.dll we will always have the perfect timing to place our hooks right after the mod loaded.
From there, we hook the exported render routines of the refexport_t struct.
This hook can be removed after a few frames if required but currently stays in tact to detect key presses in the main menu when no mod is loaded yet.
The renderer functions that get hooked are refexport_t::Shutdown(), refexport_t::EndRegistration() and refexport_t::EndFrame().
Now that we are in the correct thread, we can finally hook the function we will use for rendering and logic: vmMain().
This is done by finding the pointer to the cgvm and swapping out its entryPoint address with our hook:

  1. vm_t *_cgvm = off::cur.cgvm();
  2. if (_cgvm)
  3. {
  4. vmMain_t vmMain = _cgvm->entryPoint;
  5. if (vmMain && vmMain != hooked_vmMain)
  6. {
  7. orig_vmMain = vmMain;
  8. _cgvm->entryPoint = hooked_vmMain;
  9. }
  10. }
This alone would be relatively easy to detect for an anti-cheat.
Thats why we have another trick up our sleeves: All anti-cheats in this game are implemented in the mod's cgame_mp_x86.dll.
This means that they can only execute code, when their vmMain gets invoked by the engine.
To mask our vmMain hook, we simply spoof the return address and temporarily remove all our hooks until the mod is done running and passes execution back to our cheat.
To also easily hook the syscalls made by the mod back into the engine, we have yet another trick: we locate the currentVM pointer, duplicate the whole VM object and replace its systemCall address with our own.
This hook however, needs to stay when we call into the original vmMain. To make it undetected, we simply swap the currentVM pointer with our copy.
This way an anticheat will think it has the correct systemCall address, while the engine internally will still end up calling our hook:

  1. intptr_t __cdecl hooked_vmMain(intptr_t id, intptr_t a1, intptr_t a2, ...)
  2. {
  3. // Hook syscall func by replacing currentVM
  4. vm_t *curVM = off::cur.currentVM();
  5. memcpy(&hookVM, (void*)curVM, sizeof(hookVM));
  6. orig_CL_CgameSystemCalls = hookVM.systemCall;
  7. hookVM.systemCall = hooked_CL_CgameSystemCalls;
  8. off::cur.currentVM() = &hookVM;
  9. auto VmMainCall = & -> intptr_t {
  10. // Restore vmMain original temporarily
  11. vm_t *_cgvm = off::cur.cgvm();
  12. _cgvm->entryPoint = orig_vmMain;
  13. // Spoof the return address when calling "orig_vmMain" to make sure ACs don't easily detect our hook (e.g. as ETPro does).
  14. // NOTE: This is not supported for ET:Legacy but support can be added if required.
  15. intptr_t result = SpoofCall12(off::cur.VM_Call_vmMain(), (uintptr_t)orig_vmMain, _id, _a1, _a2, ...);
  16. // Rehook vmMain
  17. _cgvm->entryPoint = hooked_vmMain;
  18. // Restore currentVM
  19. off::cur.currentVM() = curVM;
  20. return result;
  21. };
  22. intptr_t result = VmMainCall(id, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11, a12);
  23. ...
  24. return result;
  25. }
We now have access to every vmMain call (engine -> mod) and every systemCall (mod -> engine), giving us full control over all in- and output of the mod.

## Hardware/GUID Spoofing

The game itself has no real knowledge about the underlying hardware IDs.
The only way to track a player without additional code is to look at their etkey that is sent to the server on connect.
These keys can be manually generated by anyone at any time and therefore do not uniquely identify a player.
To implement player tracking, mods resort to reading the Hardware-ID of the system.
This is done by querying disk drive serials or the MAC address(es) of the network cards.
To implement a hookless Hardware-ID/GUID spoofing, the cheat directly accesses the sent packet queue clc.reliableCommands.
This requires reverse engineering of the specific mods and is generally inferior to placing simple hooks.
If you wish to generically bypass any HWID tracking, you should therefore resort to simple hooking of the APIs in question.

## Screenshot (PBSS) cleaning

The game is driven by the OpenGL renderer.
Screenshots are therefore also taken with OpenGL.
To read the current displayed pixels, one can call opengl32!glReadPixels().
Luckily, this function is pretty easy to hook by swapping a .data pointer on Windows.
OpenGL on Windows is allocating a big API dispatch table and storing the pointer to tht table via TLS (thread local storage).
The cheat extracts this table address by disassembling the instructions at glReadPixels.
After receiving the dispatch table address, we can easily swap out any function with our hook.
The hook then proceeds to set a global boolean value, indicating that all rendering should be disabled.
To update the screen data, the engine function SCR_UpdateScreen() is executed.
After the screen has been cleared, the original glReadPixels can be invoked to gather the cleaned screen data.
This whole process usually takes no more than a few milliseconds.

## Gathering entity data

Most cheats rely on reversing each individual mod to find the address of the cg_entities array.
This is however not needed. Entity data is transmitted to the client each server tick and is received by the mod using the CG_GETSNAPSHOT syscall.
Since we can intercept all syscalls done by the mod, we can just wait for the mod to request the data and then copy it off.
This makes it even possible to modify the data the mod will receive, allowing us to modify or even delete events sent from the server.

## Unlocking unpure PAK files

Other cheats implementd this feature by hooking FS_PureServerSetLoadedPaks().
This is however not really needed. One can simply walk all loaded PAKs in fs_searchpaths.
Find the PAK file you want to unlock. To please the server, spoof the checksum and pure_checksum fields with the values from any legit pak file such as pak0.
Now that we use the same hash as pak0, we do not want to send the hash multiple times to the server (since it was already sent).
To do this, we simply set the pak's referenced count to 0.
Now the client will be able to use the unpure pak file without the server even knowing about its existence.

## Possible improvements

The biggest improvement right now would be creating weapon and event lists for each supported mod and fall back to the default ET implementation only if the mod is unknown.
As it currently stands, many mods have additional and/or removed weapons, which leads to some code not working correctly on some mods.
This however is pretty trivial and might be done soon.
Another simple improvement would be the injector. The injector is currently using LdrLoadDll() to inject the dll.
It is therefore easily visible in the Ldr module list. This code should probably be swapped out with a manual mapping implementation.
However, right now no mod detects the cheat even using LdrLoadDll().
Another already mentioned improvement wouldd be adding a more generic HWID spoofing by directly hooking the Windows APIs in question.
This hasn't be done yet because the goal of this cheat was to not modify any read-only data.
Lastly, the aimbot prediction is really just rudimentary and should be replaced with some more advanced techniques.
One big improvement would be the use of backtracking as it is done nowadays for quake (source) based such as Counter-Strike.


New member
all this looks hq
i would like to try to port the chams to cod1, i guess it would be possible since it uses opengl too...
ftr i'm only interested about chams for when player is visible, and i don't think i would use it in matches, but i would like to see how it looks

the chams i saw in cod1 were always kinda ugly (sorry coders), i heard it's because it's more difficult that when using directx