UT99.org | Unreal Tournament Community

So I have a couple of questions for the at-large group here. Over at Dane's we had been discussing UT servers that are doing a bait-and-switch. You connect to one IP and they quietly move you to another (without any notice and without permission). I don't care to discuss the 'why' part, I'm just of the mind that this is not tolerable behavior.

This is right on the heels of our fake-player discussion (don't worry paper, that's all I'm going to mention about it) and it's had me thinking. Servers have really had too much say over clients in UT and I think it might be time to give some of that back.

Here's what I'm proposing: a client side mod (I'll call it Adrian, the Patron Saint of soldiers) run locally by you that monitors your installation. If you go to a server and that server moves you then Adrian lets you know. If the server tries to write to your ini file Adrian will also tell you what was written and which server did it. I could even log when the ini was read and what information was requested. That's just a few things this could be allowed to watch and report, I'm sure there are more.

The trick will be keeping it from hooking most game functions so it stays off of ACE's radar. It can be done though, even if it meant running it outside the UT folder's allocated memory.

Is anyone interested in something like this? Would it be something you would use?

Yes, I'm freaking tired of servers constantly adding themselves and their 'friend' servers to my Favorites every time I join them. I have like 25 servers in favorites and 5 that I actually play on.

Handling inis shouldn't be something that ACE would cause problems for, you just need to perform some integrity checks in critical classes, and store backups of said settings in a master class.
Now if you're talking about having more control on how the Game Engine handles URL's, all I have to do is add some extra lines on my XC_GameEngine.

Wouldn't be a bad idea to block all URL browse commands that don't come from map Local sessions, replicated ClientTravel with a matching URL to current server or the player's own Input.
That pretty much solves all unauthorized ClientTravel/Open commands, I'd just have to trace back the entire function stack lol.
Could add an extra console command to toggle said protection, something like LockURL 1 and LockURL 0.
This way we won't even need to spawn a single actor to perform a per-frame check at all.

Higor wrote:Wouldn't be a bad idea to block all URL browse commands that don't come from map Local sessions, replicated ClientTravel with a matching URL to current server or the player's own Input.

If you could do that a LOT of players would be very happy, myself included!

Could it also detect wether or not its the client that add servers to favorites this way?

I have heard long time ago that some servers could snatch your INI in some way, or rip out lines from it, for example the root-password to your own servers, dono if this is even possible in real or just a hoax, since i could not let this of my mind i never visit other servers with the same UT i use on my own servers...False or True ?

Without a doubt: true. I've done it. Not for bad reasons, you guys all know me better than that, but Dane and I did test reading/writing to all of the client's installation and not just the UT/User ini. It's not hard to grab all the important ini lines and you as a client would never know it. I can take your passwords as easily as changing your favorites, and that includes being able to fake your nexgen login on your own server. This is why I campaign so fiercely against servers doing bad shit to clients. They can steal as easily as writing to you, it's the same set of codes.

Just have a look here to see what "they" can do with your UT, your ini your PC .....

https://forums.epicgames.com/threads/76 ... ANT-UPDATE

This was used for UT2004 but i why should it not work for UT?

It mostly won't work because of the bandwidth restrictions that are a part of UT. I say 'mostly' because I don't know for sure. Ferali and I have discussed this at length and he seems to think you cannot get outside the UT installation while I think it's theoretically possible (just not practical). The server-client connection is already pretty saturated so trying to piggyback anything alongside of it would be really tough. I can't imagine the hoops Anth had to jump through to get the ACE snapshots across.

Let me be clear: I've never seen anyone able to access outside the install without using a dll but I wouldn't bet the farm against it. Even still there's a lot of damage to be done. With existing code I can place a cheat into your cache file, write the aimbot binds quietly to your files, and wait for you to be flagged on other servers. All without you knowing anything.

Man that ain't a U package, it's a whole spyware on your system lol.
And native packages would need permission from the user via NPLoader right?
Unfortunately we can't prevent other Unreal packages from accessing your settings if a server decides to run it, we can make a client-only package (client may install it on his own) that with LOCK and UNLOCK toggles so that your settings aren't messed with.
It's best done via the Root Window, as a matter of fact, I use a custom root window to prevent ASH and ModMenuChecker from scanning my mods lel.

Conceptually this reminds me of some of the security tools and browser plugins available.
I get notified or blocked if the "wrong" site tries to load.

You could also compare it to SSL certificates being checked to see if they match the URL you are actually on.

A client-side solution does seem to be the best option.
If it turns out to require an external program, would that also make it easier to support other UE games ?

Higor wrote:Man that ain't a U package, it's a whole spyware on your system lol.
And native packages would need permission from the user via NPLoader right?

What would prevent a fraudulent person to hex edit or recode NPloader to skip the client acception and just make it auto inject and execute the script?

native code can be injected - executed - and then deleted again without the player knowing about it. And since you will have to leave a port open for internet traffic in order to play on the server, then whatever traffic the fraudulent coder will be transfering will go unnoticed unless you as a client have installed tool(s) to scan your ingoing/outgoing data - tools that very native package can bypass too if the fraudulent coder has taken that into account too. In theory we are doomed - it's like the good old virus vs antivirus theories, you got to know what you are up against in order to stop it - and you will always be at least one step behind all the time.

Spoiler

This thread sounds like cheat. Lock!

Ignore me.

TheDane wrote: What would prevent a fraudulent person to hex edit or recode NPloader to skip the client acception and just make it auto inject and execute the script?

I've had that same thoughts myself but never shared that with anyone. It seems the weakest link to me if you were to attack the process.

Still though, all this is just armchair discussion. The reality is that there is not much to be gained by any of this that can't be gotten already via UScript. Even if you could get outside the UT folder the client would almost surely lag out or crash when you tried to transfer any data. You'd need a rogue dll to do the work for you and that's not getting passed to you without you installing it yourself. Really we just need to think about handling the problems we know exist: unwanted ini changes and monitoring of ini accessing. The rest is worth kicking around but let's not lose sight of what can be worked on.

Chamberly wrote:

Spoiler

This thread sounds like cheat. Lock!

Ignore me.

Nah ...not really. But the thread went again another way as Jack intended it, at start.

All this is a mere milkmaid calculation* theoretical and practical are you in danger when you connect to a server.
A mean and dastardly server admin can do with an unprotected client what ever he/she want. To detect this meddling in your ini. (and make it public) is more important then to block all possible attacks... you will not win. Or why is it that the Virus-database in your V-scanner get updated nearly every second day.
And I think it's dangerous to talk about this malicious dll. possibilities openly in the public.


*Directly translated from German, means "naive miscalculation".