XC_Engine [20] - XC_Core [7b] - XC_IpDrv

[Higor]

Good, XCGE allows you to code the antibrute forcer yourself.

[sektor2111]

For future fixes - Introduction:

• Application: Unreal engine
  http://www.unrealtechnology.com
  Games: Raven Shield, Deus Ex, Land of the Dead, Postal 2, Rune,
  Shadow Ops, Unreal 2, Unreal Tournament, Unreal
  Tournament 2003, WarPath, XIII and possibly other games
  based on the old versions of the Unreal engine (1, 2)
  Platforms: Windows, Linux, MacOSX
  Bug: failed assertion
  Exploitation: remote, versus server
  ...
  Bug
  ======
  This advisory is only a reference to keep this bug tracked because the
  affected games are enough old although still played.
  
  The engine uses a particular assertion in the ReceivedRawBunch function
  for handling the data in the incoming packets.
  Such assertion is "NumInRec<=RELIABLE_BUFFER" and can be exploited
  though the sending of a number of packets major than RELIABLE_BUFFER
  (128) using a sequential number different than the expected one.
  
  The effect for the games that implement this assertion is their
  immediate termination, while there are a couple of games (Unreal 1 and
  SWAT4) that simply report the failed assertion in the console without
  bad effects.

The tool for crashing exist in Medor's repository and the only engine having this problem solved is a 451 modified by Anthrax else the rest of versions still have this stupid exploit - including newer Engine versions (still wonder about V 4 because Epic learn lessons harder)
It needs a sanity check to close connection if overrides RELIABLE_BUFFER else you'll be rewarded with ReVote map. If a clow will setup a BAT file to deliver a loop attack nobody will join until the moron is banned from outside I guess because I'm not sure if UT helps.

Result of "join"

Code: Select all

DevNet: NotifyAcceptingChannel Control 0 server Level CTF-Face_R15.MyLevel: Accepted
DevNet: Level server received: HELLO REVISION=0 MINVER=400 VER=436
Critical: appError called:
Critical: Assertion failed: NumInRec<=RELIABLE_BUFFER [File:C:\UTDev\Engine\Src\UnChan.cpp] [Line: 262]
Critical: Windows GetLastError: The operation completed successfully. (0)
Exit: Executing UObject::StaticShutdownAfterError
Critical: QueueIt
Critical: UChannel::ReceivedRawBunch
Critical: DispatchDataToChannel
Critical: BunchData
Critical: UNetConnection::ReceivedPacket
Critical: UNetConnection::ReceivedRawPacket
Critical: UTcpNetDriver::TickDispatch
Critical: UpdatePreNet
Critical: ULevel::Tick
Critical: (NetMode=1)
Critical: TickLevel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: UpdateWorld
Critical: MainLoop
Exit: Exiting.
Uninitialized: Name subsystem shut down
Uninitialized: Log file closed, 03/06/15 19:26:33

Successfully crashed.

Wasn't that fixed though? I remember looking at a list of familiar bug reporting and fixing from a website somewhere.

It was fixed only in one 451 which is unfriendly with XC_Engine (Speaking about Linux). And... I got rid of 451 even from Win because I wanna see what is in certain Level directly in server and 451 DOESN'T Help at all.

[Chamberly]

Wasn't that fixed though? I remember looking at a list of familiar bug reporting and fixing from a website somewhere.

[Higor]

Aren't v436 servers immune to that exploit?
PD: Why does it not surprise me Medor is hosting the tool...

EDIT:
I guess not.

EDIT2:
Oh look, I HEX edited my Engine.dll and the crash was gone

All i did was change the 128 (RELIABLE_BUFFER) value into 0x00FFFFFF.
Good luck sending me 16777215 packets meeting special conditions in a single frame.
Now I simply have to let XC_GE find that code dynamically and patch it? I may need help to do this...

[sektor2111]

Why does it not surprise me Medor is hosting the tool...

He possible doesn't knows what is that, he is "trying to help" like others do. Luigi has more info and is a contributor in finding Win exploits speaking even about OS itself not only such applications. Anthrax told that he couldn't solve that VIA ServerCrashFix so he recompiled other DLL, the rest of 451 "engine" is unchanged. After my understanding he left reliable condition normally and added an "else" socket_close or such, simply closing unreliable fart, or he changed condition - if bigger than Reliable- close connection, it was a pretty small thing added and problem has been solved without increasing buffer size. At least 451 would be also supposed to solve max connections/minute to not see multiple attempts (other exploit presented somewhere which I can't recall right now - maybe I'll G00gle that later). Other things I don't know at this moment but "serverkill" tool can also be modified in several ways to do one or more messed things and that's why each mod intended to spawn something in game ordered by player needs to be controlled against abusing else you might see X millions spawned (recall discussion about precipitations) and server will go down in certain moment, yes is not only cheating the way to harm things in a server. I don't even want to see if this thing called "abusing" is solved in UE4 or we can wait 5 years for monthly updates. Maybe in 2030 an UE5 will be a better error free model.

[papercoffee]

I don't even want to see if this thing called "abusing" is solved in UE4 or we can wait 5 years for monthly updates. Maybe in 2030 an UE5 will be a better error free model.

Isn't UE4 not any longer based on U-script?

[Higor]

XC_Engine: Found RELIABLE_BUFFER assertion at 0x1040129B: v436 Engine.dll
Log: READING ADDRESS: 128
Log: SETTING ADDRESS: 16777215

That was easier than expected... of course I need to change the VirtualProtect() into mprotect() if I port this to Linux.
I'll add the reverse method so that ACE won't bitch when you log on onto a server.

==========
Request, need v440 and v451 (non-patched) Engine.dll files so I can disassemble them and find where the assertion is.

[sektor2111]

You can't hook DevNet or that UnChan.cpp? I still believe that it needs condition changed. I'm not sure if increasing buffer is the right response but if won't be causing other nasty things... then hack that as you consider. As I can see in log first thing reacting is DevNet. I don't know who and how links that but it is primary thing facing bad request.

[Chamberly]

I don't even want to see if this thing called "abusing" is solved in UE4 or we can wait 5 years for monthly updates. Maybe in 2030 an UE5 will be a better error free model.

Isn't UE4 not any longer based on U-script?

I heard somewhere that they said it's based on C++... I don't know if there is any U-script inside the free source. I guess the UE is based off C++ then. & then I'm like... so it's not a Uscript game? lol jk

[sektor2111]

I did not check UE4 yet but all prior versions have C++ native side and UScript side.
Bad code Natives leads into instant crash. Bad coded Uscript leads in other exploits causing events to not go as supposed and other unexpected results.
_____________
I found how was fixed into a 451 version this exploit

Code: Select all

For Unreal Engine licensees:

In UnChan.cpp, UChannel::ReceivedRawBunch:

Replace:

checkSlow(NumInRec<=RELIABLE_BUFFER);

With:

if (NumInRec>=RELIABLE_BUFFER-1)
{
Connection->State = USOCK_Closed;
}

So if overrides buffer connection is closed. I cannot say if is good to replace "checkSlow" with "if" but it looks like is solved based on this wrapping.

[Higor]

The buffered bunches won't crash the game if they exceed 128 (RELIABLE_BUFFER), they're no longer stored in a static array (as with ancient unreal engine) but instead they're a chained list of objects that loop from start to finish.
The server remains stable even after making the assertion check for a stupidly high value, and yes, the memory region edited corresponds to UChannel::ReceivedRawBunch indeed.

So whatever, I could read the entire ASM instructions and try and make a copy of the function but I'm not being paid for that time, and secondly the servers appear to handle the excess packets just fine with no apparent memory leak whatsoever.
As long as Luigi's stupid little tool doesn't crash the server, then it's fine.

(Almost) Better news are that my v451 Linux server managed to bind again, after I realized the UnGnuG.h anth provided to fix compilation was missing the 'appSeconds' symbol and I had to put it back there.
(appSeconds is inlined at build time, my binaries are not supposed to find it in Core.so)
Then, after fixing the entire mess with global and static variables, I got it past the initialization stage and the server runs fine... until the garbage collector runs and crashes, so we're back at v9 issues.
Don't know if I should blame this on the GameEngine class size (4 bytes bigger in v451), the crash persisted after I temporarily edited the class header to include the v451 change.
What I know is, that the (TopChunk==NULL) assertion is nothing like I've seen before.

[sektor2111]

The buffered bunches won't crash the game if they exceed 128 (RELIABLE_BUFFER),
...
As long as Luigi's stupid little tool doesn't crash the server, then it's fine.
...

This means that developing a bigger buffer is just a good solution.

[Higor]

I started brainstorming a bit and found a way to dynamically relink the ULevel object (MyLevel) into a different class that runs custom code, setting up the level was the challenge and can't make it work for clients... doesn't matter because I only need said hack on servers.
I'll start by adding an extra replication layer that allows actors to be replicated from behind translucent surfaces, hopefully it won't be horribly slow.

[sektor2111]

I'll start by adding an extra replication layer that allows actors to be replicated from behind translucent surfaces, hopefully it won't be horribly slow.

I was testing such things, let's say I'm not disturbed because I'm no longer playing games having 2000 creatures.

[RocketJedi]

version 10 crash

XC_Engine: Checking for Moving Brush Tracker insertion...
Init: Game engine initialized
Critical: UXC_TravelManager::PostMapChange
Critical: UXC_GameEngine::Init
Critical: UServerCommandlet::Main
Exit: Executing UObject::StaticShutdownAfterError
Exit: Exiting.
Uninitialized: Name subsystem shut down
Uninitialized: Log file closed, 03/10/15 13:18:51

had to go back to version 9