Server Help

General Questions - Making a bot

Anonymous - Thu Sep 01, 2011 7:48 pm
Post subject: Making a bot

I'm making a bot, starting from scratch, not worrying about the packet encryption for now. Building it in VB.NET

I attempted to emulate some of continuum's packet's and I can't seem to past this part..

This is output from VB.NET

Code: Show/Hide

C2S data = 00-07
C2S data = 00-07
C2S data = 00-01-00-34-DB-CD-11-00
C2S data = 00-01-00-34-DB-CD-11-00
S2C data = 00-10-E9-7A-AE-3F-DC-49-5A-49-01-00
C2S data = 00-10-E9-7A-AE-3F-DC-49-5A-49-01-00
S2C data = 00-10-EA-7A-C0-DD-62-89-8C-42-01-00
C2S data = 00-10-EA-7A-C0-DD-62-89-8C-42-01-00
C2S data = 00-01-00-34-DB-CD-11-00
C2S data = 00-01-00-34-DB-CD-11-00
S2C data = 00-10-EB-7A-70-BE-90-55-DE-46-01-00
C2S data = 00-01-00-34-DB-CD-11-00
S2C data = 00-10-EC-7A-84-2A-84-85-52-84-01-00
C2S data = 00-01-00-34-DB-CD-11-00
S2C data = 00-10-ED-7A-60-35-D4-1E-11-7A-01-00
C2S data = 00-10-EB-7A-70-BE-90-55-DE-46-01-00
S2C data = 00-10-EE-7A-74-CD-3A-8A-BA-56-01-00
C2S data = 00-10-EC-7A-84-2A-84-85-52-84-01-00
C2S data = 00-10-ED-7A-60-35-D4-1E-11-7A-01-00
C2S data = 00-10-EE-7A-74-CD-3A-8A-BA-56-01-00

With Wireshark I noticed it opens up 2 connections to every zone I connect too.. but then again UDP never connects so i'm kinda baffled here.. of course this is new to me.. all this networking and stuff.. first time i'm doing this.

Lol honestly.. hold up a second i'll have to reget these packets.. they may contain my username and password.. I don't know what they mean right now, someone might decode them and steal my account lol.

Anyways looking at the packets seems the first 2 bytes are not encrypted and used as control bytes such as 00-07 looks like a connect to server request, then you send

00-01.. which has 00 - [4 important bytes it seems] - 00

server sends back
00-10 - [4 important bytes it seems] - [ 4 more important bytes it seems] - 00

they do seem random but I think they are some kind of seeds or something.. of course this is all guess work. But the client keeps sending random stuff everytime and the server responds with more random pairs of dwords.

Then the client sends a new 00-01 request.. seems it didn't make a connection so it retries again.

Anyways all this is just my understanding but I am still unsure why I cannot connect to say SSCU Extreme Games.. I double and triple checked my work.. and I don't see any reason why I shouldn't be able to keep connecting.. I am just resending the same packets continuum generates.. to the server and the server responds with it's stuff..

I just came here to get some wisdom i'll get this fixed eventually, but I don't know what I'm doing right now.. I been trying to disassemble the subgame server. Found some strange things.. seems you guys don't have the source code to subgame server? and you make patches in Fix.dll?

But i'm pretty much trying to make a bot.. that will fly around SSC network zones and act like a real player hehe.

Cheese - Fri Sep 02, 2011 12:44 pm
Post subject:

http://d1st0rt.sscentral.com/packets.html

Anonymous - Fri Sep 02, 2011 7:57 pm
Post subject:

Anyone have Continuum v0.40's key expansion from server keys. From researching this forum seems there was a oracle server ran by Snrrrub on UDP://sharvil.nanavati.net:6000 but after sending it the packet my connection gets forcibly closed. So I don't know how to decrypt continuum packets.. Looking at other bot sources/api's i figured no one has continuum encryption fully set.. Unpacking continuum executable isn't hard.

Wondering now.. if it's possible to add continuum key expanding method looking at work done by Snrrrub.

Well I don't understand this key expanding seems like a bunch of random stuff..
In Continuum 0.40.. seems these offets are pretty important.
0x00457D60
0x00458E90

which generate the scrty and scrty1

Code: Show/Hide

sub_457D60((void **)&v9, 0, 612215210); //modified MD5
sub_458E90(&v9, -1439978213);

those two methods seem pretty complicated shit..

they work by modifying a DWORD at a time and rotating the bits left.
After much examination it just looks like !MODIFIED MD5!.

if you look at this, you can do a quick analysis and see this

Code: Show/Hide

void *__userpurge sub_457D60<eax>(void **a1<ecx>, int a2<ebx>, int a3)
{
..
v8 = __ROL__(*(_DWORD *)*a1 - 681945657, 7);
v8 -= 271734071;
v9 = __ROL__((v8 & 0xEFCDAAC9 | ~v8 & 0x98BACD4E) + *((_DWORD *)*v6 + 1) - 107344724, 12);
v10 = v8 + v9;
v11 = __ROL__((v8 & v10 | ~v10 & 0xEFCDAAC9) + *((_DWORD *)*v6 + 2) - 1126481991, 17);
v12 = v10 + v11;
v13 = __ROL__((v12 & v10 | v8 & ~v12) + *((_DWORD *)v3 + 3) - 1319441881, 22);
v14 = v12 + v13;
v15 = __ROL__(*((_DWORD *)v3 + 4) + (v14 & v12 | v10 & ~v14) + v8 - 177010401, 7);
v16 = v14 + v15;
v17 = __ROL__(*((_DWORD *)v3 + 5) + (v16 & v14 | v12 & ~v16) + v10 + 1200080794, 12);
v18 = v16 + v17;
v19 = __ROL__(*((_DWORD *)v3 + 6) + (v16 & v18 | v14 & ~v18) + v12 - 1472706653, 17);
v20 = v18 + v19;
v21 = __ROL__(*((_DWORD *)v3 + 7) + (v20 & v18 | v16 & ~v20) + v14 - 45706063, 22);
v22 = v20 + v21;
v23 = __ROL__(*((_DWORD *)v3 + 8) + (v22 & v20 | v18 & ~v22) + v16 + 1753258344, 7);
v24 = v22 + v23;
v25 = __ROL__(*((_DWORD *)v3 + 9) + (v24 & v22 | v20 & ~v24) + v18 - 1958414817, 12);
}

If you know how MD5 works.. you can quickly spot.. It uses MD5 variant.

Okay so the expansion of encryption/decryption keys of continuum 0.40 is MD5 variant..

Anyone ported this yet?? (to save me time) or should i do it.[/code]

Dr Brain - Sat Sep 03, 2011 8:09 am
Post subject:

No one is going to help you destroy the last thing keeping this game alive, no.

Anonymous - Sat Sep 03, 2011 3:34 pm
Post subject:

Excuse me? i'm doing this for a education purpose and for my own private use.

Whatever i'll keep stepping asm line by line until I figure it all out.

What am i doing wrong lol? instead of making a shitty bot with obsolete subspace encryption.. i'm going with a more modern approach.

Dr Brain - Sat Sep 03, 2011 5:43 pm
Post subject:

I didn't say don't do it. I said we won't help you.

Please don't release your findings if you do break the encryption, as it's the encryption is the only thing standing in the way of widespread cheating. With PriitK effectively dead, we can't expect a client update.

Oh, and don't use this in a zone you don't have control over, as you will probably wind up netbanned for life. Zone operators are not forgiving in these things. Just a friendly warning to hopefully keep you out of trouble.

Anonymous - Sat Sep 03, 2011 10:09 pm
Post subject:

I am not going to use this for cheating.. I'm not modifying the client in any way.. I am just creating a AI player whats the wrong with this? it will just be a player.

Well okay i won't release this information but maybe something to help me save time?.

Ehh okay no one will help me here.. it's okay meh I always liked doing things on my own anyways

cycad - Sun Sep 04, 2011 4:43 am
Post subject:

Displaying irresponsibility by testing against a zone you don't control, using what's presumably a pirated copy of hex-rays, and openly discussing the Continuum protocol puts your trust factor at about zero.

Regardless, the 'more modern' approach you claim to be after is to use ASSS anyway. The Continuum protocol isn't going to get you anything more than the SubSpace protocol will unless you're prepared to reverse engineer Continuum-only packets, and based on the questions above, it would take you a prohibitively long amount of time.

For doing AI you need access to the game events and the SubSpace protocol gives them to you. The protocol you use shouldn't affect your design anyway, making a protocol swap down the road easy. Take the path of least resistance and use the SubSpace protocol if you want results.

Anonymous - Sun Sep 04, 2011 6:09 pm
Post subject:

Meh i'm 70%~ down stepping all possible cases in continuum key expansion

Each DWORD expand is handled by 10 cases.. each case has 4 function calls.. (this requires alot of calculator work as you cannot step continuum directly). Why? because Prittk or whatever.. really made it clever and instead of putting like CALL Address.. he somehow encoded the address and now it looks like CALL EAX, so just have to go back a few lines and figure it out.

so 10 cases.. each has 4 function calls.. (4th function call) goes into another huge function with 10 more cases in it.. and each of those 10 cases has 4 functions.. seems huge as hell!. Probably looking at about 5000~6000 C# lines of code.

Judging by the community in the continuum world.. not many people will even find the continuum key thingy important.. lets be honest most of the people here how to even code.

Anonymous - Sun Sep 04, 2011 7:12 pm
Post subject:

I'd like to add more unfortunately I cannot edit, my post

You say changing encryption down the road is no big deal.. sure it's not but whats the point in testing your bot which you are hoping to make AI in with no players.. trick is to make it learn from multiple obstacles (players). As for making it in subspace encryption to connect to ASSS zones?? well.. Hyperspace isn't a good zone for testing on.. have to buy ships.. and such plus who will switch to ASSS zones? certainly not the top zones like TW/EG.

Continuum Packet reversing is a simple task, but most of the packets are the 1.35 subspace packets correct? I don't really care about the new packets they added to continuum.. I'm just looking for weapons packet, rotation/movement of player ship's on screen packet..

I could save myself ALOT of time.. and just hook continuum's client structs for each player and get this information.. but then i'll have to be depended on continuum client..

presumably i'm using a pirated copy of hex-rays? I've been using hex-rays since 2007.. and I find it easier to see whats going on.. then reading the equivalent assembly code which in most cases is triple the size.

What you mean irresponsibility testing against a zone I don't control? umm.. will this bot crash the server? Probably not.. and if it does.. then hell they gotta fix the server software so that doesn't happen.. I'll try to emulate continuum as best I can..

I understand what you mean by `cheating` as in if I don't send death packet for example, I won't die.. and probably eat on other persons screen I'll try my best to make it as legit and follow server settings as best as possible so yes I am suppose to die in the game.

This is a fun experience.. usually when I trace the recvto/recv/send/sendto.. and end up with encrypt/decrypt functions. They are usually just one function.. but continuum really went all out and spread it all around with like 40 functions maybe 80? (not sure yet)..

Just remember that cheating is against the rules in any of the servers you play.. so they could ban you.

P.S.> you say I am irresponsible, yet you see i'm doing some progress and refuse to aid/help me.. this doesn't serve good on my part.. I'm doing all this hard work which I believe you guys did before.. so you can just share it with me to let me end it quicker..

Then again.. I'm probably if this doesn't work..

i'll copy/paste all the assembly code with Code Ripper (olly debug plugin) then run it with proper parameters such as buffer,key and make sure the register flags are all identical.. which pretty much will save me like 3 days of work and will work 100%.

Anonymous - Tue Sep 13, 2011 10:41 pm
Post subject:

I give up

lol, i'm not capable of doing this myself, you guys win

Cheese - Wed Sep 14, 2011 8:32 pm
Post subject:

if you are sincerely interested in making an AI bot, you wouldnt mind

making your ai bot using mervbot or twcore with permissions to play
or

making an asss zone and writing server side ai bots

and if you are interested in the second, you would be very interested in THIS,
which is something that handles everything you need to make an ai bot, and you just write your ai in.

but i have connections to many players in many zones, and i have heard that this might not be your intention

Anonymous - Sat Sep 17, 2011 4:29 am
Post subject:

lol my problem now isn't the continuum encryption it's how the packets work even decrypted they are so crazy and follow 4 different formats.

Reliable message I like best.. but I can't always depend on it.. as some of the packets come in what looks like malformed.. because they came in using either this small chunk body format or huge chunk (which is very problematic.. the huge chunk packet, the first 4 bytes after opcode/crc ofcourse are suppose to be the same as the size of remaining incoming data minus the data the came in of the huge chunk data.. but after doing like

BitConverter.ToUInt32(data, 2); [3th byte from packet.. [first being the crc checksum.. second being the opcode 0x0A (huge chunk packet).. I was thinking maybe endianness problem, so I tried resorting the bytes in the opposite position then running BitConverter.ToUint32() no change still some unpredictably huge number

I get a value like 1 billion sometimes 700k.. lol no packets can come in that huge.... thats like half a megabyte maybe more of packetdata, so I rely on 0x0C to come in (cancel the huge chunk) and it sometimes does.. (but I think it comes in because of malformed packet.. or some bad packet handling I got here.. Small Chunk packets also all predictions..

sometimes the small chunk tail comes in.. and I combine the whole all the packets that came in with small chunk's before and send it all as one huge packet for processing.. (sometimes tail never comes, nothing I can work with, very shitty).

Cluster packets the 4th system.. which pretty much cannot exceed one packet which can be the 520 bytes.. is pretty easy to handle.. it's pretty much always works properly.. I used to get OutOfRangeExceptions due to malformed packets but no problem.. seems fixed properly..

Code: Show/Hide

switch(data[0]) {
.....
case 0x0E: //cluster packet:
try
{
int size = 0;
int countChecked = 1;
do
{
size = data[countChecked + 1];
if (size > countChecked + data.Length) break;

byte[] littlePacket = new byte[size];
Array.Copy(data, countChecked + 2, littlePacket, 0, size);
Client2ServerPacketProcessing(littlePacket);
countChecked += size + 1;
} while (countChecked + 1 < data.Length);
}
catch (IndexOutOfRangeException ioore) { }
break;
}

Pretty much those chunk packets giving all the problems.. I wonder why.. I checked all sources MervBot.. they all got their own things nothing I am not doing differently..

Except maybe packets with bad CRC's I should dispose? if I do that.. I dispose probably 40% of all packets.

This makes me think maybe when a chunk packet started.. it has no opcode and maybe no crc byte at all.. just plain random bytes which I keep appending to some buffer until.. either size is reached.. or tail is reached for small one.

I will keep at this problem atleast.. I'm experimenting with my own zone should show 0 packetloss.. which would probably mean no malformed packets.. and a very stable flow of packets to organize with..

ACK packets.. don't come in order which is pretty fun to watch.. kinda like asynchronous sockets

Cheese - Sat Sep 17, 2011 2:02 pm
Post subject:

probably downloading news.txt or lvl

Anonymous - Sat Sep 17, 2011 8:48 pm
Post subject:

Nope.. I downloaded the map, news and I am getting Position Packet while being in spec.. I guess that's normal..

(note this is my own zone, I have no lvz's or anything).. after like 30 seconds in zone.. Position Packets stop coming in.. and a huge chunk packet starts out of nowhere.. I do believe this is just position packets that probably got malformed or something with Huge Chunk packet opcode.. But whats strange.. Size keeps going up... everytime I download bytes.. lol wtf!

data is byte array of RAW packet from server.. just after being decrypted. first byte is CRC probably always zero..

Code: Show/Hide

switch (data[1])
{
case 0x0A: //huge chunk
if (data.Length >= 7)
{
C2SHugeChunkSize = BitConverter.ToUInt32(data, 2);

Console.WriteLine("[C2S]: Size = " + C2SHugeChunkSize + " bytes: so far " + C2ShugeChunkPacket.Count + " bytes");
//int size = BitConverter.ToUInt16(data, 4);

if (data.Length - 6 > 0)
{
byte[] hugeChunkData = new byte[data.Length - 6];
Buffer.BlockCopy(data, 6, hugeChunkData, 0, data.Length - 6);
C2ShugeChunkPacket.AddRange(hugeChunkData);

if (C2SHugeChunkSize == C2ShugeChunkPacket.Count)
{
Client2ServerPacketProcessing(C2ShugeChunkPacket.ToArray());
C2ShugeChunkPacket.Clear();
}
}
}
else
{
Console.WriteLine("Malformed big chunk ignored.");
}
break;