One of the least discussed issues with the Arma 3 Engine, Real Virtuality 4, is the Engine & the Developer’s inability to protect game servers from its own scripting language.
For the last 3+ years, I have been abusing the scripting language & its intricacies to execute SQF code wherever and whenever I want. For many SQF developers, the idea of abusing the implementation of this language can only reach so far. However, once you really dive into the possibilities and flaws in the SQF implementation, you can find some really crazy stuff. We’ve seen things like Server Transfering by KillZoneKid, to the last code execution exploit I posted on November 4th, 2016, nearly 3 years ago. None of these exploits really dove into anything inherently wrong with how the Engine operates. Server Transfer works due to when the game decides to “kill” the OnEachFrame thread. The UI execution exploit was a simple mistake made by the SQF developers for Arma 3.
Let’s first start with a quick refresher on the UI execution exploit. This worked by exploiting how the game saved custom colors for the UI frames. When you inserted code into the color section within your profile namespace, it would execute the code when you opened the game options menu. There are still a few more exploits like this, and I may cover them in the future, but they all have one thing in common: The end-user has to click on a few buttons or take a few actions to trigger code execution. This means, anyone with knowledge of these exploits, can prevent the user from taking those actions or clicking those buttons. As well, anticheat developers can block & ban for some of these exploits. These style of exploits are very powerful, it lets cheaters cheat without being BattlEye banned, but they are not “unblockable”, there is always a way to disable a user from executing their code.
But, why do the UI style exploits require a user-action? When a user loads into a server, the game terminates all SQF threads & removes all event handlers. This prevents any code from the main menu or a previous multiplayer session from interacting with the new session. I call this the SQF Firewall. Any code you have running will always stop at this intersection.
If we can break through the SQF Firewall, there is a lot of unique advantages we would have. We could effectively build a way of execution SQF cheats without BattlEye or the server-based anticheat from ever knowing. On the next page, I’ll describe the code that allows us to break this firewall & explain how it works.