KR 2.48.0.3+ / 2D 6.0.5.0 changes
KR 2.48.0.3+ / 2D 6.0.5.0 changes
Hello to all. I read several posts on runuo.com and laughed very much. So i have made a decision to share information about new changes. Changes were made both for 2D and KR authorization.
Here is article with required code for RunUO 2.0: http://ruosi.org/publ/1-1-0-3
Good luck.
Here is article with required code for RunUO 2.0: http://ruosi.org/publ/1-1-0-3
Good luck.
Faster core, many features and much more - www.runuo.com . Ask Ryan.
For beginners:
http://rapidshare.com/files/71918894/Ru ... 0.rar.html
Clean SVN 265 RunUO 2.0 with required changes and compile.bat for compilation.
1. run compile.bat
2. move server.exe to your server directory
3. run server
3. use uorice from archive to remove crypt from client.exe (6.0.5.0)
4. connect with no_crypt_client_2d.exe to your server.
Warning: RAZOR WILL NOT WORK, DON'T USE IT
http://rapidshare.com/files/71918894/Ru ... 0.rar.html
Clean SVN 265 RunUO 2.0 with required changes and compile.bat for compilation.
1. run compile.bat
2. move server.exe to your server directory
3. run server
3. use uorice from archive to remove crypt from client.exe (6.0.5.0)
4. connect with no_crypt_client_2d.exe to your server.
Warning: RAZOR WILL NOT WORK, DON'T USE IT
Faster core, many features and much more - www.runuo.com . Ask Ryan.
Yeah, i used Ethereal and it's very easy change, but several posts from runuo.com 're killing menazghul hat geschrieben:Funny coincedence.
Last night I played around with 6.0.5.0, found it unable to log in (to Sphere, not RunUO), and asked TCPDump for assistance.
Well, the rest was a matter of 10 minutes (hey, my box isn't as fast while compiling!).

Faster core, many features and much more - www.runuo.com . Ask Ryan.
Well, I'll not talk bad about ppl. who are not here to defend themselves, and who I do not know (especially as they are working for/with a competing project
). Furthermore, I'm not reading at runuo.com (why should I?). But you're right, it's a little bit weird.
Perhaps it simply was not "their day"
BTW: Any ideas what significant changes 6.0.5.0 has, compared with 6.0.4.0 (apart from this login gibberish)?

Perhaps it simply was not "their day"

BTW: Any ideas what significant changes 6.0.5.0 has, compared with 6.0.4.0 (apart from this login gibberish)?
Yeah, i have only several times another value, so it is probably constant. May be it's count of packets. Last known is EDTwoUnknownGuys hat geschrieben:Is the first truly random? It was always EF during sniffing session... Anyway good job

Faster core, many features and much more - www.runuo.com . Ask Ryan.
No developer of RunUO made any post about this "issue". ;-)
It were all users with no or only little experience with UO packets.
Then it is no wonder they turn into "wild guessing mode".
But seeing these changes, i wonder what EA wants to achieve? Why would they need the version packet expanded to 21 bytes?
It were all users with no or only little experience with UO packets.
Then it is no wonder they turn into "wild guessing mode".

But seeing these changes, i wonder what EA wants to achieve? Why would they need the version packet expanded to 21 bytes?

Anyway, if you don't know the subject - you should not teach others and discuss 'weird' things.Sotho Tal Ker hat geschrieben:No developer of RunUO made any post about this "issue". ;-)
It were all users with no or only little experience with UO packets.
Then it is no wonder they turn into "wild guessing mode".![]()
What is version packet? They just added 17 bytes to seed. No one packet was added or changed.Sotho Tal Ker hat geschrieben: But seeing these changes, i wonder what EA wants to achieve? Why would they need the version packet expanded to 21 bytes?
Faster core, many features and much more - www.runuo.com . Ask Ryan.
well, seeing that they finally just added 4 longwords holding the client version - what also may be placeholders, of course - perhaps they also had problems with the 6.0.1.6/7 change where it was impossible to determine for the server _what_ client tries to connect (what was important due to the backpack grid position they added). And they want to be prepared for the next time 

Hi all! Here is my little contribution 
If you want your RunUO 2.0 SVN Rev 265 to get client version of new clients from the new packet, you have to do this:
1) Apply the changes posted by Wyatt to support 6.0.5.0 client.
2) Open Server/Network/MessagePump.cs and replace this:
with this:
If you use RunUO-Encryption 2.2 pack by Sebastian Hartte (DarkStorm) to support OSI-Encrypted clients, you would want to support also encrypted 6.0.5.0 clients. You have to do this:
1) First of all, add support for last RunUO 2.0 SVN. Open Scripts/Engines/Encryption/Encryption.cs and replace this:
with this:
2) Now the real support for the new seed packet. In the same file, replace this:
with this:
3) Finally, add this definition to Scripts/Engines/Encryption/Configuration.cs:
That's all, enjoy!

If you want your RunUO 2.0 SVN Rev 265 to get client version of new clients from the new packet, you have to do this:
1) Apply the changes posted by Wyatt to support 6.0.5.0 client.
2) Open Server/Network/MessagePump.cs and replace this:
Code: Alles auswählen
int seed = (m_Peek[0] << 24) | (m_Peek[1] << 16) | (m_Peek[2] << 8) | m_Peek[3];
Code: Alles auswählen
int seed = 0;
if ( seed_length == 4 )
{
seed = ( m_Peek[0] << 24 ) | ( m_Peek[1] << 16 ) | ( m_Peek[2] << 8 ) | m_Peek[3];
}
else if ( seed_length == 21 )
{
seed = ( m_Peek[1] << 24 ) | ( m_Peek[2] << 16 ) | ( m_Peek[3] << 8 ) | m_Peek[4];
ns.Version = new ClientVersion( m_Peek[8], m_Peek[12], m_Peek[16], m_Peek[20] );
}
1) First of all, add support for last RunUO 2.0 SVN. Open Scripts/Engines/Encryption/Encryption.cs and replace this:
Code: Alles auswählen
if (((IPEndPoint)from.Socket.LocalEndPoint).Port != Listener.Port)
{
m_Encryption = new NoEncryption();
return;
}
Code: Alles auswählen
bool handle = false;
for ( int i = 0; i < Listener.EndPoints.Length; i++ )
{
IPEndPoint ipep = (IPEndPoint) Listener.EndPoints[i];
if ( ((IPEndPoint)from.Socket.LocalEndPoint).Port == ipep.Port )
handle = true;
}
if ( !handle )
{
m_Encryption = new NoEncryption();
return;
}
Code: Alles auswählen
if (!m_Seeded)
{
// Now check if we have at least 4 bytes to get the seed
if (m_Buffer.Length >= 4)
{
byte[] m_Peek = new byte[m_Buffer.Length];
m_Buffer.Dequeue( m_Peek, 0, m_Buffer.Length ); // Dequeue everything
m_Seed = (uint)((m_Peek[0] << 24) | (m_Peek[1] << 16) | (m_Peek[2] << 8) | m_Peek[3]);
m_Seeded = true;
Buffer.BlockCopy(m_Peek, 0, buffer, 0, 4);
length = 4;
}
else
{
return;
}
}
Code: Alles auswählen
if (!m_Seeded)
{
int seed_length = m_Buffer.GetSeedLength();
if (m_Buffer.Length >= seed_length)
{
byte[] m_Peek = new byte[m_Buffer.Length];
m_Buffer.Dequeue( m_Peek, 0, seed_length );
if ( seed_length == 4 )
m_Seed = (uint) ( ( m_Peek[0] << 24 ) | ( m_Peek[1] << 16 ) | ( m_Peek[2] << 8 ) | m_Peek[3] );
else if ( seed_length == 21 )
m_Seed = (uint) ( ( m_Peek[1] << 24 ) | ( m_Peek[2] << 16 ) | ( m_Peek[3] << 8 ) | m_Peek[4] );
m_Seeded = true;
Buffer.BlockCopy(m_Peek, 0, buffer, 0, seed_length);
length = seed_length;
}
else
{
return;
}
}
Code: Alles auswählen
new LoginKey( "6.0.5", 0x2E0B97AD, 0xA210DE7F ),
I just can't get this to work, I've tried everything. Out of all the packet changes EA made this must be the most complex one since the others I've figured out WAY before RunUO did.
Can someone shed some light on exactly what packet size was made bigger so I can just increase the value in the packet handler?
I've also added that new EF handler, no luck there either. At one point I got it working, but I had to initiate a login, hit back, then try again. But now when I do that it just says encrypted client detected. I have this:
if ( !ns.SentFirstPacket && packetID != 0xF0 && packetID != 0xF1 && packetID != 0xCF && packetID != 0x80 && packetID != 0x91 && packetID != 0xA4 && packetID != 0xEF)
I don't care about backwards compatibility, so I don't need anything fancy, just pure packet info.
edit: ok think I may have figured it out, testing stuff now, here is info I've found:
ok still not wrking. I need to somehow tell the first buffer to seek till 21, just can't seem to figure out where it gets 4 from. I did all required changes in messagepump.cs
Can someone shed some light on exactly what packet size was made bigger so I can just increase the value in the packet handler?
I've also added that new EF handler, no luck there either. At one point I got it working, but I had to initiate a login, hit back, then try again. But now when I do that it just says encrypted client detected. I have this:
if ( !ns.SentFirstPacket && packetID != 0xF0 && packetID != 0xF1 && packetID != 0xCF && packetID != 0x80 && packetID != 0x91 && packetID != 0xA4 && packetID != 0xEF)
I don't care about backwards compatibility, so I don't need anything fancy, just pure packet info.
edit: ok think I may have figured it out, testing stuff now, here is info I've found:
Code: Alles auswählen
old client
send 4 bytes: IP address
send 62 bytes: initial login
Receive 86 bytes: server list
new client:
send 1 byte: 0xEF
send 82 bytes: login
(stuck)
login old: 62 bytes
0000 80 stuff00 00 00 00 00 00 00 00 00 00 00 .stuff...........
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 62 ...............b
0020 stuff 00 00 00 00 00 stuff.....
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 5d .............]
login new: 82 bytes (first 20 bytes should actually be another packet including seed - index 1 to 4 is seed (matches my ip of 10.1.1.20)
0xEF sent before, then this:
0000 0a 01 01 14 00 00 00 06 00 00 00 00 00 00 00 05 ................
0010 00 00 00 00stuff00 00 00 00 00 00 00 .....stuff.......
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030 00 00 00stuff 00 ...stuff.
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00
FIXED!
replace
with
Old one only handles login server, but does not handle logging in to the actual server (the seed is still 4 bytes for the 2nd login stage)
This checks if the login stage is 1st or 2nd.
Only thing that makes me nervous with this fix is someone mentioned that 0xEF was actually not always 0xEF.... can someone confirm this? I have only seen it as 0xEF so far. But nothing says that will change next update....
Also this fix wont work with encryption support, but probably need a fix of some sort to encryption support. I don't really support encryption on my shard anyway, it was more experimental, so I just disabled it.
Full fix here: http://www.uovalor.com/forum/viewtopic.php?p=11331
(pretty sure thats everything lol)
replace
Code: Alles auswählen
public int GetSeedLength()
{
if ( m_Buffer[4] == 0x80 ) // we need this check for old clients
return 4;
return 21;
}
Code: Alles auswählen
public int GetSeedLength()
{
if ( m_Buffer[0] == 0xef ) // we need this check for old clients
return 21;
return 4;
}
This checks if the login stage is 1st or 2nd.
Only thing that makes me nervous with this fix is someone mentioned that 0xEF was actually not always 0xEF.... can someone confirm this? I have only seen it as 0xEF so far. But nothing says that will change next update....
Also this fix wont work with encryption support, but probably need a fix of some sort to encryption support. I don't really support encryption on my shard anyway, it was more experimental, so I just disabled it.
Full fix here: http://www.uovalor.com/forum/viewtopic.php?p=11331
(pretty sure thats everything lol)