Server Help :: View topic - SubGame Server Decompiled, Continuum Support!

Server Help

Misc User Apps - SubGame Server Decompiled, Continuum Support!

fatrolls - Mon Dec 01, 2014 2:36 am
Post subject: SubGame Server Decompiled, Continuum Support!

I wanted to make SubGame open source so I could work off it because ASSS got alot of shortcomings like bad commands hard structure to work with and other stuff.

I took subgame.exe which is pretty clean server not subgame2.exe this one has no patch work to Fix.dll so it is pretty clean when decompiled.

Pretty much wasted my whole summer re factoring the names so they make more sense.

Got it to fully compile a week ago and it didn't even run just crashed, I don't know C that well I can fix stuff though.

Started breakpointing and fixing things little by little and in the end got SubSpace 1.34 to connect and fly around etc..

Then 2 days ago I wanted to add Continuum support found a good article explaining how Continuum encryption worked by Snrrrub.

Got Continuum encryption implemented and now you can fly around using Continuum.

Well it's pretty stable atm just got issues with multiplayer support don't know how it can handle packets simultaneously from multiple users without threading. I see it creates extra subgame processes for each user but I never figured out how to activate it.

Pretty much I gave up and decided to release it maybe somebody will pick up where I left off and I could start working on it again..

If someone wants to fix the multiplayer support I would start working on it again.

Uploaded the project on Google Code:
https://code.google.com/p/subgame-continuum-subspace-clone/source/browse/

You could download that rar file which is all the folder structures.

To work on it download the updated Dev-C++ by Orwell
http://sourceforge.net/projects/orwelldevcpp/

also get the plugin for AStyle which you can install into Dev-C++ quick tools
now you can code pretty sloppy and let it auto beautify your code for you.

Run's without crashing

P.S.> The old 1.34 Subgame server folder is before I started to add the Continuum Encryption it has alot of outdated code and will crash more often then the Continuum version.

CypherJF - Mon Dec 01, 2014 11:52 pm
Post subject:

Nice, thanks for your hard work!

Mine GO BOOM - Thu Dec 04, 2014 1:56 pm
Post subject:

Uploaded a copy of the rar to your post.

cycad - Sat Dec 06, 2014 12:30 am
Post subject:

That is good work. Part of the problem is IDA and Hex-Rays do not always produce correct disassembly/decompiled source. Another part of the problem is that there are some bugs that fix.dll & the subgame2 patches fix. Still, looking at vanilla subgame.exe instead of subgame2.exe is the correct way to do it. Unfortunately there are bound to be tons of necessary fixups in general and especially around optimized areas.

fatrolls - Sun Dec 07, 2014 8:07 pm
Post subject:

Learned some secret commands on subgame that people never documented such as Shift+F12 to shutdown the subgame. Some incorrect packets on the twcore Subspace Protocol could be figured out easily here such as the SendAdvertisements people didn't know how to calculate the size of the bitmap, but it turns out it doesn't even send a bitmap but just pixels, you have to build the bitmap by hand it must use the same palette that subspace uses for its 256 colors. The player voice packet was misunderstood I figured it out.. Also figured out a few vulnerabilities that could possibly be used to cause problems.

Didn't even know it hosted a server on server port + 1 just to display number of users and lag of the zone in the zone list lol, could easily be spoofed up to 65,555 players in your zone most likely even show up on directory list haha.

Yes it has no problems submitting your zone to the directory list and it even shows up there (didn't bother the spoof trick as it would probably ban my zone from the list).

Has no problem connecting/communiating with the biller server uses standard subspace encryption for that with encryption turned off by echoing the same server key or echoing a 0 client key i forgot.

My biggest problem was getting BinarySearch to work right and the solution turned out to be very very simple turns out Hex-Ray's doesn't do Parenthesis correctly had to resort to asking stackoverflow for a solution here so it just did the math too early without doing inner-math first.

This was a very good learning experience with Hex-Rays as now I could see exactly what it can't do, I was going to write a regular expression script that automatically fixes all the fixes I did by hand to Hex-Ray generated code to make perfect compiles but I figured some areas require a parser and I would need to get some IDE code that parses C code properly and abandoned that idea.

Most importantly I wanted a plugin for Hex-Rays that automatically searched for the same address offsets and figured out what structure needed to be used maybe even traced each function that uses other functions with the same structures and automatically filled in all the structures so renaming would all that would of been needed in the process.

Found a plugin that does that surprisingly very poor performance from it had to resort to structuring the structs by hand.

Things like HugeChunk Packet transfers required a structs inside of another struct.

Kept it all C no typedef's none of that garbage

I liked how subgame wrapped malloc/free with AllocateMemory/ExpandedMemory/FreeMemory gives it nice feel like visual basic with Redim Preserve memory resizing memory and its all clean without getting those segmentation faults and other crap.

Yeah I removed nearly all ugly optmizations that HexRays couldn't figure out such as strcat/strcpy some memset's which are represented as a bunch of nested loops.

Removed optimizations that multiply to represent negative numbers.

Removed optimizations of the __OFSUB__ and __SETS__ which looked ugly..

I left in only 2 or 3 __OFSUB__'s which I wasn't sure of.

Some good things could be learned from this C code like how to properly drop the flags. Such as
SpawnOnMap

Any numbers which used __PAIR__ all removed
Represented all float/doubles properly not shifted by some power, figured out the shifting is the same as dividing by a certain power.

And made sure it has no C++ code only used new[]; in a few areas which I replaced with mallocs

It still has no multi-threading and never did but it seems to work like that.. but I think something because multi-threading is missing all the packets should probably suffer some kind of delay as they are all processed by one pipe a while loop and I think this is the reason why the server doesn't support mulitplayer atm..

You can login Continuum / Subspace with it and it works fine (Well I broke Subspace haha, now you always get warning of a mismatch login.)

Continuum works perfectly after I added the Continuum version packet.

Only problem right now it doesn't support multiplayer as you can login one person and fly around no problem.. but a second person wouldn't be able to even get past the login screen. It either thinks that connection is already online and ignores it or it just has some bug somewhere..

I want to make this run without problems so I could possibly run this on a Linux computer. Only problem is I wouldn't be able to run "Continuum.exe Z" command so I would always have to use the old scrty1 / scrty files which is probably no problem as no one really cheats.

Thats about the only problems that it has right now.

P.S.> I fixed up OpenCore you released with a ton of bug fixes, added mysql support and others added ASSS Support, I'll attach it here if you want to update your github with it.

Mine GO BOOM - Mon Dec 08, 2014 12:45 pm
Post subject:

As a reminder, the original subgame.exe combine with the original Subspace.exe do have some exploit issues. You can potentially have full read/write access to any file on the client's drive (*getfile and *putfile). There are other exploits on the server side that also have been patched against.

Things like Shift+F12 were known and was used as a griefing attack against small zone owners a long time ago ("Hey dude, Shift+F12 opens this cool admin panel in subgame"). Needing to open both the main Port and Port+1 is mentioned a lot in all the Router FAQs (https://forums.minegoboom.com/viewtopic.php?t=2443).

cycad - Tue Dec 09, 2014 7:50 pm
Post subject:

fatrolls wrote:

P.S.> I fixed up OpenCore you released with a ton of bug fixes, added mysql support and others added ASSS Support, I'll attach it here if you want to update your github with it.

I'll look at pull requests on GitHub if they are per-feature (not one giant pull request for everything), but there's no way I'm going to manually merge by hand from a zip file. I doubt it has tons of bugs as you say since it has reliably stable performance from those who use it in EG. As for MySQL last I remember was it couldn't be added due to licensing issues. That would be useful to have though.

fatrolls - Tue Dec 09, 2014 9:55 pm
Post subject:

It had bugs for one the PacketClustering was not properly implemented didn't take into account packets already over 255 in size as the size byte could only represent 1 byte so the size sometimes cycled on itself and crashed (very long chat messages)..

It had bugs like connecting to ASSS and couldn't support those C plugins like baseduel/eliteduel/duel that were coded for PowerBot I believe. I added support for them

bugs all around to be honest I think the BigChunk !getfile !putfile were broken fixed those.

I guess it's just a very outdated version on github

cycad - Tue Dec 09, 2014 11:30 pm
Post subject:

ASSS compatibility is a non-goal for opencore, so I'm not at all surprised about incompatibilities there. That's because ASSS was designed considering what Continum will accept whereas opencore was designed considering what subgame will produce, and those aren't the same.

That being said clustering shouldn't crash so I looked over the cluster parsing code (phand.cpp:230) and don't see anything wrong there?

Your're right those bots you mentioned were for PowerBot which is a different core so those wouldn't work with opencore without modification. That's not a bug although it is cool you added support for those PowerBot plugins to opencore.

What's on GitHub is .19pr1 (prerelease 1) so it has mid development, non-functional features and file transfers are one of them. .19 did eventually come around but the source was lost when the VPS I did dev on crashed, and I realized I didn't care enough to rewrite what was gone. This was in 2007 when I abandoned the project.

I can't post more detail or look at code since I'm on travel using an iPad and this post has taken like 2 hours. Maybe next week if I don't get RSI from using this thing.

fatrolls - Thu Dec 11, 2014 3:26 pm
Post subject:

What I meant was

https://github.com/cycad/opencore/blob/master/opencore.cpp

at line 1032

and how its used at 1110 & 1112

you can see the flaws there.

look at this line:

Code: Show/Hide

&buf[offset], "AZ", p->len, p->data, p->len);

You do know that the packet length can possibly exceed a byte (255) and overflow into a small value making the packet completely de-synchronize. Have to avoid clustering packets if they are over 255 in size.

I know those were stolen from TWCore and TWCore has the same flaw I reported they dont seem to care about fixing it the correct way but quickfixed it by limiting chat messages to 243 characters even though 250 is allowed by continuum.

cycad - Thu Dec 11, 2014 10:07 pm
Post subject:

It's not wrong and neither is TWCore. It's the format that subgame accepts so it's a limitation of the protocol, so guess what -- nobody is stealing from anybody; both groups have correctly implemented packet generation. I'm not sure what you're trying to accomplish with an asinine accusation like that about stealing code.

The code you are referring to is a non-exported function so it doesn't do bounds checking. You can't just call into it with bogus data and expect it to work. Exported functions that do eventually make that call limit the message size accordingly to prevent the non-issue you've described.

This thread has really turned counterproductive so I don't think I'll be responding further unless there's something relevant to current dev or subgame reversing that we can talk about.

fatrolls - Thu Dec 11, 2014 11:43 pm
Post subject:

You seem to be missing the point of what i'm trying to point out no idea why you are turning so aggressive, I read somewhere from your source code that you borrowed it from TWCore.

Why don't you just admit you what really happened someone poorly guessed how the packets worked in Subspace and everybody started following that standard

Packet clustering is used when many packets suppose to be sent at one time and could all fit in one packet which is under 255 bytes in size, other then that it should always just use reliable packets (ignoring core packets of course)

You can read any file like
https://github.com/cycad/opencore/blob/master/encrypt.cpp

it says it's ported over from TWCore so I assumed the clustering was as well.. as it's identical in TWCORE you're probably not as sharp as me haha but that's not a problem no need to be so ignorant about the whole deal I'm just trying to help out.

You seem to be forgetting how your bot worked the send_outgoing_packets is what flushes all packets. We both know you don't call the write_packet directly if you wish to send any raw packets they all first go through send_outgoing_packets

So if that function is used to send all the packets your bot generated, if you are sending out which could involve a chat packet which is over 255 in bytes in length therefore it shouldn't be processed as a cluster packet but it may (if two packets meet up together in the same loop which does happen)

That chat packet may in
n->queues->h_prio
or
n->queues->n_prio

both get processed by pull_packets function which will attempt to create a cluster for all packets, since the next function write_packet can only be used to send 1 packet at a time, so it tries to cram as much information into 1 packet as it can instead of sending multiple packets that are pending to be sent the same time. But that's the flaw overlooking each of the packets sizes first.

In your source you attempt to create a cluster packet if atleast 2 packets are on the list. So lets say the first packet is over 255 byte in size packet and the second is a normal maybe 16 byte packet

the pktl will be 2 for the cluster layout

MAX_PACKET = 512
MAX_PACKET - pktl = 510

Run this check
(p->len + ch_size <= len - offset)
with
(255 + 1 <= 510 - 0)
simplified its
(256 <= 510)

which will process the packet as a cluster even though it's not suppose to be a cluster.

I understand maybe the packets magically are all checked somewhere before they are even checked whether or not they can be clustered, but unfortunately both TWCore and your OpenCore doesn't have that check anywhere.

Yeah I fixed it pretty crappy but I fixed it.

Why do you think TWCore caps out messages to 243 letters and not the full 250 letters? if you check their source code

http://www.twcore.org/browser/trunk/twcore/src/twcore/core/net/GamePacketGenerator.java

as you can see on line 744 the chat packet composes a low priority packet

if you look what kind of packets they have at class from line 1537.

You'll see they have normalPackets and cappedPackets which both get processed by 1 pipe on line 1566 which is getNextPacket()

It also has the same limitation as your bot on the line 84 where if there is only 1 packet on list it's sent reliable yet if there is 2 packets on list it sends as clusteredpacket

what characterizes it a cluster packet just because there 2 packets on the list? (same way as your bot)

As you know reliable messages don't send a size byte to indicate how big a sub-packet inside it is.

Cluster packets are sent as reliable messages.
Reliable messages can also send packets such as big chat packets without clustering them in the first place

if it was implemented properly then you can send chat messages up to 250 characters long without any issues and I've fixed that in OpenCore, but in TWCore they said they would fix it but don't really care.

Why did TWCore pick the special number of 243 as maximum chat packet even though in continuum I can easily send a 249 chat length message no problem hehe.

Here is my explanation for that
Chat packet

Code: Show/Hide

bytearray.addByte( 0x06 ); // Type byte
bytearray.addByte( messageType );
bytearray.addByte( soundCode );
bytearray.addLittleEndianShort( userID );
bytearray.addByteArray( msg );
bytearray.addByte( 0x00 );

Reliable packet

Code: Show/Hide

outgoingPacket.addByte( 0x00 );
outgoingPacket.addByte( 0x03 );
outgoingPacket.addLittleEndianInt( m_nextOutboundAck );
outgoingPacket.addByteArray( message );

chat packet
1+1+1+2+X+1 = 6
reliable packet
1+1+4+X = 6

Now combine that where the bot crashes since it all passes through a clustering system

255-6-6 = 243

As you can see they try to force the chat packet to always fit into a cluster packet first of all reliable messages can't be clustered but I haven't really looked whats going on

So don't tell me bullshit as you can see it's the same flaw.
I know what I'm talking about I'm experienced at what I do, I actually make big money from reversing.

damageinc86 - Fri May 16, 2025 2:05 pm
Post subject:

fatrolls wrote:

I know what I'm talking about I'm experienced at what I do, I actually make big money from reversing.

Oh how we need people like you now more than ever.