Titan Network
More Titan Projects => Icon => Topic started by: Joshex on December 26, 2014, 12:37:16 PM
-
So, a few days ago I decided to get Icon running, I know it's been a long time since it was released.
I just thought I'd say thanks for the efforts,
and of course ask some questions, not typical ones.
So, if you are aware I have a python server, I can control the message content entirely, so if I wanted to monkey with sending messages to the CoH Client, could I just target it? aka GameLogic.sServer.sendto('/loadmaps'+' '+'maps/....', C:/...../icon.exe)
I'm aware it uses a modified blowfish encryption key to communicate, but would it accept non-encrypted messages as well?
last question, where and how can I define the server IP in icon/dlls ETC.?
even receiving a single message from the client in my own server would be a huge step.
-
You ought to post this in the Icon forum. There are very helpful people, including Codewalker of course, there who might not see it here.
-
You ought to post this in the Icon forum. There are very helpful people, including Codewalker of course, there who might not see it here.
I looked for a forum devote to icon and didn't see one, link? is it on titan? can this thread be moved there?
-
-
-
Icon doesn't listen on the network. It specifically disables all client-server communications in order to get the game client running without a server, by overwriting the code for the network functions and making them return success without doing anything.
-
Icon doesn't listen on the network. It specifically disables all client-server communications in order to get the game client running without a server, by overwriting the code for the network functions and making them return success without doing anything.
Ah I see, So I'd have to monkey with the real client. If only I knew what IP addresses the client was trying to connect to, then I could make an outgoing router.
-
No need for a fancy intercept, it connects to whatever IP address you tell the client to connect to with the -auth command line parameter.
After authenticating, the auth server sends a list of shard numbers (that get turned into names like Freedom and Virtue by a lookup table in the client) with IP addresses and port numbers. Those IPs and ports are for the dbservers, and once you pick a shard from the list, the client attempts to communicate with whatever IP the authserver sent.
The dbserver in turn hands the client off to the appropriate mapserver after a character is selected, again sending an IP and port.
The dbserver and mapserver protocols are all UDP based, so they're not really "connections" on the OS level per se, as UDP is a connectionless datagram protocol. A server will have a single UDP socket open that packets from all clients arrive over. There is a pseudo-connection based on source IP and state however. The encryption is an optional feature bit and isn't required for the UDP protocol, but it's bog-standard Blowfish with a DH key agreement, so there's not much of a reason not to implement it.
SEGS has an implementation of the UDP protocol you can look at, though the content of the bitstreams has changed significantly between Issue 3 and Issue 24.
-
No need for a fancy intercept, it connects to whatever IP address you tell the client to connect to with the -auth command line parameter.
After authenticating, the auth server sends a list of shard numbers (that get turned into names like Freedom and Virtue by a lookup table in the client) with IP addresses and port numbers. Those IPs and ports are for the dbservers, and once you pick a shard from the list, the client attempts to communicate with whatever IP the authserver sent.
The dbserver in turn hands the client off to the appropriate mapserver after a character is selected, again sending an IP and port.
The dbserver and mapserver protocols are all UDP based, so they're not really "connections" on the OS level per se, as UDP is a connectionless datagram protocol. A server will have a single UDP socket open that packets from all clients arrive over. There is a pseudo-connection based on source IP and state however. The encryption is an optional feature bit and isn't required for the UDP protocol, but it's bog-standard Blowfish with a DH key agreement, so there's not much of a reason not to implement it.
SEGS has an implementation of the UDP protocol you can look at, though the content of the bitstreams has changed significantly between Issue 3 and Issue 24.
Thanks for the info!, when I find time I'll give it a go I assume cityofheroes.exe is the target for -auth ? and -authIP or -auth IP or -auth [IP]? no doubt it goes in the Target: listing after the file location?
as for encryption I think for datagram testing purposes I wont be trying to use it, after all when you make your own server from scratch it means programming encryption yourself. I will eventually make an encryption method for the project bane server probably just [message, key offset] (where key-offset is random 1 to 26 each time a message is sent) but for now I need things to work without it.
phishing this should be easy with the info given, heh;
try:
RESP = GameLogic.sClient.recvfrom(1024)
UPData = loads(RESP)
Open('textfile'+random number+'.txt', 'w').write(UPData)
then I can see what it asks when and prepare responses for it. indeed your info was very helpful even if it is the messaging process for issue 3.
there is only one foreseeable problem with my plan, I can definitely mimic the server, but without the map models the server would just either have everyone fall or people will walk through buildings. I suppose I could program spawn-able and movable walls into the server client then get them to where there's a wall in game and save the server file and reload, but then there's odd geometry like Atlas...
it's gonna be a lot of work either way, I make it sound a lot easier than it probably will be. I think I'll make this a Second side project.
oh well I'm rambling. Thanks again for your help Codewalker! and thanks for Icon, I just had to play on the skii slopes in pocket D this holliday and with icon I was able.