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

Higor
Godlike
Posts: 1832
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 10]

Post by Higor » Fri Mar 06, 2015 5:20 pm

Good, XCGE allows you to code the antibrute forcer yourself.
ImageImage
Image unreal://23.111.157.138:7777
Image unreal://46.228.199.205:7788

User avatar
sektor2111
Godlike
Posts: 5507
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 10]

Post by sektor2111 » Fri Mar 06, 2015 6:21 pm

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.
Chamberly wrote: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.
Last edited by sektor2111 on Sat Mar 07, 2015 10:14 am, edited 3 times in total.

User avatar
Chamberly
Godlike
Posts: 1963
Joined: Sat Sep 17, 2011 4:32 pm
Personal rank: Dame. Vandora
Location: TN, USA

Re: XC_GameEngine [build 10]

Post by Chamberly » Fri Mar 06, 2015 6:31 pm

Wasn't that fixed though? I remember looking at a list of familiar bug reporting and fixing from a website somewhere.
Image
Image
Image Edit: Why does my sig not work anymore?

Higor
Godlike
Posts: 1832
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 10]

Post by Higor » Fri Mar 06, 2015 10:46 pm

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...
ImageImage
Image unreal://23.111.157.138:7777
Image unreal://46.228.199.205:7788

User avatar
sektor2111
Godlike
Posts: 5507
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 10]

Post by sektor2111 » Fri Mar 06, 2015 10:49 pm

Higor wrote: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.

User avatar
papercoffee
Godlike
Posts: 9987
Joined: Wed Jul 15, 2009 11:36 am
Personal rank: coffee addicted !!!
Location: Cologne, the city with the big cathedral.

Re: XC_GameEngine [build 10]

Post by papercoffee » Fri Mar 06, 2015 11:28 pm

sektor2111 wrote: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
Godlike
Posts: 1832
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 10]

Post by Higor » Fri Mar 06, 2015 11:38 pm

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.
ImageImage
Image unreal://23.111.157.138:7777
Image unreal://46.228.199.205:7788

User avatar
sektor2111
Godlike
Posts: 5507
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 10]

Post by sektor2111 » Sat Mar 07, 2015 12:57 am

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.

User avatar
Chamberly
Godlike
Posts: 1963
Joined: Sat Sep 17, 2011 4:32 pm
Personal rank: Dame. Vandora
Location: TN, USA

Re: XC_GameEngine [build 10]

Post by Chamberly » Sat Mar 07, 2015 4:50 am

papercoffee wrote:
sektor2111 wrote: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
Image
Image
Image Edit: Why does my sig not work anymore?

User avatar
sektor2111
Godlike
Posts: 5507
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 10]

Post by sektor2111 » Sat Mar 07, 2015 10:43 am

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
Godlike
Posts: 1832
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 10]

Post by Higor » Sat Mar 07, 2015 3:52 pm

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.
ImageImage
Image unreal://23.111.157.138:7777
Image unreal://46.228.199.205:7788

User avatar
sektor2111
Godlike
Posts: 5507
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 10]

Post by sektor2111 » Sat Mar 07, 2015 6:25 pm

Higor wrote: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
Godlike
Posts: 1832
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 10]

Post by Higor » Mon Mar 09, 2015 6:48 am

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.
ImageImage
Image unreal://23.111.157.138:7777
Image unreal://46.228.199.205:7788

User avatar
sektor2111
Godlike
Posts: 5507
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 10]

Post by sektor2111 » Mon Mar 09, 2015 9:21 pm

Higor wrote: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
Inhuman
Posts: 828
Joined: Wed Mar 12, 2008 7:14 pm
Personal rank: I.T Master
Location: New York

Re: XC_GameEngine [build 10]

Post by RocketJedi » Tue Mar 10, 2015 6:20 pm

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
https://www.vulpinemission.com
Image ROCKET-X8 Server
Image MONSTERHUNT w/ NALI WEAPONS 3 + RX8
Image BUNNYTRACK NY
Image SNIPER DEATHMATCH
Image InstaGib + ComboGib + Jailbreak
Image ROSEBUM ROCKET-X RB