Foxhole Internal + extras
In case my old partner reads this, no I did not copy paste your project. No I did not steal your code. I only added what I could figure out myself.
For the last 1.5 months I’ve been working every single day on learning Foxhole cheat making and slowly converted over to C from C++. I originally had a partner last year who created an internal cheat I used which I thought was incredibly nice. It did things I never thought possible which since have been patched by the developers unfortunately.
This write up will be honest of my experience thus far attempting to 100% solo a game I previously had zero experience with on a coding side. Previously when my partner was making the cheat I was too inept with UE4 Internals to really get it or do it myself. I have worked round the clock this year to change that.
Initial Versions - The uphill struggle
During the first 4 weeks of development I wrote 2 separate internal cheats for foxhole trying to optimize my code’s speed per cycle while having an easy to use base. Version 1 failed because it was too slow and version 2 failed because it was unstable and too slow. I ran into the issue of not knowing what things in the game were needed to achieve features while also learning a hard lesson that I’ve never experienced as a primarily external cheat developer: The context of the class instance matters more than you can imagine when calling functions or directly writing memory. I learned everything here by trial and error over 4 weeks. I’ve debugged just about every problem you could have when writing internal ESP with both engine rendering off unreal engine and external libraries. I’ll sum it up as one of the best learning experiences I’ve had this year combined with the most frustrations I’ve had this year. I want to add that I blasted through 4 rendering overlay ideas before landing on one that I liked so this also took time.
I manually reverse engineered post render after 1 week of studying methods to do so along with making a working VMT hooking class combined from several online resources. I won’t pretend to have “invented VMT hooking” or something like that as pretty much all publicly known methods are the only ways. Majority of hooking is boilerplate code, it’s just a matter of knowing when or where to use it. I have found that majority of VMT information on unknowncheats.me is full of shit and github was better for getting a full understanding of exactly what VMT shadow hooking was doing behind the scenes along with direct pointer swaps on regular VMT hooks. The next best thing was just sitting down and trial / erroring every single type of hooking I found in every combination of settings to determine which one followed the way I expected it to work the best without causing instability or stack corruption.
Process Event Hook took me a lot longer than post render to hook because I was finding conflicting information on if it was truly virtual or just a regular function. I believe it’s game dependent in the end. Foxhole happens to be a real function that can be directly hooked. I chose detour hooks because it’s the easiest version to use as a beginner. I have a large struggle reversing process event manually because the UE version of foxhole is using a proxy scripting engine tacked onto itself overtop process event which is proxied on all functions. I won’t lie and say I 100% figured it out but I was able to get some tools which give me the index and address of process event every update. Outside of jumping into x64 dbg or ollydbg and checking the sig, I’m not 100% sure how the sig was made to start with due to the heavy abstraction of the game engine. Realistically I’ve only used this hook for 2 things and neither of them are 100% required for the cheat to work but they are very very nice to have.
At some point around here I thought maybe the SDK I was dumping with a free dumper was fucked up so I bought cheat-gear and tried that only to realize it was my file explorer that was glitched between PC restarts not showing a file I thought I was missing with the free dumper. $25 + 2 days down the shitter to learn a tool I didn’t need. At least I have 2 ways to get a foxhole SDK.
Lets just say the 3rd version appeared to be the charm and seemed stable. I wrote an entire wrapper library to convert between Unreal Engine 4 Kismet drawing with UCanvas -> IMUGI -> Windows API so I could easily transfer data from anywhere in my code straight into the UE4 draw text functions and the like. I spent over 5 days 16 hours+ a day making a new base with a new design that is original to myself. I improved the frames per second efficiency of my code and had literally all ESP written with my UE4 kismet UCanvas wrapper. GAME FUCKING UDPATES 2X overnight and what do you think happens on test day of my cheat?! They no longer exposed kismet drawing in prod client…. After some further testing and a few changes to my development plans I believe I know how that happened. Lets just say they’re in the walls and you’re not crazy. So a few weeks of work just got tossed out the window and I still have instability issues… Next section will explain how I fixed this.
Ghost fueled sleepless nights followed by stress release
4th base was written in under 4 days using another new design created by me following ANSI C88 standards combined with C++ 23. I had many talks with friends about quick code vs clean code vs abstracted code vs just make the fucking thing already idiot. Turns out I was massively overthinking most of my code and getting way too sucked into modern stacks. It’s just better to write in native C as much possible with native C++ supporting it. I was able to get my code with an internally rendered overlay to run in sync with the game without rendering in Post Render or any game context. I was able to keep my 2 hooks with the ability to unhook and reinject as much as I want. The ESP code for my overlay was time consuming to port over from kismet but in the end it’s much faster while having no instability issues. I have only run into a single issue related to font of certain Russian names 1 time which I will patch shortly. I can run at 144 or 60 fps no interruptions to my cheat although for my particular PC to run the game 100% stable I prefer 60 so there is no drops. I learned that majority of c++ std functions are dogshit and you need to just use native C to create your own workarounds to maintain fast code.
The crashing issues I had originally faced were due to 3 things which are all 100% fixed in Version 4:
slow shit-code on my end fucking up the frame sync of the game & expected results of internal code on the engine.
improper hooking
Invalid thread context from which I called functions or interacted with certain pointers
Personally the only reason I even use C++ at this point instead of raw C is that making DLLs for windows is much easier on C++ combined with me being a class and namespace enjoyer. My next cheat will 100% be in C88 primarily with probably only the rendering solution being C++ because for somebody at my stage of coding knowledge I don’t feel like it’s feasible to re-invent direct X.
I probably sound like a lunatic skipping all over but this write up is after several ops in Foxhole and days of grinding for our base mixed in with insanely long development hours. I totally obsessed this project until I had figured out how and why everything worked along with getting a very nice demo of it.
TLDR; Drink ghost energy drinks and code in ANSI C88 to win.
Closing Statements
Stay away from the “learning X ezpz” gimmick garbage. Just stick to reference manuals or strictly “this is the thing, it works like this” books.
The following books helped me figured out all my problems and without them idk if would have been possible. My rendering on V4 is designed like a queue system and avoids mutexes and conditional_variables but still works flawlessly. I figured it out after reading C++ Concurrency in Action for a few days.
