Trying to understand a bit more about about the RC5 5187 Acc-Client password decryption process

21
Spirited wrote: Mon May 17, 2021 2:16 am So when decoding the message, Comet only skips in 7 bytes before it reads in the length. So perhaps you're skipping that? See here: https://gitlab.com/spirited/comet/-/blo ... ake.cs#L65
Perhaps I didn't articulate this well sorry - This is the start of the DH handshake. The client disconnects the moment it receives the first DH Exchange packet after initially connecting to the Game server.

I copy pasted a sample from a revised 5165 COEmu source to ensure I wasn't doing something incorrectly. As far as I know nothing about the DH exchange changed between 5165 and 5187 -> even when performing the query with the packet structure below:

Code: Select all

            var random = new System.Random();
            int PAD_LEN = 11;
            int _junk_len = 12;
            string tqs = "TQServer";
            MemoryStream ms = new MemoryStream();
            byte[] pad = new byte[PAD_LEN];
            random.NextBytes(pad);
            byte[] junk = new byte[_junk_len];
            random.NextBytes(junk);
            int size = 47 + aPrimeRoot.Length + aGenerator.Length + key.Length + 12 + 8 + 8;
            BinaryWriter bw = new BinaryWriter(ms);
            bw.Write(pad);
            bw.Write(size - PAD_LEN);
            bw.Write((UInt32)_junk_len);
            bw.Write(junk);
            bw.Write((UInt32)encryptionIV.Length);
            bw.Write(encryptionIV);
            bw.Write((UInt32)decryptionIV.Length);
            bw.Write(decryptionIV);
            bw.Write((UInt32)aPrimeRoot.ToCharArray().Length);
            foreach (char fP in aPrimeRoot.ToCharArray())
            {
                bw.BaseStream.WriteByte((byte)fP);
            }
            bw.Write((UInt32)aGenerator.ToCharArray().Length);
            foreach (char fG in aGenerator.ToCharArray())
            {
                bw.BaseStream.WriteByte((byte)fG);
            }
            bw.Write((UInt32)key.ToCharArray().Length);
            foreach (char SPK in key.ToCharArray())
            {
                bw.BaseStream.WriteByte((byte)SPK);
            }
            foreach (char tq in tqs.ToCharArray())
            {
                bw.BaseStream.WriteByte((byte)tq);
            }
            byte[] Packet = new byte[ms.Length];
            Packet = ms.ToArray();
            Console.WriteLine(PacketDump.Hex(Packet));
            
            Buffer.BlockCopy(Packet, 0, mBuf, 0, (int)ms.Length); // Copy it to this current Msg in preparation of sending it to the server.
            
            Console.WriteLine(PacketDump.Hex(mBuf));
The client instantly disconnected.

I'm not really sure what could cause a conquer client to instantly disconnect from the game server other than a malformed packet? I'm thinking perhaps I need to step away from this for a few days and come back to it with a fresh pair of eyes. :disappointed:

Trying to understand a bit more about about the RC5 5187 Acc-Client password decryption process

22
Usually it has to do with the packet length being incorrect. In my implementation, I have the following definition: https://gitlab.com/spirited/comet/-/blo ... ake.cs#L83. I'm at work right now so I can't really check your work very closely, but I'm not 100% following your length calculation.
Interested in my work?

If you wanna learn more about me and my projects: visit my portfolio website. There, you can find my free, open-source work and articles about game development. Due to contractual restrictions: I am not available for job requests or volunteer work.

About Me | GitLab Profile | Website

Trying to understand a bit more about about the RC5 5187 Acc-Client password decryption process

23
Spirited wrote: Mon May 17, 2021 9:01 pm Usually it has to do with the packet length being incorrect. In my implementation, I have the following definition: https://gitlab.com/spirited/comet/-/blo ... ake.cs#L83. I'm at work right now so I can't really check your work very closely, but I'm not 100% following your length calculation.

For testing purposes I hard coded some things just to see what the value would be like, I went over this several times and with 11 bytes of padding at the start, and 12 bytes of junk length before the encryptionIV, the total length of the packet should be 326. I stepped through and ensured that all the data is being written correctly but sadly it still disconnects me. I may be a lost cause at this point.

Code: Select all

	   Random rnd = new Random();
           
            var paddingBytes = new byte[11]; 
            rnd.NextBytes(paddingBytes);
            Buffer.BlockCopy(paddingBytes, 0, mBuf, 0, 11); // 0-11 (11 bytes)
           
            Length = 326 - 11; // 12-15 (4 bytes)
            JunkLength = 12; // 16-19 (4 bytes)
           
            var junkBytes = new byte[12];
            rnd.NextBytes(junkBytes);
            Buffer.BlockCopy(junkBytes, 0, mBuf, 20, 12); // 20-31 ( 12 bytes)
           
            EncryptionIVLength = 8; //32-35 ( 4 bytes) 
            Buffer.BlockCopy(encryptionIV, 0, mBuf, 36, 8); // 36-43 ( 8 bytes)
            
            DecryptionIVLength = 8;// 44-47 ( 4 bytes)
            Buffer.BlockCopy(decryptionIV, 0, mBuf, 48, 8); // 48-55 (8 bytes)
            
            PrimeRootLength = 128; // 55-59 (4 bytes)
            Buffer.BlockCopy(Encoding.ASCII.GetBytes(aPrimeRoot), 0, mBuf, 60, 128);
            
            GeneratorLength = 2;  // 188-191 (4 bytes)
            Buffer.BlockCopy(Encoding.ASCII.GetBytes(aGenerator), 0, mBuf, 192, 2);
            
            PrimaryKeyLength = 128; //194-197 (4 bytes)
            Buffer.BlockCopy(Encoding.ASCII.GetBytes(key), 0, mBuf, 198, 128);

Trying to understand a bit more about about the RC5 5187 Acc-Client password decryption process

24
Ah, I don't think this is documented very well in Comet. Comet's client send method creates a copy of the packet with the server footer automatically appended to it and writes the packet length. Since the initial handshake packet is length 325 given the inputs you provided, +8 for the footer (TQServer) would give you the correct packet length of 333 (which is what it's expecting from you).
Interested in my work?

If you wanna learn more about me and my projects: visit my portfolio website. There, you can find my free, open-source work and articles about game development. Due to contractual restrictions: I am not available for job requests or volunteer work.

About Me | GitLab Profile | Website

Trying to understand a bit more about about the RC5 5187 Acc-Client password decryption process

25
Spirited wrote: Tue May 18, 2021 5:58 am Ah, I don't think this is documented very well in Comet. Comet's client send method creates a copy of the packet with the server footer automatically appended to it and writes the packet length. Since the initial handshake packet is length 325 given the inputs you provided, +8 for the footer (TQServer) would give you the correct packet length of 333 (which is what it's expecting from you).
Took a look again after a few days and found that I'm still stuck on this unfortunately. I did discover that the client produces debug logs:

Code: Select all

ERROR: CGameSocket::ReceiveMsg() OnShakeHand failed at ..\3DRole/Network/socket.h, 564 -- Sun May 23 16:35:41 2021
So at-least I know I'm failing the handshake somehow. I've followed Comet pretty closely, and below is what I have done so far:

I've done quite a bit of debugging and as far as I can tell I'm sending the packet in the correct structure:

1. Header - 11 bytes
2. Length of total packet (minus 11 junk bytes) - 4 bytes
3. Junk/Padding length - 4 bytes
4. Junk/Padding bytes - random 12-24
5. EncryptionIv length - 4 bytes
6. EncryptionIV - 8 bytes
7. DecryptionIVLength - 4 bytes
8. DecrpytionIV - 8 bytes
9 Primelength - 4 bytes
10. Prime - 128 bytes
11. GeneratorLength - 4 bytes
12. Generator - 2 bytes.
13. KeyLength - 4 bytes
14. Key - 128 bytes.

I am also appending the TQFooter (8 bytes but no length bytes before and not included in the total length part of the packet. ) at the end of the packet. Is there anything else you can think of that I may be fucking up in that initial DH handshake send?

Here is function snippet of that class
https://pastebin.com/nB5y2AdM

Trying to understand a bit more about about the RC5 5187 Acc-Client password decryption process

26
I think the main problem is the length you're providing in the packet. With the structure you defined above, that's 325 bytes + 8 which is the expected 333 bytes (given a junk padding length of 12). Looking at your packet structure snippet though, you're initializing the length at only 314 bytes. I'd try fixing that length and seeing if that helps. *fingers crossed*
Interested in my work?

If you wanna learn more about me and my projects: visit my portfolio website. There, you can find my free, open-source work and articles about game development. Due to contractual restrictions: I am not available for job requests or volunteer work.

About Me | GitLab Profile | Website

Trying to understand a bit more about about the RC5 5187 Acc-Client password decryption process

27
Spirited wrote: Mon May 24, 2021 6:38 am I think the main problem is the length you're providing in the packet. With the structure you defined above, that's 325 bytes + 8 which is the expected 333 bytes (given a junk padding length of 12). Looking at your packet structure snippet though, you're initializing the length at only 314 bytes. I'd try fixing that length and seeing if that helps. *fingers crossed*
A friend reached out and pointed out an obvious stupid mistake I was doing. Was not even using the correct encryption (blowfish). I should have guessed as much. Thanks for your patience Spirited.

Trying to understand a bit more about about the RC5 5187 Acc-Client password decryption process

28
Rezlind wrote: Tue May 25, 2021 4:27 pm
Spirited wrote: Mon May 24, 2021 6:38 am I think the main problem is the length you're providing in the packet. With the structure you defined above, that's 325 bytes + 8 which is the expected 333 bytes (given a junk padding length of 12). Looking at your packet structure snippet though, you're initializing the length at only 314 bytes. I'd try fixing that length and seeing if that helps. *fingers crossed*
A friend reached out and pointed out an obvious stupid mistake I was doing. Was not even using the correct encryption (blowfish). I should have guessed as much. Thanks for your patience Spirited.
Ahhh, yep. That'd do it! Glad you were able to figure it out!
Interested in my work?

If you wanna learn more about me and my projects: visit my portfolio website. There, you can find my free, open-source work and articles about game development. Due to contractual restrictions: I am not available for job requests or volunteer work.

About Me | GitLab Profile | Website

Trying to understand a bit more about about the RC5 5187 Acc-Client password decryption process

30
Great job, and good luck with your other server upgrades!
Interested in my work?

If you wanna learn more about me and my projects: visit my portfolio website. There, you can find my free, open-source work and articles about game development. Due to contractual restrictions: I am not available for job requests or volunteer work.

About Me | GitLab Profile | Website