How to create a Remote Execution

Okay, so we know that BattlEye filters are the real bane of remote execution. Obviously sending our entire cheat through the filters just sounds like a bad idea. The server owner would have every single variable, and code snippet, of our entire cheat, and know for a fact it’s us! As well, every time we remote execute, it’ll create a new log! Spamming the filter log file is the quickest way to get banned from a server. So the next step in learning how to remotely execute is learning how to avoid detection.

Like I said before, you will likely never create a remote execution that isn’t logged in some way. The goal here is to reduce the total amount of code flagged by the BattlEye filters. This is where the term “Pro RE” came from. A professional remote execution is only different in that it protects the code that is being executed from logging to the server’s remote execution filters.

A Pro RE is split into ~3 main parts: The Remote Execution, The Installer, and the Executor.
The Remote Execution we discussed. This is the exploit that gets our code from our machine onto a remote machine.
The Installer’s job is to use the remote execution to install an alternative form of remote communication, ideally onto the server.
The Executor uses this new remote communication channel to pass our desired payload onto the destination and run it.

What is an alternative form of remote communication I hear you ask? Looking back at locality, we learn that some functionality has global arguments and global effects. Our goal here is to abuse these global functions to create a new way to pass data from my client to another. The simplest way for me to explain this is with an example.

In this example, I left out the remote execution part as an exercise to the reader. Here we are using map markers as an alternative communication channel. This is by far my favorite as it’s really easy to do and leaves no trace in BattlEye logs. The code flow actually starts at the bottom with Executor on line 40. First, we see if we already ran the installer, and if not, we run Installer. The installer method executes a payload on all clients. Let’s look closely at this payload on line 17. First, we make sure our client knows the payload was installed. Next, we make sure only the server spins up a communication channel. This channel reads the value from our marker and waits for it to be non-blank. Once it is non-blank, we compile its value and execute it on all clients. Resetting its value back to blank. Anyway, back to the Executor method, once we’ve installed this communication channel, we simply format our code and put it into the marker text. The server handles the rest.

The flow of this is the following:
Execution #1: Executor->Installer->Create Marker->Remote Execute ( install payload on server)->Set Marker Text->( back to server)Read marker text-> Execute value on all machines
All subsequent calls: Executor->SetMarkerText->(Server)Read Marker Text->Execute Value on All Machines

So, our Remote Execution and the Installer are the only two features that are logged. Any script functionality we execute will not be logged. Letting us keep the majority of our SQF undetected for much longer.

There are other ways of establishing a communication channel, this is my favorite, though it is somewhat easier to detect, you can get fancy with it. You’ll often see the payload in string format, with some string function that compiles and executes it. This is because a lot of the functionality in my example would actually get flagged by remote execution BattlEye filters. The key to a good RE is a great exploit and a terrific installer payload. The better the payload, the less likely it is to get noticed in the log files.

I hope this post clarified a few questions about remote execution. It is a topic that takes some trial and error, and I am sorry I can’t really contribute more examples. At a certain point, I would have to create my own remote executions to further explain in detail how they operate. Definitely take a look at old leaked cheats and their remote executions. Now that you understand the concept of how a Pro RE works, they should make a lot more sense to you.

Pages: 1 2 3