Supporting OSI Client Encryption [Ver 1.0]

[darkstorm]

This script will allow you to support unmodified clients.

A README file is included in the zip and also an utility to automatically extract the encryption keys from a client.

The script and the program are released under the GPL.

No core modifications are required yet. But because of an upcoming change in the official core (PacketEncoder will be changed from a static to an instance member), i am planning to modify the script accordingly and make the 2-line change to the core public. (Since it will improve the performance significantly).

Currently there is only one issue known to me:
Encryption contexts will not be cleaned up correctly if a NetState is disconnected. There is no reliable callback for a disconnecting socket, so it's only possible with some sort of manual garbage collection. It is highly likely though, that certain Contexts will be reused since i use the OS Socket handle as the key to identify the context.
This issue will resolve itself with the next version of the core or the 2 line core mod mentioned above.

NOTE ON VERSION 2.0:
I added the encryption keys for clients 3.0.5 trough 5.0.1 to the configuration. If you find any errors please report them here.

Version 2 requires you to modify your core if you are using RunUO 1.0. Information on how this can be done and also a precompiled version of RunUO 1.0 with the change can be found here:
Making NetState.PacketEncoder an instance member instead of a static class member.
The change allows the encryption to store its context information directly with the NetState instead of a Hashtable. That increases performance and also removes the problem of cleaning up the hashtable when a NetState disconnects. The change has been accepted into the next official RunUO version. Version 2.0 of this script should work with an unmodded RunUO 2.0 once it's out.

NOTE ON VERSION 2.1:
A bug with UOGateway stat request packets and the remote admin interface has been fixed.

NOTE ON VERSION 2.2:
Added encryption keys for client 5.0.2.

cu,
darkstorm

[Nuts&Bolts]

Very nice work. I was wondering when some one would come up with some thin like this. Thanks

[PerfectWing]

Well, it's not like it's impossible to get ahold of the developers when someone wants to go out on a limb for something like this. He probably, I don't know, asked?

Nice, darkstorm, I think. :|

[PerfectWing]

I've never had much beef for getting information related to such things in the past.

[cfaust]

Very nice darkstorm; you wanted it, you coded it, you submitted it very nice indeed. This is a great example of community and sharing.

[darkstorm]

Originally Posted by Phantom

Wonders how you know whats being changed in the core.

I talked to one of the developers and he said the change is in.

[darkstorm]

Oh what i forgot to clear up:
This does not remove support for unencrypted clients. It just adds support for encrypted ones. If you dont want unencrypted clients with this system, you can disable them in the Configuration.

[poetawd]

DUDE, this is AWESOME !!!


REALLY!!!!


Thanks for sharing! It is already in use in my shard!!!

You saved me a lot of time! because I was tired of teaching NEWBIES how to use UOGATEWAY or RAZOR !!

Thank you !!

[darkstorm]

Originally Posted by poetawd

DUDE, this is AWESOME !!!


REALLY!!!!


Thanks for sharing! It is already in use in my shard!!!

You saved me a lot of time! because I was tired of teaching NEWBIES how to use UOGATEWAY or RAZOR !!

Thank you !!

Well if you have any feedback it would be nice to post it here. I am highly interested in bug reports. Oh and i highly suggest you upgrade to the version with the core mod if you can do so (I will provide a compiled excutable for that), it really helps performance.

[darkstorm]

Updated the script to 2.0:
- Included encryption keys for clients 3.0.5 to 5.0.1
- Removed the Hashtable for encryption contexts
- Now requires a 2-line modification to the core:
http://www.runuo.com/forum/showthread.php?p=463154
(A precompiled version is included there)

If you don't want to modify your core, use version 1.0 (You can copy the Configuration.cs from 2.0 over if you want more encryption keys). I highly recommend the modification though, since it improves performance and reduces memory usage.

Please note that the core change has been accepted into the next release of RunUO, so the modification will only be neccesary until the next version of RunUO has been released.

[Ryan]

Nice work ds

Thanks for a very nice contirbution.

[Zero_X]

Awesome job indeed ;D

[Oliver]

great work darkstorm.

I may have found a bug though.
in the Encryption.DecodeIncomingPacket method, when the very first data comes, you're getting the seed out of it. So you dequeue everything from the temp bytequeue, get the seed, but then you do not re-enqueue the rest of the data. I.e. if the seed comes bundled with the first packet, the packet could get forgotten.
Maybe there are other mechanisms that would hinder that, but in this particular method it's wrong I think...

so I think a line like this should be added
m_Buffer.Enqueue(m_Peek, 4, m_Peek.Length-4); (Encryption.cs, line 135)

...or maybe just the first 4 bytes should be dequeued in the first place.

[QuIcK_FiNgErS]

Hmm, Im gonna show some ignorance here. But I generally dont know something so im gonna ask.

I dont get the whole client encryption thing. What is it?
I see this script released and an immediate great response, even Ryan's there.

I dont mean to sound like a dick but "whats the big deal"


I hereby permit people to flame me lol

[Sotho Tal Ker]

Originally Posted by QuIcK_FiNgErS

Hmm, Im gonna show some ignorance here. But I generally dont know something so im gonna ask.

I dont get the whole client encryption thing. What is it?
I see this script released and an immediate great response, even Ryan's there.

I dont mean to sound like a dick but "whats the big deal"


I hereby permit people to flame me lol

It just means that you don't need to use Razor/UO Gateway/UO Rice to edit your Ultima Online executable to play on freeshards. You can just play UO "out of the box" after changing the login.cfg (which can be easily done by hand).
So to play on an exact osi clone without any custom graphics (mobs, statics, items, hues, multis) you just need to provide a download to a modified login.cfg (which is generally smaller than 200 bytes). That relieves new gamers out of the difficult process in setting up programs like UOG or Razor or UO Rice. (No need to tell them to use this and that and giving out links to the programs, and I personally know how much problems you can have explaining a new player how to do make it work).
Please note that UO Gateway and Razor provide other functionality besides encryption removing, but not everyone uses them.

[darkstorm]

Originally Posted by Oliver

great work darkstorm.
I may have found a bug though.
in the Encryption.DecodeIncomingPacket method, when the very first data comes, you're getting the seed out of it. So you dequeue everything from the temp bytequeue, get the seed, but then you do not re-enqueue the rest of the data.

I previously did that. But actually i don't need to enqueue the first 4 bytes. Initially RunUO calls the read function on the socket for exactly 4 bytes. That means that the first chunk of data will _always_ be 4 bytes and never more than that. So basically it could be made an assumption and the enqueue-ing could be removed for seeding at least. For the automatic detection of the encryption method i think i could lower the size of the buffer to 128 byte or something like that since the only packets that should be received initially are 0x80/0x91 (62 and 65 byte respectively) and possibly the ping packet (0x73 which is 2 or 3 bytes). Would further reduce the memory consumption of the encryption.

[darkstorm]

Originally Posted by Sotho Tal Ker

It just means that you don't need to use Razor/UO Gateway/UO Rice to edit your Ultima Online executable to play on freeshards. You can just play UO "out of the box" after changing the login.cfg (which can be easily done by hand).
So to play on an exact osi clone without any custom graphics (mobs, statics, items, hues, multis) you just need to provide a download to a modified login.cfg (which is generally smaller than 200 bytes). That relieves new gamers out of the difficult process in setting up programs like UOG or Razor or UO Rice. (No need to tell them to use this and that and giving out links to the programs, and I personally know how much problems you can have explaining a new player how to do make it work).
Please note that UO Gateway and Razor provide other functionality besides encryption removing, but not everyone uses them.

That is exactly the case. In addition to that, if your shards wants to modify a LOT of data and wants to use a custom patcher/login program for that purpose, having to use a third party program in between makes things a lot more complicated and annoying to the players (since the admin can't legally distribute UOG and those tools). Encryption support in the server eliminates that need since an unmodified client can log in directly.

[pinco]

I found a problem with that script...
The remote admin not work with that script installed...
This is a very good script I like to use this, but I need remote admin for the server connection... there are any solution? :P

The probelm is these lines:

// If it's still not initialized, copy the data back to the queue and wait for more
//				if (m_Encryption == null) 
//				{
//					m_Buffer.Enqueue(buffer, packetOffset, packetLength);
//					length -= packetLength ;
//					return;
//				}

I have leave it for make it work...

[floppydisc]

Well the RemoteAdmin issue could be a problem of the RemoteAdmin client (assuming you are talking about my submission in the third party forum). I'm currently sending the 4 byte integer (big-endian ofcourse) "1" (or in hex: 01 00 00 00) which was basicly meant as dummy packet so the server let me in Until now that didn't matter, as the seed was not really checked. Now that it is checked (and even used) I will most likely have to change this. So here is my question: what would be a valid seed?

[pinco]

the removing of this four lines not give problem and all type of client work, Remote Admin, client crypt and client decrypt... I think this is a good solution for optimize the script :-P

[darkstorm]

Originally Posted by pinco

the removing of this four lines not give problem and all type of client work, Remote Admin, client crypt and client decrypt... I think this is a good solution for optimize the script :-P

I am sorry but thats not an option. If the IP packet with the first login packet is fragmented, it wouldn't login otherwise. However there is another fix. I just didn't know NetState was also used for the Remote Admin.

*edit* Argh ok i have to revert my statement. What exactly is the difference between the original client and the remote admin client?

[darkstorm]

Resolved the remote admin problem in version 2.1.

I will leave version 1.0 as it is because that is meant for "demonstration" purposes. Any production shard should use the coremod and version 2.1.

*edit*
decided against leaving version 1.0 as it is. released version 1.1 which also includes the remote admin fix.

[floppydisc]

The remoteadmin protocol only uses packet 0xF1. Everything else is handled by the packethandler for 0xF1 (defined in Scripts/Engines/RemoteAdmin/Network.cs)

[darkstorm]

Originally Posted by floppydisc

The remoteadmin protocol only uses packet 0xF1. Everything else is handled by the packethandler for 0xF1 (defined in Scripts/Engines/RemoteAdmin/Network.cs)

Yes only the first packet had any relevance. I used the 0xf1, 0x00, 0x40 start of the packet to identify your remote admin tool.
As posted above that fixed it for me.

[Joeku]

Sweet. Good job!