Investigation: Razor packet-logs from UOX3 and RunUO

Post by **Xuri** » Fri Jan 02, 2009 6:10 am

I've logged some packets of character creation + logging in with existing characters and walking around a bit, first using client 6.0.1.7 and UOX3 0.98-3.7t, then using the patched up client - version 6.0.12.3 - and RunUO.

Here are the logs. Feel free to take a look and see if you can figure out why the latest client versions work with RunUO but not with UOX3.

Hopefully someone can figure it out...

Jediman · Post by **Jediman** » Fri Jan 02, 2009 4:23 pm

Doesn't it have something to do with the way RunUO handle ecnryption?
There is some sort of file they use to allow for new clients that don't even have it removed I think...

I think I asked this before but what does UOX3 do when listening for the packets? How does it process them in the packets code? Is there an exception we can add to simply allow for newer clients?

Post by **Xuri** » Fri Jan 02, 2009 6:46 pm

Well, RunUO can handle encrypted clients - but only with an addon/mod. Default RunUO needs to have the encryption removed before it will communicate with the client, just like UOX3.

I've never had much understanding of how exactly the packet-stuff works, so can't give you an answer there, sorry. :/

Post by **Xuri** » Sat Jan 03, 2009 2:22 pm

Ooh! Ahh! Interesting!
I installed a trial copy of Visual Studio 2008 on my laptop (only thing i have accessible right now), poked around in the uox3 source for a bit, and figured out the following:

If I comment out lines 988 through 998 in network.cpp, aka the following bit of code:

Code: Select all

			if( mSock->FirstPacket() && packetID != 0x80 && packetID != 0x91 )
			{
				// April 5, 2004 - EviLDeD -  Hmmm there are two of these ?
				if(cwmWorldState->ServerData()->ServerUOGEnabled())
					sprintf( temp, "UOG Stats Sent or Encrypted client detected. [%i.%i.%i.%i]", mSock->ClientIP4(), mSock->ClientIP3(), mSock->ClientIP2(), mSock->ClientIP1() );
				else
					sprintf( temp, "Encrypted client detected. [%i.%i.%i.%i]", mSock->ClientIP4(), mSock->ClientIP3(), mSock->ClientIP2(), mSock->ClientIP1() );
				messageLoop << temp;
				LoginDisconnect( s );
				return;
			}

... then attempting to login once will give you a packet error message in the UOX3 console window, and attempting a second login right after that will allow you to login.

I'm now running around in UOX3 0.98-3.7u using client version 6.0.12.3, and it seems to be working alright!

The weird thing is that the code-bits above should only run if the first packet received from the client is != 0x80 - which shouldn't happen as the first packet sent to the server (according to the Razor packetlogs I'm getting) is packet 0x80. However, in MSVC, "packetID" is displaying a value of 255 'ÿ'. (0xFF?)

*scratches beard and looks around for giwo, grimson or maarc*

Post by **Xuri** » Sat Jan 03, 2009 2:37 pm

Hm not all is well even after being able to login though - if I login with an existing character, it seems to work okay. If I login with a brand new character, it freezes after a few steps - status gump never loads, no paperdoll, etc. This is not unique to the most recent versions, however, it also happened to me in client version 6.0.1.7, I think it was.

Packetlogs from Razor shows that the client keeps sending the following (with some variations) repeatedly without ever getting a reply from the server:

13:42:38.7031: Client -> Server 0xBF (Length: 6)
0 1 2 3 4 5 6 7 8 9 A B C D E F
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000 BF 00 06 00 24 6E ....$n

13:42:40.2343: Client -> Server 0x02 (Length: 7)
0 1 2 3 4 5 6 7 8 9 A B C D E F
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000 02 04 00 00 00 00 00 .......

13:42:40.6875: Client -> Server 0x02 (Length: 7)
0 1 2 3 4 5 6 7 8 9 A B C D E F
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000 02 04 01 00 00 00 00 .......

13:42:41.0781: Client -> Server 0x02 (Length: 7)
0 1 2 3 4 5 6 7 8 9 A B C D E F
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000 02 04 02 00 00 00 00 .......

13:42:41.4843: Client -> Server 0x02 (Length: 7)
0 1 2 3 4 5 6 7 8 9 A B C D E F
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000 02 04 03 00 00 00 00 .......

13:42:42.2031: Client -> Server 0xBF (Length: 6)
0 1 2 3 4 5 6 7 8 9 A B C D E F
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000 BF 00 06 00 24 59 ....$Y

13:42:46.8281: Client -> Server 0xBF (Length: 6)
0 1 2 3 4 5 6 7 8 9 A B C D E F
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000 BF 00 06 00 24 3F ....$?

13:42:51.2500: Client -> Server 0xBF (Length: 6)
0 1 2 3 4 5 6 7 8 9 A B C D E F
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000 BF 00 06 00 24 2E ....$.

Then it just keeps on sending the 0xBF packet, while seemingly "frozen".

Could it be that we don't have the complete changes when it comes to the "extra byte to some packets"-change that occured some time back? (Check the following uox3.org thread, and the following uodev.de thread (where the solution came up originally))

Maarc · Post by **Maarc** » Sun Jan 04, 2009 2:31 pm

I'll have a look at it when I have some real time. But yes, I suspect its the offset factor that is at work.

Jediman · Post by **Jediman** » Wed Jan 07, 2009 8:52 pm

Sweet, so now we are getting somewhere.

Xuri you just reminded me to install Vstudio 2k8 Pro on my desktop here

*starts installing and downloading source*

Jediman · Post by **Jediman** » Mon Jan 12, 2009 11:26 pm

I haven't had the chance to fire up Vstudio 2k8 on the desktop yet (that reminds me to patch it..ugh lol).

Anyone get any further with this?

Not that I advocate swiping code or anything but has anyone peered at RUO to see how they interepret the newer packets?

giwo · Post by **giwo** » Tue Jan 13, 2009 2:56 am

Isn't swiping code what open source is all about?

Post by **Xuri** » Tue Jan 13, 2009 3:01 am

I'd do it, but I don't read code well enough (especially code dealing with uo packets!) to understand what I'm seeing.

giwo · Post by **giwo** » Fri Jan 16, 2009 10:06 pm

Well I had a brief look at the packet logs, and they are quite different.

The first thing I noticed is RunUO is doing an early version request from the client, a packet UOX3 doesn't even currently have implemented. I went ahead and added handling for that packet, and dropped it in the character creation and play character routines.

Give it a try and let me know how it affects things (if at all).

Post by **Xuri** » Fri Jan 16, 2009 11:19 pm

Tested using UO version 6.0.12.3 (Patch 74) and used Razor 1.0.11 to remove the encryption and launch the client.

Unless I comment out the code I mentioned further up in the thread, I only get "Encrypted client detected" spam in the UOX3 console and am unable to login. If I comment out that code, I manage to log in after trying 3-4 times, usually allows me on after it spams a line like

WARNING: Bad packet request thrown! [packet ID: 0x64]

or

WARNING: Bad packet request thrown! [packet ID: 0xff]

After logging in I could create new characters and walk around just fine, paperdoll, backpack and everything - as well as log in with existing characters and do the same.

giwo · Post by **giwo** » Sat Jan 17, 2009 6:08 am

Ok, I stopped after the version packet, so I'll do a bit more inspection of the logs you posted.

Sounds like there is a new packet we aren't handling yet (that falls into the range we are using for that UOGateway packet).

giwo · Post by **giwo** » Sat Jan 17, 2009 10:40 am

Well I found the problem. Starting with client 6.0.6.0 (or possibly 6.0.5.0) and later, the OSI client is sending the following 21 bytes of data prior to the initial 0x80 packet

Code: Select all

0xef
0xc0
0xa8
0x01
0x67
0x00
0x00
0x00
0x06
0x00
0x00
0x00
0x00
0x00
0x00
0x00
0x06
0x00
0x00
0x00
0x01

The first 5 bytes (starting with 0xEF) are listed by RunUO as a seeding packet, though I don't really know what it is used for. The remaining 16 bytes I have no idea what purpose they serve, but I added some logic to look for the 0xEF packet, if found to skip ahead to the 0x80 packet for initial logon, and it seems to work.

I'll go ahead and commit my code, and see how things work on your end. PS please test the 6.0.1.7 clients with this as well, to ensure I didn't break backwards compatibility.

Post by **Xuri** » Sat Jan 17, 2009 4:56 pm

Well. Initial testing using 6.0.12.3 shows that it works 99% perfectly

For some reason, some times I have to try to login twice before I'm allowed onto the server. The first time it will just sit there on "verifying account" until I cancel and retry.

But definitely a huge step forward!

Edit: I've now also tested using v6.0.1.3 and v6.0.5.0, and it works with both of those as well! I don't have any client versions under 6.0.1.3, so can't test with any lower, though.

Ultima Offline eXperiment 3 forums

Investigation: Razor packet-logs from UOX3 and RunUO

Investigation: Razor packet-logs from UOX3 and RunUO