So, how do people cheat in UT, and how do you stop them?

[Rajada]

I know this is a touchy subject, but I was wondering if anyone here might know of an ethical place where I could read about some of the in-engine / in-game methods that cheaters and hackers use in UT99 or Unreal multiplayer servers. Something for example, used to help admins spot cheaters. I'm the main developer for another Unreal engine game (Nerf ArenaBlast, you might have heard of it), and I'm looking to kill some of the more abused exploits and cheats. We already managed to block translucent texture wallhacking (not that it is a viable solution for UT, as we're working with our own source code).

My theory is, that with the source I have, I can block some of the cheats that are just oversights on the developer's parts, but I'd need to learn a little bit about them. I already know there's a lot you can do with hotkeys and the "set" command, and I've personally experienced someone executing a server takedown on me (though I don't know the specifics) via some code / special characters executed through chat. These are examples of the main issues I'd like to eliminate in NAB. I'm not looking for any secrets to specific UT anti-cheat methods, but just some general red flags I can investigate, and look into closing the more worrisome backdoors.

And before you ask, no, I don't even play UT online.

[gopostal]

Raj, you won't find an easily browsed archive of hack methods, Instead you'll find the proverbial rabbit hole of affiliated sites where cheating is discussed but quite often methodology is held close to the vest by the people posting the cheats. It's in their best interest for you NOT to know quite everything since the more people who use a particular method has a direct effect on admins addressing said issue.

Let me know when a good time is and I'll meet you on teamspeak and send you the last version of my all-in-one private anticheat I had done for my closer admin friends. It's designed to close the holes that ACE didn't address (like the SET command wallhack bullshittery). The code is obfuscated but I'll send you the complete source and if you want I'll outline each class of the mod and the nuts and bolts of how players are exploiting.

You'll find great reluctance on the part of the developers for them to talk about specific cheating methods in any sort of open manner. You'll do a lot better with PM's. If anyone is reading this and wants to help him I'd be glad to vouch for Raj. I've corresponded with him for years and he's a stand-up guy.

Sadly you are about to see that cheating is not only ongoing but rampant. I coded my mod to be able to run silently and only log to the server when it detects if desired. This allowed server admins to "test" run it without the player base being aware they had been flagged. Every single time it was deployed it was just....horrible. More than once I had admins tell me "I guess we'll just live with it. I never knew it was this bad." It's the main reason I quit playing competitive games years ago (and I was a ranked BR player back in the day).

I hope you get the answers you are looking for.

[x21]

The 2 easiest ways to run code are to hook into either the HUD or the Console. this can be fixed with a gametype that runs it's own HUD and console.

[Smirftsch]

I neither remember anymore, nor would I know where to start with all the hacks and exploits we've found and fixed over the years.
x21 is fully right, a lot, if not most of the cheats and bots have been done with custom consoles, but in the moment people are able to fake the guid of a package there is little chance to stop them.
We also blocked certain commands from being used online, such as editactor, because it opens a ton of possibilities.
In the end we've came up with solutions to check for manipulated packages and hooks, which is a rather costly process, as you can imagine.

[x21]

Integrity seems to be the only option to secure a server. And even this may not be perfect. This is the nature of client server games. The client will always have some level of control over what happens locally.

[Rajada]

SO, the good thing about Nerf Arenablast (other than the fact that most everyone who plays it plays one standardized version) is that because it was an older engine version, it's rather simplistic code-wise, and doesn't have the mess of patches that UT has. For example...

The 2 easiest ways to run code are to hook into either the HUD or the Console.

I'm not even sure NAB had support for HUD mutators, or if they'd even work. But this is besides the point. With the small community NAB has, I don't expect a ton of sophisticated cheaters. I expect a few people exploiting easily found in-game bugs. Hence...

You'll find great reluctance on the part of the developers for them to talk about specific cheating methods in any sort of open manner.

I wasn't expecting anyone to. I probably should have been more clear that I'm looking for low-tech cheats. I know that a lot of cheats are instanced from external files or outside of the game. But, again, I'm not expecting many cheaters like that in our small community I'm not denying they could exist, but rather looking for the places I can do the most good for NAB specifically. I was looking to seal up holes in in-game stuff, however, I'd still like to discuss that with you if you have the time.

[gopostal]

I understand what you are saying. There will always be people who cheat/exploit/whatever but if you can close down the points where you know trouble already exists then you don't need to worry about them so much. That's pretty much what the mod I'll send you was made for. I tried to address all the open parts of the engine that I both knew about and had the technical knowledge to do something with. I wasn't nearly as advanced as MK or Bob but I did take the time to tear open the existing anticheats (as well as both public and private cheats) to see what's going on under the hood.

I'm off this weekend so let me know if that's good for you. Been going through a bad spot with my voice but it's serviceable and should last the half hour or so we need. Is it OK if I email you the files ahead of time? You can look things over and see what I was doing.

[Rajada]

I'm off this weekend so let me know if that's good for you. Been going through a bad spot with my voice but it's serviceable and should last the half hour or so we need. Is it OK if I email you the files ahead of time? You can look things over and see what I was doing.

Yeah I can swing on this weekend. And go ahead and e-mail me whatever you need to, it will be helpful to get familiar with what we're talking about ahead of time.

[gopostal]

I emailed the files to you. One zip is the mod and ini and the other zip is the source. Don't get hung up if you try to read the source and it looks messed up. It's written that way on purpose to pass properly through the obfuscator. Once I show you how to filter it in notepad++ you'll be able to read it easily.

I'll hop into TS tomorrow.

[BobIsUnreal]

simple botting is very possible out of the box, although the fact that its mostly projectiles and not tracehits, makes it less viable.
cheating in a "kids game" powered by u225 level grapics is kinda stupid anyway, easy, but pointless.

[Rajada]

simple botting is very possible out of the box

But, was it done with an external program or in-game methods? I'm trying to eliminate mostly in-game exploits right now, though I'm very aware a lot of cheating is done with  external cheat programs. The way I see it, with the source code I have I can fix many of the in-game cheats that most Unreal games have to a point where you don't need administrative intervention, it just can't be done anymore. Such as the multi-gunning exploit I discovered is quite possible in NAB and fixed thanks to gopostal's help.

Like you said, cheating in NAB would be kind of silly, but I'm a bit more concerned with "exploits" anyway. I already know most of the issues in maps, which are certainly abused by people I've played with, but I hadn't thought about any of the engine exploits people could use to cheat until now. So I started this thread in hopes of collecting as much info as possible.

Already, my dev "team" and I have eliminated multi-gunning with the Whomper and "Wall hacks" via setting client texture properties. We improved glyph support, so flooding is much harder to pull off, and, we have plans on how to deal with the online unrestricted set command.

The way I see it, you can't really stop people from using external programs, but fixing in-engine issues will stop a lot of current cheats dead in their tracks.

[BobIsUnreal]

No external programs. Just modified nerf  files that were edited using  included nerf editor,
While i did not  test this online of course, If it runs offline, all that needs to happen if somone wanted to use it online would be to conform the file against the original  so it dont mismatch the servers version.



Probably  the  most simplest anticheat that checks for manipulated packages would instantly pickup on this tho.
the issue with package checking is there is such variants of every package for every version/patch,
for example,
unreal has has 25+ differnt patches. you would have to check on every combination, of every system file.
or restrict players to a specific version,  few years ago most ut99 servers required a version that the serverowner choose, say 436, but if you had 432, you couldnt play , and then there was 432 only server that required you have 432 aqnd not 436 etc.
227 for full security can disallow all but curret version to hhelp this, but every version has its own quirks, not to metion the dozen of sub betas people are using.
furthermore the uid of the files i belive may be able to be spoofed/hacked in such a way were they would show up to the anticheat as normal files anyway( maybe?)
 
the other way to defend from this specific exact "exploit" if you want to call it that , is to override the function it utalizes with your own, or "ignore" the changed code and have your code replace the base, instead of extend it.

also if your not  checking specificly for changed texture flags regualerly ( current vs texture.default?)
and your just limiting pre level SET scripts or reseting values.
there may still be a way to to use unreal scipt to toggle specific textures mid game, after checks are already done.

[han]

Changed texture PolyFlags didn't had that huge impact in Nerf anymore as surfaces now only use the PolyFlags set on the surface and masking on the texture (as in setting alpha to 0) is done during texture import. But this was actually just a rendering motivated change and that it affects cheating was never on my mind.

SET command is now restricted in multiplayer to certain classes like URenderDevice, UInput, more or less what the user can change inside the menu. I didn't want to break config for multiplayer.

One thing I currently don't understand and would like to have an explaination for is how one can abuse the SET command in singleplayer to cheat in multiplayer later on, where the SET command is restricted (doesn't need to be public answer, a PM would be fine).

Regarding the config for Console and other parts of Sytem.ini's [Engine.Engine] section, I have some rough plan how I can implement some matching of the clients config (and instances) to the one of the server and have already written some parts of it.

Another change we are going for is to restricting access to the C++ source code of our parts, so it becomes somewhat a larger hurdle to put in replacement parts.

But once again, this is just for raising the initial bar for cheating to a resonable level, without UnrealEngine source it's not even a fight we can hold our ground. ^^

[gopostal]

You have to remember that by their nature SET commands are persistent. They can remain in place across hard resets in a great many instances. That means you can do your SET command and then join the server of your choice and the setting can remain the way you had it (depends on the setting, some won't do this but many will). There's no choice but to periodically scan your players to check for default settings even if you disallow the usage of SET. Like Bob said you can just bypass this by manually editing the ini file, hacking the core, etc. Externally monitoring the settings though is hard to get around and that's why I did that method.

In that program I gave Raj there is code to log player's keybinds and modmenus to the server log. I would also add packages loaded and even look at logging some key settings of the client that would be beneficial to manually adjust if I were trying to do bad things. I used to be against this sort of thing but cheating is so rampant now that I think it's easily defensible as appropriate. To wit: https://www.pcgamesn.com/valve-steam-accounts-ban

You really should get Bob involved if you want to close as many holes as possible. I know most of the UT stuff but he's way better versed on the earlier engine exploits that were closed with 436. I hope you guys get this worked out, it looks like a pretty fun game and there's a place for nostalgia gaming that's getting bigger.

[han]

You have to remember that by their nature SET commands are persistent. They can remain in place across hard resets in a great many instances.

Can you name an example, so I could track that down in detail?

[gopostal]

Sure:
set playername gopostal

You are way overthinking this. Set commands aren't some sort of arcane thing, it's just a way to poke directly into the engine and alter a setting. If that setting is persistent, like if it's saved by being written to the ini, then it will remain. Lots of set's get flushed on map reload and revert to engine default (a change in drawsize to a particular class for instance) but a great many do not. Both ways are advantageous if you are looking to exploit things since you can make changes and they go poof when the map is over. A good instance of this is the rampant cheating on redeemer only servers in UT. Players use the set command to make the warhead launcher much much larger. This makes it nearly impossible to hide since your model will poke right through the walls or out the roof of where you are hiding. Since it's redeemers you only need to know generally where the player is to blast them. It's ruined the servers.

You'll never stamp out set commands unless you restrict them utterly. I'm not sure that possible, it would require rewriting a lot of the core code since it goes hand-in-hand with variable changing and the game code itself calls the command.

[han]

Yeah but the warheadlauncher is neither a config class nor does it has any config/globalconfig variables on it, so how does it work that the DrawScale sticks if set before joining the server?

So which of the PlayerPawn globalconfig variables can be abused for cheating? But in this case, as they are set in the ini, blocking access to a server after using the SET command is sort of pointless as they could have been set in the ini file in the first place.

Though i noticed that one shouldn't block access to setting the mouse (speed) related option.

[gopostal]

The warhead launcher drawscale is not something that is replicated over and over. It is loaded by the server using default values at map runtime and further instances just assume this default without that data passing from server to client. As a client I'm free to then alter those settings at will by opening my console, using a macro, hotkeys, etc. Because of the nature of Unreal engine's flexibility you almost surely won't be able to stamp this out by trying to address it how you want to address it. You can't restrict set commands on the client or you'll remove their ability to do a ton of things. To go this route you'd need to redo the core and even then I doubt you could account for everything. Guys like me would throw themselves into finding every seam we could just for the challenge.

You are way, way better monitoring the client. It can be done discreetly and with little to no overhead. My mod thoroughly checked players every few seconds and no one could tell it was running besides the first pass that collected the player's keybinds and mods. Even that stayed almost totally hidden in the map loading process.

You need to ask yourself if there was a simpler way of dealing with what you are doing, wouldn't others have already done it? Suppressing command usage doesn't work because of the law of unintended consequences.

[han]

Actually I'm just trying to understand why other people restrict connecting to a server after a SET command is used, so I would like to have an example how this can be abused, so we can descide if we would like to go this way, or can address this issue in another way or not bother at all.

How does this player checking every few seconds helps for example with the redeemer resizing, like it could just be increased just before drawing and after drawing reset to the normal size?

[BobIsUnreal]

also , restricting SET is pointless if someone can execute any type of uscript
for instance you could completely block any set command , and somone can just do
foreachall weapon , if weapon,isa reedemer then weapon.drawscale = 999.
or directly call the functions set would. also there is a alternative command  setpropertyvalue that basicly does what set does without using set

how does player checking every few seconds helps for example with the redeemer resizing

the server has client code chacking for these changes values. if it sees a setting that dsnt match what the server thinks it should be . its manipulated , and you can either reset the values, or boot the client out.

[gopostal]

Yeah, the client has no idea how often the server is checking them. It would be a simple matter to randomize those checks if they tried to beat it by timing the changes around the checks.

When doing anticheat work it's best to focus as close to the client as you possibly can. If you 'secure' the server and ignore the client then you simply have no way to address the new ways that they will come up with to exploit the existing code (and there WILL be ways to do this I promise you).

Build your core, close whatever you can that reasonable, then just expect that you will then be participating in the cat-and-mouse exchange that exists in every single multiplayer game out there. There just is no simple solution when games use a server-client relationship that allows input from the client. Not to mention this code is so old it's used as a way to teach new cheat code authors the basics before they move on to newer, more advanced games.

Edit: Hi Bob :waves: PM me your TS addy, I'd like to BS with you some evening and catch up.