|
You last visited: Today at 06:20
Advertisement
[Research / Help] Packet Data
Discussion on [Research / Help] Packet Data within the Dekaron forum part of the MMORPGs category.
02/22/2024, 04:49
|
#1
|
elite*gold: 0 
Join Date: Oct 2007
Posts: 121
Received Thanks: 39
|
[Research / Help] Packet Data
So I have been a part of the forums for a long time and as we all do, we take breaks from the game to do life stuff but lately I've had some free time and decided to pick this project back up. I have always been interested in games communication and have done some work on it, but there are still some things I haven't figured out.
@guesswho-.- If you're still around let me know, I have a decent amount of freetime now rather than when I first PM'd you and hope you're still around to shed some light on this
I'll try to best explain what is going on. I am currently running that Sharingla 1-click and Client for my research. I was thinking of starting back at A3 though cause it may be simpler to work on and it's really about the nostalgia at this point.
1. Here is a MITM (or proxy) if some call it that. This was a "proxy" that was posted in the Conquer Online forums called (Pojerv Proxy) that I heavily modified to work with Dekaron. There are still a lot of things to improve on it, but that will come in due time. I have also built a C++ Console Application that mimics this for testing and to learn different skills.
2. I believe I have things figured out for the most part using Zektors Encryption / Decryption that was posted some time ago. As far as my understanding goes: - If the client is sending the initial packet which is 20080, it is encrypted with 0x19.
- The server will then respond with 20081 which is 64 bytes in length. The session key is then derived by (buffer[24] ^ buffer[28]) ^ 0x19. This packet should still be encrypted with key 0x19 but every other packet after that shouldn't be. The AuthServer is a little odd because it still seems like all the packets are 0x19 until the game server. I'm a little unsure if this is correct or not, but from my findings, doing it this way has always given me back the correct packet.
- When switching servers or going from login screen to getting in the game the same 2 packets are always sent as they are sort of the handshake for the session. The Session Key should change every time 20081 is sent to the client
3. Right now I am just trying to figure out the basics of the communications before I start trying to dive into the structure of each packet which leads me to the following things I don't know: - There are times where the packet checksum is not correct. My understanding is, if the packet is decrypted properly and re-encrypted with the proper key, the checksum should be the same as the original packet. Please correct me if I am wrong here.
================================================== ==================================================
This is the part I am really stuck on because I don't know how the checksum is being calculated or if there is such thing as decrypting it properly. I have done tests where I encrypt the entire packet, swap the re-encrypted packet's checksum with the one initially received and everything is sent and received fine between the game and client. The moment I use the re-encrypted packet's checksum, the server nor client accepts it properly. This is where I am asking for help from those who have looked into this before if they are even still on the forums. Below is an example of what I am seeing.
================================================== ==================================================
Code:
PacketID: [50D0000] | PacketLength: [52]
0 1 2 3 4 5 6 7 8 9 A B C D E F
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000 D1 EE 82 66 18 87 24 86 7F 68 77 37 3F A1 16 80 ...f..$..hw7?...
0016 34 E6 59 DF C2 82 9D 8A E7 41 8E 96 79 34 72 E4 4.Y......A..y4r.
0032 D9 4F F5 62 60 56 1F 7A EB DC D1 D1 EA 82 87 97 .O.b`V.z........
0048 FD C5 08 8D ....
0 1 2 3 4 5 6 7 8 9 A B C D E F
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000 D0 79 AF DD 10 19 00 34 5C DD 78 AE 05 0D 00 00 .y.....4\.x.....
0016 41 05 00 10 AE 78 DD 5C A0 90 E5 6B 27 FC 00 00 A....x.\...k'...
0032 00 00 00 01 A0 00 F3 00 00 A1 16 80 18 E6 59 DF ..............Y.
0048 40 EE 99 8A [MENTION=321756]...[/MENTION]
0 1 2 3 4 5 6 7 8 9 A B C D E F
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000 51 91 3C C2 18 87 24 86 7F 68 77 37 3F A1 16 80 Q.<...$..hw7?...
0016 34 E6 59 DF C2 82 9D 8A E7 41 8E 96 79 34 72 E4 4.Y......A..y4r.
0032 D9 4F F5 62 60 56 1F 7A EB DC D1 D1 EA 82 87 97 .O.b`V.z........
0048 FD C5 08 8D ....
Checksum does not match
o_checksum: D1 EE 82 66
n_checksum: 51 91 3C C2
Packet body is encrypted successfully
The above is from my C++ helper application. Here is where it gets even weirder. Below is the same implementation but in C#
Code:
PacketID: [50D0000] | PacketLength: [52]
0 1 2 3 4 5 6 7 8 9 A B C D E F
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000 D1 EE 82 66 18 87 24 86 7F 68 77 37 3F A1 16 80 ...f..$..hw7?...
0016 34 E6 59 DF C2 82 9D 8A E7 41 8E 96 79 34 72 E4 4.Y......A..y4r.
0032 D9 4F F5 62 60 56 1F 7A EB DC D1 D1 EA 82 87 97 .O.b`V.z........
0048 FD C5 08 8D ....
0 1 2 3 4 5 6 7 8 9 A B C D E F
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000 D0 79 AF DD 10 19 00 34 5C DD 78 AE 05 0D 00 00 .y.....4\.x.....
0016 41 05 00 10 AE 78 DD 5C A0 90 E5 6B 27 FC 00 00 A....x.\...k'...
0032 00 00 00 01 A0 00 F3 00 00 A1 16 80 18 E6 59 DF ..............Y.
0048 40 EE 99 8A [MENTION=321756]...[/MENTION]
0 1 2 3 4 5 6 7 8 9 A B C D E F
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000 D1 EE 82 66 18 87 24 86 7F 68 77 37 3F A1 16 80 ...f..$..hw7?...
0016 34 E6 59 DF C2 82 9D 8A E7 41 8E 96 79 34 72 E4 4.Y......A..y4r.
0032 D9 4F F5 62 60 56 1F 7A EB DC D1 D1 EA 82 87 97 .O.b`V.z........
0048 FD C5 08 8D ....
Here you can see that the packet has been encrypted properly include the calculated checksum. Between both examples the decrypted data is exactly the same but for the life of me I cannot narrow down why the checksum is completly different between the C# and C++ versions. To top it all off it seems like there is some randomness on the re-encrypted packets in the C# application. Sometimes it's good and sometimes it's not. I have no clue what I am missing.
Below you can see the output where I was checking if the packet checksum match the re-encrypted data.
Code:
[Send] Packet [0x50D0000] checksum is correct
[Recv] Packet [0x50D0000] checksum is correct
[Send] Packet [0x50D0000] checksum is correct
[Recv] Packet [0x50D0000] checksum is correct
[Send] Packet [0x50D0000] checksum is correct
[Recv] Packet [0x22000001] checksum is correct
[Send] Packet [0x50D0001] checksum is correct
[Recv] Packet [0x50D0000] checksum is correct
[Recv] Packet [0x5040000] checksum is not correct
[Recv] Packet [0x5040000] checksum is not correct
[Send] Packet [0x50D0000] checksum is correct
[Send] Packet [0x50D0000] checksum is not correct
[Recv] Packet [0x50D0000] checksum is correct
[Send] Packet [0x50D0000] checksum is correct
[Send] Packet [0x50D0002] checksum is not correct
[Send] Packet [0x50D0000] checksum is correct
[Send] Packet [0x50D0000] checksum is correct
[Send] Packet [0xE010002] checksum is correct
[Recv] Packet [0x50D0000] checksum is correct
[Recv] Packet [0x50D0000] checksum is not correct
[Recv] Packet [0x50D0000] checksum is not correct
[Send] Packet [0x50D0000] checksum is correct
[Recv] Packet [0x50D0000] checksum is correct
[Send] Packet [0x50D0002] checksum is correct
[Send] Packet [0x50D0000] checksum is correct
[Send] Packet [0x50D0002] checksum is correct
[Send] Packet [0x50D0000] checksum is correct
[Send] Packet [0xE010002] checksum is correct
[Send] Packet [0x50D0000] checksum is correct
[Send] Packet [0x50D0000] checksum is correct
[Recv] Packet [0x50D0000] checksum is correct
[Recv] Packet [0x50D0000] checksum is not correct
[Send] Packet [0x50D0000] checksum is correct
[Recv] Packet [0x50D0000] checksum is correct
[Send] Packet [0x50D0000] checksum is correct
[Recv] Packet [0x50D0000] checksum is correct
The code for checking the checksum is pretty simple as it's just Take() is the first 4 bytes and returns a bool if it's equal to one another.
Code:
bool isChecksumCorrect = buffer.Take(4).SequenceEqual(encryptedBuffer.Take(4));
if (isChecksumCorrect)
WriteLine(string.Format("[Recv] Packet [0x{0:X2}] checksum is correct", getPacketID(decryptedBuffer)), ConsoleColor.Green);
else
WriteLine(string.Format("[Recv] Packet [0x{0:X2}] checksum is not correct", getPacketID(decryptedBuffer)), ConsoleColor.Red);
If you have stuck around this long, thanks for reading the post. If anyone has any information that they're willing to share please PM me. I know these days the forums are pretty dead and finding those who are interested in this is difficult vs those who are just looking for the latest files.
|
|
|
|
02/22/2024, 07:45
|
#2
|
elite*gold: 293
Join Date: Jan 2012
Posts: 2,445
Received Thanks: 1,100
|
Quote:
If the client is sending the initial packet which is 20080, it is encrypted with 0x19.
The server will then respond with 20081 which is 64 bytes in length. The session key is then derived by (buffer[24] ^ buffer[28]) ^ 0x19. This packet should still be encrypted with key 0x19 but every other packet after that shouldn't be. The AuthServer is a little odd because it still seems like all the packets are 0x19 until the game server. I'm a little unsure if this is correct or not, but from my findings, doing it this way has always given me back the correct packet.
When switching servers or going from login screen to getting in the game the same 2 packets are always sent as they are sort of the handshake for the session. The Session Key should change every time 20081 is sent to the client
|
The default crypt key is 0x0F rather than 0x19.
Quote:
|
buffer[24] ^ buffer[28]) ^ 0x19
|
no, it's a xor of CryptKeyLow and CryptKeyHi from the following struct:
struct ConAck : public PacketHeader
{
unsigned int dwServerTick;
unsigned int dwStartTick;
unsigned char bCryptKeyLow;
unsigned char bPadding1[3];
unsigned char bCryptKeyHigh;
unsigned char bPadding2[3];
unsigned char strPassport[32];
};
on the server side bCryptKeyLow and High are treated as int32 but for the ease of use I went with padding.
Quote:
|
There are times where the packet checksum is not correct. My understanding is, if the packet is decrypted properly and re-encrypted with the proper key, the checksum should be the same as the original packet. Please correct me if I am wrong here.
|
post the C++ crc calc function you're using. I cant tell you where the bug is if I dont know the code.
|
|
|
|
|
02/22/2024, 17:34
|
#3
|
elite*gold: 0
Join Date: Oct 2007
Posts: 121
Received Thanks: 39
|
Quote:
|
The default crypt key is 0x0F rather than 0x19.
|
That's true. I have seen the 0x0F come up with that. When I do buffer[4] ^ 0x19 on 20080 from send() (talking Client -> Server) it decrypts to 0x0F. buffer[4] usually has 0x16 if I am not mistaken. Please check me on that one.
Quote:
no, it's a xor of CryptKeyLow and CryptKeyHi from the following struct:
struct ConAck : public PacketHeader
{
unsigned int dwServerTick;
unsigned int dwStartTick;
unsigned char bCryptKeyLow;
unsigned char bPadding1[3];
unsigned char bCryptKeyHigh;
unsigned char bPadding2[3];
unsigned char strPassport[32];
};
on the server side bCryptKeyLow and High are treated as int32 but for the ease of use I went with padding.
post the C++ crc calc function you're using. I cant tell you where the bug is if I dont know the code.
|
Ok so the "Session key" or "Crypt key" to re-encrypt the packet can be derived from doing bCryptKeyLow ^ bCryptKeyHigh? This is interesting because when I re-encrypt a packet using this way, I get a completely different packet vs the original. When using (bCryptKeyLow ^ bCryptKeyHigh) ^ 0x19 I can see the new packet looks exactly like the original one that was received by the proxy. I have to do some more tests when I get home just to make sure but if you say this is the way, I will change it around for sure as I know you have definitely researched this more than me lol.
I am using Zektor's Packet Encryption and Decryption that was posted some years ago
Code:
void CalculateChecksum(unsigned char * PacketData, unsigned long DwordVal)
{
int Counter = 0;
long Byte1, Byte2, Byte3, Byte4;
Byte1 = Byte2 = Byte3 = Byte4 = 0;
DwordVal = ~DwordVal;
Byte1 = (DwordVal & 0x000000FF);
Byte2 = (DwordVal & 0x0000FF00) >> 8;
Byte3 = (DwordVal & 0x00FF0000) >> 16;
Byte4 = (DwordVal & 0xFF000000) >> 24;
PacketData[Counter++] = Byte4;
PacketData[Counter++] = Byte3;
PacketData[Counter++] = Byte2;
PacketData[Counter++] = Byte1;
}
void EncryptData(unsigned char * PacketData, int Length, long FlagByte)
{
long EncryptedByte = 0;
unsigned long DwordTableVal = 0;
unsigned long DwordVal = 0xFFFFFFFF;
int Counter = 4;
for(int i = 0; i < Length; i++)
{
EncryptedByte = ((ByteTable[(Counter & 0x0FF)]) ^ FlagByte) ^ PacketData[Counter];
PacketData[Counter++] = EncryptedByte;
DwordTableVal = (EncryptedByte ^ DwordVal) & 0x0FF;
DwordVal = (DwordVal >> 8) ^ Table[DwordTableVal];
}
CalculateChecksum(PacketData, DwordVal);
}
Then to decrypt the packet, I did make a modification to the CryptBody() portion of the decryption
Code:
void CryptBody(unsigned char * PacketData, int len)
{
if (len <= 14 || PacketData[14] == 0x00)
{
}
else
{
// Doing the CryptBody on everything besides the Checksum
unsigned char* DecryptedData = new unsigned char[len];
unsigned long key = PacketData[14];
for (int i = 0; i < 4; i++)
{
DecryptedData[i] = (byte)(PacketData[i]);
PacketData[i] = DecryptedData[i];
}
for (int i = 4; i < len; i++)
{
DecryptedData[i] = (byte)(PacketData[i] ^ key);
PacketData[i] = DecryptedData[i];
}
}
}
I did this to rule out the checksum being incorrect which ended up working out properly because I can see a lot more packets are being re-encrypted with the correct checksums. In the example I posted using packet 50D0000, it ended up re-encrypting properly after I made this change to CryptBody() my initial post. But some packets still aren't re-encrypted properly. It's really really odd and I think I'm missing something important.
Essentially my thinking is the checksum is to prevent corrupted data when sending between Client and Server, vice versa to ensure data integrity. It makes sense as if I send a packet with a wrong checksum it fails. For example: If I send 2040000 which looks like character data, the client fails to receive it properly and causes a black screen upon the character select screen. The body can be absolutely the same as the original packet minus the checksum but will fail because the checksum is wrong.
|
|
|
|
|
02/22/2024, 21:35
|
#4
|
elite*gold: 0
Join Date: May 2019
Posts: 23
Received Thanks: 4
|
Hey man you can share too this project?
Quote:
Originally Posted by GrandSlam
So I have been a part of the forums for a long time and as we all do, we take breaks from the game to do life stuff but lately I've had some free time and decided to pick this project back up. I have always been interested in games communication and have done some work on it, but there are still some things I haven't figured out.
@guesswho-.- If you're still around let me know, I have a decent amount of freetime now rather than when I first PM'd you and hope you're still around to shed some light on this
I'll try to best explain what is going on. I am currently running that Sharingla 1-click and Client for my research. I was thinking of starting back at A3 though cause it may be simpler to work on and it's really about the nostalgia at this point.
1. Here is a MITM (or proxy) if some call it that. This was a "proxy" that was posted in the Conquer Online forums called (Pojerv Proxy) that I heavily modified to work with Dekaron. There are still a lot of things to improve on it, but that will come in due time. I have also built a C++ Console Application that mimics this for testing and to learn different skills.
2. I believe I have things figured out for the most part using Zektors Encryption / Decryption that was posted some time ago. As far as my understanding goes: - If the client is sending the initial packet which is 20080, it is encrypted with 0x19.
- The server will then respond with 20081 which is 64 bytes in length. The session key is then derived by (buffer[24] ^ buffer[28]) ^ 0x19. This packet should still be encrypted with key 0x19 but every other packet after that shouldn't be. The AuthServer is a little odd because it still seems like all the packets are 0x19 until the game server. I'm a little unsure if this is correct or not, but from my findings, doing it this way has always given me back the correct packet.
- When switching servers or going from login screen to getting in the game the same 2 packets are always sent as they are sort of the handshake for the session. The Session Key should change every time 20081 is sent to the client
3. Right now I am just trying to figure out the basics of the communications before I start trying to dive into the structure of each packet which leads me to the following things I don't know: - There are times where the packet checksum is not correct. My understanding is, if the packet is decrypted properly and re-encrypted with the proper key, the checksum should be the same as the original packet. Please correct me if I am wrong here.
================================================== ==================================================
This is the part I am really stuck on because I don't know how the checksum is being calculated or if there is such thing as decrypting it properly. I have done tests where I encrypt the entire packet, swap the re-encrypted packet's checksum with the one initially received and everything is sent and received fine between the game and client. The moment I use the re-encrypted packet's checksum, the server nor client accepts it properly. This is where I am asking for help from those who have looked into this before if they are even still on the forums. Below is an example of what I am seeing.
================================================== ==================================================
Code:
PacketID: [50D0000] | PacketLength: [52]
0 1 2 3 4 5 6 7 8 9 A B C D E F
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000 D1 EE 82 66 18 87 24 86 7F 68 77 37 3F A1 16 80 ...f..$..hw7?...
0016 34 E6 59 DF C2 82 9D 8A E7 41 8E 96 79 34 72 E4 4.Y......A..y4r.
0032 D9 4F F5 62 60 56 1F 7A EB DC D1 D1 EA 82 87 97 .O.b`V.z........
0048 FD C5 08 8D ....
0 1 2 3 4 5 6 7 8 9 A B C D E F
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000 D0 79 AF DD 10 19 00 34 5C DD 78 AE 05 0D 00 00 .y.....4\.x.....
0016 41 05 00 10 AE 78 DD 5C A0 90 E5 6B 27 FC 00 00 A....x.\...k'...
0032 00 00 00 01 A0 00 F3 00 00 A1 16 80 18 E6 59 DF ..............Y.
0048 40 EE 99 8A [MENTION=321756]...[/MENTION]
0 1 2 3 4 5 6 7 8 9 A B C D E F
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000 51 91 3C C2 18 87 24 86 7F 68 77 37 3F A1 16 80 Q.<...$..hw7?...
0016 34 E6 59 DF C2 82 9D 8A E7 41 8E 96 79 34 72 E4 4.Y......A..y4r.
0032 D9 4F F5 62 60 56 1F 7A EB DC D1 D1 EA 82 87 97 .O.b`V.z........
0048 FD C5 08 8D ....
Checksum does not match
o_checksum: D1 EE 82 66
n_checksum: 51 91 3C C2
Packet body is encrypted successfully
The above is from my C++ helper application. Here is where it gets even weirder. Below is the same implementation but in C#
Code:
PacketID: [50D0000] | PacketLength: [52]
0 1 2 3 4 5 6 7 8 9 A B C D E F
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000 D1 EE 82 66 18 87 24 86 7F 68 77 37 3F A1 16 80 ...f..$..hw7?...
0016 34 E6 59 DF C2 82 9D 8A E7 41 8E 96 79 34 72 E4 4.Y......A..y4r.
0032 D9 4F F5 62 60 56 1F 7A EB DC D1 D1 EA 82 87 97 .O.b`V.z........
0048 FD C5 08 8D ....
0 1 2 3 4 5 6 7 8 9 A B C D E F
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000 D0 79 AF DD 10 19 00 34 5C DD 78 AE 05 0D 00 00 .y.....4\.x.....
0016 41 05 00 10 AE 78 DD 5C A0 90 E5 6B 27 FC 00 00 A....x.\...k'...
0032 00 00 00 01 A0 00 F3 00 00 A1 16 80 18 E6 59 DF ..............Y.
0048 40 EE 99 8A [MENTION=321756]...[/MENTION]
0 1 2 3 4 5 6 7 8 9 A B C D E F
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000 D1 EE 82 66 18 87 24 86 7F 68 77 37 3F A1 16 80 ...f..$..hw7?...
0016 34 E6 59 DF C2 82 9D 8A E7 41 8E 96 79 34 72 E4 4.Y......A..y4r.
0032 D9 4F F5 62 60 56 1F 7A EB DC D1 D1 EA 82 87 97 .O.b`V.z........
0048 FD C5 08 8D ....
Here you can see that the packet has been encrypted properly include the calculated checksum. Between both examples the decrypted data is exactly the same but for the life of me I cannot narrow down why the checksum is completly different between the C# and C++ versions. To top it all off it seems like there is some randomness on the re-encrypted packets in the C# application. Sometimes it's good and sometimes it's not. I have no clue what I am missing.
Below you can see the output where I was checking if the packet checksum match the re-encrypted data.
Code:
[Send] Packet [0x50D0000] checksum is correct
[Recv] Packet [0x50D0000] checksum is correct
[Send] Packet [0x50D0000] checksum is correct
[Recv] Packet [0x50D0000] checksum is correct
[Send] Packet [0x50D0000] checksum is correct
[Recv] Packet [0x22000001] checksum is correct
[Send] Packet [0x50D0001] checksum is correct
[Recv] Packet [0x50D0000] checksum is correct
[Recv] Packet [0x5040000] checksum is not correct
[Recv] Packet [0x5040000] checksum is not correct
[Send] Packet [0x50D0000] checksum is correct
[Send] Packet [0x50D0000] checksum is not correct
[Recv] Packet [0x50D0000] checksum is correct
[Send] Packet [0x50D0000] checksum is correct
[Send] Packet [0x50D0002] checksum is not correct
[Send] Packet [0x50D0000] checksum is correct
[Send] Packet [0x50D0000] checksum is correct
[Send] Packet [0xE010002] checksum is correct
[Recv] Packet [0x50D0000] checksum is correct
[Recv] Packet [0x50D0000] checksum is not correct
[Recv] Packet [0x50D0000] checksum is not correct
[Send] Packet [0x50D0000] checksum is correct
[Recv] Packet [0x50D0000] checksum is correct
[Send] Packet [0x50D0002] checksum is correct
[Send] Packet [0x50D0000] checksum is correct
[Send] Packet [0x50D0002] checksum is correct
[Send] Packet [0x50D0000] checksum is correct
[Send] Packet [0xE010002] checksum is correct
[Send] Packet [0x50D0000] checksum is correct
[Send] Packet [0x50D0000] checksum is correct
[Recv] Packet [0x50D0000] checksum is correct
[Recv] Packet [0x50D0000] checksum is not correct
[Send] Packet [0x50D0000] checksum is correct
[Recv] Packet [0x50D0000] checksum is correct
[Send] Packet [0x50D0000] checksum is correct
[Recv] Packet [0x50D0000] checksum is correct
The code for checking the checksum is pretty simple as it's just Take() is the first 4 bytes and returns a bool if it's equal to one another.
Code:
bool isChecksumCorrect = buffer.Take(4).SequenceEqual(encryptedBuffer.Take(4));
if (isChecksumCorrect)
WriteLine(string.Format("[Recv] Packet [0x{0:X2}] checksum is correct", getPacketID(decryptedBuffer)), ConsoleColor.Green);
else
WriteLine(string.Format("[Recv] Packet [0x{0:X2}] checksum is not correct", getPacketID(decryptedBuffer)), ConsoleColor.Red);
If you have stuck around this long, thanks for reading the post. If anyone has any information that they're willing to share please PM me. I know these days the forums are pretty dead and finding those who are interested in this is difficult vs those who are just looking for the latest files. |
hey man you can share too this project i very interested too
|
|
|
|
|
02/22/2024, 21:52
|
#5
|
elite*gold: 293
Join Date: Jan 2012
Posts: 2,445
Received Thanks: 1,100
|
Im not sure you're doing this correctly.
the checksum is the last DwordVal byteswapped:
*(unsigned long*)PacketData = _byteswap_ulong(~DwordVal);
that works fine for me  I dont use that calculate checksum func, none of my custom servers use it tbh.
|
|
|
|
|
02/28/2024, 18:38
|
#6
|
elite*gold: 0
Join Date: Oct 2007
Posts: 121
Received Thanks: 39
|
Quote:
Originally Posted by guesswho-.-
Im not sure you're doing this correctly.
the checksum is the last DwordVal byteswapped:
*(unsigned long*)PacketData = _byteswap_ulong(~DwordVal);
that works fine for me I dont use that calculate checksum func, none of my custom servers use it tbh. |
Lol nice! i figured you essentially figured out everything. So I took what you said about it being the last ~DwordVal and did some testing on a particular packet
Code:
public byte[] encryptedBuffer = { 0x82, 0x58, 0x46, 0xDD, 0x08, 0x9D, 0x24, 0x77, 0x23, 0xB5, 0x0F, 0x99, 0x38, 0xA8, 0x16, 0x80, 0x15, 0x0F, 0x54, 0xD4, 0x29, 0xFB, 0x40, 0xC6, 0x47, 0x7C, 0x6B, 0xFD, 0x79, 0xC7, 0x72, 0xE4, 0xFE, 0x40, 0xF5, 0x67, 0x34, 0xD2, 0xD9, 0x5B, 0xFB, 0x55, 0xFC, 0xCB, 0x3B, 0x9B, 0xE5, 0xD2, 0x74, 0xD4, 0x91, 0x07, 0x5D, 0x88, 0x88, 0x1E, 0xC2, 0x41, 0x84, 0x3A, 0xB1, 0x0F, 0x9D, 0x23, 0xA6, 0x18, 0xAC, 0xF6, 0x98, 0xF6, 0xB5, 0x4D, 0xB3, 0x7B, 0x9F, 0x0A, 0xAA, 0xAA, 0xA1, 0x1F, 0xE6, 0xD2, 0xC9, 0x97, 0xF7, 0x6A, 0xD0, 0x46, 0xD7, 0x41, 0xFB, 0x6D, 0xCE, 0x58, 0xE3, 0xD6, 0x45, 0xDF, 0x65, 0xF3, 0x52, 0xC6, 0x7D, 0x6C, 0xE4, 0xED, 0x57, 0xC1, 0x62, 0xF4, 0x4E, 0xD8, 0x2D, 0xBB, 0x01, 0x94, 0x34, 0xA2, 0x18, 0x8E, 0x1F, 0x89, 0x33, 0xA5, 0x06, 0x90, 0x2A, 0xBC, 0x31, 0xA7, 0x1D, 0x8B, 0x28, 0xBE, 0x05, 0x93, 0x03, 0x94, 0x2F, 0xB8, 0x1A, 0x8C, 0x36, 0xA0, 0x55, 0xC3, 0x79, 0xEF, 0x4C, 0xDA, 0x60, 0xF6, 0x67, 0xF1, 0x4B, 0xDD, 0x7E, 0xE8, 0x52, 0xC4, 0xF9, 0x6F, 0xD5, 0x43, 0xE0, 0x76, 0xCC, 0x5A, 0xCB, 0x5D, 0xE7, 0x71, 0xD2, 0x44, 0xFE, 0x68, 0x9D, 0x0B, 0xB1, 0x27, 0x84, 0x12, 0xA8, 0x3E, 0xAF, 0x39, 0x83, 0x15, 0xB6, 0x20, 0x9A, 0x0C, 0xA1, 0x37, 0x8C, 0x1F, 0x5C, 0x5B, 0x84, 0xFC, 0xDA, 0x08, 0x9A, 0x24, 0x77, 0x23, 0xB5, 0x0F, 0x99, 0x38, 0xA8, 0x16, 0x80, 0x15, 0x0F, 0x54, 0xD4, 0x29, 0xFB, 0x40, 0xC6, 0x47, 0x7C, 0x6B, 0xFD, 0x5E, 0xC8, 0x72, 0xE4, 0xD9, 0x4F, 0xF5, 0x63, 0xC7, 0xFE, 0xD9, 0xC8, 0xDE, 0xE5, 0xC7, 0x51, 0xF2, 0x64, 0xDE, 0x48, 0xBD, 0x2B, 0x91, 0x07, 0xF1, 0xBB, 0x88, 0x1E, 0x85, 0x87, 0xA2, 0xF7, 0x96, 0x55, 0xBA, 0xD6, 0x81, 0xB8, 0xAD, 0x5D, 0x99, 0x8B, 0xB5, 0x4D, 0xB3, 0x7B, 0x9F, 0x03, 0xAA, 0xAA, 0x86, 0x22, 0xE5, 0xC5, 0xC9, 0x97, 0xFB, 0x6A, 0xD0, 0x46, 0xD7, 0x41, 0xFB, 0x6D, 0xCE, 0x58, 0xE2, 0x80, 0x92, 0xDF, 0x65, 0xF3, 0x52, 0xC6, 0x7C, 0xEA, 0x7B, 0xED, 0x57, 0xC1, 0x62, 0xF4, 0x4E, 0xD8, 0x2D, 0xBB, 0x01, 0x95, 0x34, 0xA2, 0x18, 0x8E, 0x1F, 0x89, 0x33, 0xA5, 0x06, 0x90, 0x2A, 0xBC, 0x31, 0xA7, 0x1D, 0x8B, 0x28, 0xBE, 0x05, 0x93, 0x03, 0x94, 0x2F, 0xB8, 0x1A, 0x8C, 0x36, 0xA0, 0x55, 0xC3, 0x79, 0xEF, 0x4C, 0xDA, 0x60, 0xF6, 0x67, 0xF1, 0x4B, 0xDD, 0x7E, 0xE8, 0x52, 0xC4, 0xF9, 0x6F, 0xD5, 0x43, 0xE0, 0x76, 0xCC, 0x5A, 0xCB, 0x5D, 0xE7, 0x71, 0xD2, 0x44, 0xFE, 0x68, 0x9D, 0x0B, 0xB1, 0x27, 0x84, 0x12, 0xA8, 0x3E, 0xAF, 0x39, 0x83, 0x15, 0xB6, 0x20, 0x9A, 0x0C, 0xA1, 0x37, 0x8C, 0x1F, 0x5C, 0xFE, 0x4E, 0xF7, 0x8D, 0x08, 0x9B, 0x24, 0x86, 0x23, 0xB5, 0x0F, 0x99, 0x38, 0xAA, 0x16, 0x82, 0x17, 0x14, 0x41, 0x2B, 0x29, 0xFB, 0x40, 0xC6, 0x1C, 0x95, 0x2E, 0xAB, 0x03, 0xF9, 0x40, 0xD7, 0xED, 0x4F, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x93, 0x05, 0xA0, 0x35, 0x25, 0x81, 0xDC, 0xD7, 0x08, 0x98, 0x24, 0x86, 0x23, 0xB5, 0x0F, 0x99, 0x38, 0xAA, 0x16, 0x82, 0x15, 0x0F, 0x54, 0xD4, 0x29, 0xFB, 0x40, 0xC6, 0x1C, 0x95, 0x2E, 0xAB, 0x03, 0xF9, 0x40, 0xD7, 0xED, 0x7A, 0xF5, 0x65, 0xC3, 0x83, 0xEA, 0x7E, 0x2B, 0x7B, 0xC2, 0xEE, 0xF4, 0x62, 0x0A, 0x4E, 0xBA, 0x95, 0x97, 0x0F, 0x19, 0x4A, 0x25, 0x86, 0x08, 0x99, 0x24, 0x0A, 0x23, 0xB5, 0x0F, 0x99, 0x38, 0xA8, 0x16, 0x81, 0x15, 0x0F, 0x54, 0xD4, 0x29, 0xFB, 0x40, 0xC6, 0x47, 0x71, 0x7A, 0xFD, 0x5A, 0xC8, 0x32, 0xE4, 0xF9, 0x7D, 0xC2, 0x63, 0xC0, 0x56, 0xEC, 0x7A, 0xEB, 0x7D, 0xC7, 0x58, 0xF2, 0x63, 0xDE, 0x48, 0xBD, 0x2B, 0x59, 0x0F, 0xB9, 0x32, 0x80, 0x1E, 0xC7, 0x19, 0xBD, 0x3A, 0x25, 0x00, 0xBA, 0x2C, 0x81, 0x17, 0xAD, 0x3B, 0x98, 0xF4, 0xE8, 0x09, 0x49, 0x7B, 0xB6, 0xF2, 0x89, 0x34, 0x7D, 0xFE, 0xA0, 0x6E, 0xC9, 0x56, 0xFC, 0x22, 0xD0, 0x58, 0xE1, 0x82, 0xFB, 0x6D, 0xCE, 0x58, 0xE2, 0x74, 0x49, 0xDF, 0x9D, 0xF5, 0x79, 0x3E, 0x7F, 0xAD, 0x83, 0x3D, 0x5A, 0x38, 0xFE, 0xB1, 0x5B, 0xD8, 0x27, 0xBB, 0x09, 0x97, 0x2A, 0xFF, 0xCB, 0x7E, 0xE4, 0xA2, 0xC3, 0x5E, 0x4F, 0x61, 0xED, 0x94, 0xC3, 0x2C, 0x3F, 0x9E, 0x28, 0xB5, 0x04, 0x9A, 0x03, 0x8B, 0xAB, 0x5A, 0xEF, 0x22, 0x34, 0x55, 0xE4, 0xFB, 0x8F, 0x9C, 0x07, 0x2D, 0x20, 0xAF, 0x72, 0xF1, 0x47, 0xDD, 0x76, 0xE8, 0x4C, 0x6F, 0x0A, 0x9C, 0x8D, 0x45, 0x13, 0x22, 0xCD, 0xAE, 0xD0, 0x63, 0x13, 0x96, 0xC4, 0x4F, 0xFE, 0x67, 0x9D, 0x0A, 0xB1, 0x3D, 0x30, 0x38, 0xA9, 0x3E, 0xC2, 0x02, 0x2C, 0x56, 0x08, 0x96, 0x24, 0x02, 0x23, 0xB5, 0x0F, 0x99, 0x38, 0xA8, 0x16, 0x81, 0x15, 0x0F, 0x54, 0xD4, 0x29, 0xFB, 0x40, 0xC6, 0x47, 0x49, 0x62, 0xFD, 0x5A, 0xC8, 0x72, 0xE4, 0xF9, 0x81, 0x59, 0x6A, 0xC0, 0x51, 0xEC, 0x7A, 0xEB, 0x7D, 0xE5, 0xAB, 0xEF, 0x64, 0xD6, 0x48, 0xF5, 0x2B, 0xB6, 0xAB, 0x07, 0x32, 0x88, 0x1E, 0x8F, 0x19, 0xA3, 0x35, 0x96, 0x6B, 0xC3, 0x79, 0xEA, 0x60, 0xFC, 0x57, 0xA7, 0x5F, 0xD9, 0x28, 0xF5, 0x38, 0x9F, 0x00, 0xAA, 0x74, 0x86, 0x37, 0x36, 0xC0, 0xC9, 0x5F, 0xFC, 0x6A, 0xD0, 0x46, 0xD7, 0x41, 0x92, 0x4C, 0xFA, 0x31, 0xC7, 0x64, 0x20, 0x35, 0x3F, 0x99, 0xE3, 0x9A, 0x69, 0xEA, 0x71, 0xED, 0x5F, 0xC1, 0x45, 0x0E, 0x8D, 0xBA, 0x36, 0xF1, 0x63, 0x8D, 0x2E, 0xC0, 0xF8, 0xAE, 0x7C, 0x2E, 0x37, 0xB0, 0x06, 0x9B, 0x2A, 0xB4, 0x31, 0x8F, 0x3C, 0x58, 0x4E, 0x75, 0x4F, 0xF4, 0xC8, 0xD6, 0x48, 0x36, 0x49, 0xE4, 0x61, 0x89, 0x40, 0xC3, 0x75, 0xEF, 0x44, 0xDA, 0x48, 0xBE, 0x84, 0x95, 0x24, 0xBD, 0x1A, 0x9D, 0x59, 0xA1, 0xC6, 0x0C, 0xB3, 0x40, 0xDE, 0x7D, 0xCC, 0x55, 0xCB, 0x5C, 0xE7, 0x6B, 0x66, 0x6E, 0xFF, 0x40, 0xC6, 0xBD, 0x93, 0x6D, 0x08, 0x97, 0x24, 0xAA, 0x23, 0xB5, 0x0F, 0x99, 0x38, 0xAA, 0x16, 0x83, 0x60, 0xEC, 0x0D, 0x1B, 0x29, 0xFB, 0x40, 0xC6 };
Here's an encrypted buffer. They Key should be 0x11 to encrypt it.
I took the first 4 bytes, and ran the CalculateChecksum() with some modifications to output the 4 bytes after it's being calculated along with the DwordVal and this was the output. Here is the how I am comparing:
EncryptDataTest()
*I set the colors so it's easier to see if there was ever a correct DwordVal*
Code:
public static byte[] EncryptDataTest(byte[] encryptedData, byte[] PacketData, ulong FlagByte)
{
ulong EncryptedByte = 0;
ulong DwordTableVal = 0;
ulong localDwordVal = 0;
ulong DwordVal = 0xFFFFFFFF;
int Counter = 4;
byte[] checkSumData = new byte[4];
bool isChecksumCorrect;
byte[] EncryptedData = new byte[PacketData.Length];
for (int i = 0; i < PacketData.Length - 4; i++)
{
EncryptedByte = ((ByteTable[(Counter & 0x0FF)]) ^ FlagByte) ^ PacketData[Counter];
EncryptedData[Counter++] = (byte)EncryptedByte;
DwordTableVal = (EncryptedByte ^ DwordVal) & 0x0FF;
DwordVal = (DwordVal >> 8) ^ Table[DwordTableVal];
checkSumData = CalculateChecksumTest(PacketData, DwordVal);
isChecksumCorrect = checkSumData.Take(4).SequenceEqual(encryptedData.Take(4)); //Checking the first 4 bytes from O_Buffer against what in the checksum data everytime time the for loop runs
if (!isChecksumCorrect)
{
Console.ForegroundColor = ConsoleColor.Red;
Console.WriteLine("Checksum is incorrect. DwordVal: [{0}] [{1:X2}]", i, ~DwordVal);
Console.ResetColor();
}
else
{
localDwordVal = DwordVal;
Console.ForegroundColor = ConsoleColor.Green;
Console.WriteLine("Checksum is correct. DwordVal: [{0}] [{1:X2}]", i, ~DwordVal);
Console.ResetColor();
}
}
CalculateChecksum(EncryptedData, localDwordVal);
return EncryptedData;
}
I'm just passing the byte[] encryptedData so I can test on it.
Here was the output
Code:
O_DwordVal: [0x7DA7B922]
N_DwordVal: [0xFFFFFFFF825846DD]
Checksum Bytes [0x82] [0x58] [0x46] [0xDD]
PacketID: [2040000] | PacketLength: [882]
Checksum is incorrect. DwordVal: [180] [FFFFFFFF57DD3A65]
Checksum is incorrect. DwordVal: [181] [FFFFFFFFB0882F68]
Checksum is incorrect. DwordVal: [182] [FFFFFFFFE56A5C52]
Checksum is incorrect. DwordVal: [183] [FFFFFFFF3A5F51E2]
Checksum is incorrect. DwordVal: [184] [FFFFFFFFBE3E2531]
Checksum is incorrect. DwordVal: [185] [FFFFFFFFB80CF15A]
Checksum is incorrect. DwordVal: [186] [FFFFFFFF49DE21CC]
Checksum is incorrect. DwordVal: [187] [FFFFFFFF492FF31C]
Checksum is incorrect. DwordVal: [188] [FFFFFFFF679B0F4F]
Checksum is incorrect. DwordVal: [189] [FFFFFFFF8CBB8D8C]
Checksum is incorrect. DwordVal: [190] [FFFFFFFFD28E5400]
Checksum is incorrect. DwordVal: [191] [FFFFFFFF5FD86C2C]
---> Checksum is correct. DwordVal: [192] [FFFFFFFF825846DD] <---
Checksum is incorrect. DwordVal: [193] [FFFFFFFFD65B91DE]
Checksum is incorrect. DwordVal: [194] [FFFFFFFF596A0CF6]
Checksum is incorrect. DwordVal: [195] [FFFFFFFF328E6C9F]
Checksum is incorrect. DwordVal: [196] [FFFFFFFFD486D4FE]
Checksum is incorrect. DwordVal: [197] [FFFFFFFF86083E70]
Checksum is incorrect. DwordVal: [198] [FFFFFFFF925BECD5]
Checksum is incorrect. DwordVal: [199] [FFFFFFFF182A76EB]
Checksum is incorrect. DwordVal: [200] [FFFFFFFF2BA31A94]
Checksum is incorrect. DwordVal: [201] [FFFFFFFF872C6AB8]
Checksum is incorrect. DwordVal: [202] [FFFFFFFFAC34BF5A]
Checksum is incorrect. DwordVal: [203] [FFFFFFFFC9AF7E49]
Checksum is incorrect. DwordVal: [204] [FFFFFFFF54189227]
Checksum is incorrect. DwordVal: [205] [FFFFFFFF5F5EFAEA]
Checksum is incorrect. DwordVal: [206] [FFFFFFFF4A8F91CB]
Checksum is incorrect. DwordVal: [207] [FFFFFFFF2A2ACE75]
Checksum is incorrect. DwordVal: [208] [FFFFFFFF1FFFC3D0]
Checksum is incorrect. DwordVal: [209] [FFFFFFFF39132671]
As you can see the correct checksum is when 192 bytes have been encrypted. So I am 100% confused to no end lol
|
|
|
|
|
03/05/2024, 08:46
|
#7
|
elite*gold: 293
Join Date: Jan 2012
Posts: 2,445
Received Thanks: 1,100
|
msg me on discord I guess. I'll help you solve the mistery.
|
|
|
|
|
03/06/2024, 03:52
|
#8
|
elite*gold: 0
Join Date: Oct 2007
Posts: 121
Received Thanks: 39
|
Quote:
Originally Posted by guesswho-.-
msg me on discord I guess. I'll help you solve the mistery.
|
You the man. I'll msg you tomorrow.
|
|
|
|
|
09/23/2024, 12:58
|
#9
|
elite*gold: 0
Join Date: Oct 2008
Posts: 266
Received Thanks: 96
|
i can help also if needed
|
|
|
|
|
04/16/2025, 06:15
|
#10
|
elite*gold: 0
Join Date: Oct 2007
Posts: 121
Received Thanks: 39
|
This is late late and I had it figured out for some time but I figured I would give an update for whoever would be interested in the future. The checksum is based on the payload length, not the length of the entire packet. Through reversing the function (Using the Sharing-La dekaron binary, it would be 0x004adc30) I noticed that the length of the packet and the payload size was different and the decryption process would only handle the payload length bytes. Below is my notes while reversing the functions a few times. I never went back and updated a lot of the comments but it was enough to help me figure out what was going on. It may be able to help someone else.
Code:
004ADC30 | 83EC 08 | sub esp,8 | allocate 8 bytes onto the stack
004ADC33 | 53 | push ebx | push ebx onto the stack
004ADC34 | 55 | push ebp | push ebp onto the stack
004ADC35 | 8BE9 | mov ebp,ecx | move ecx into ebp
004ADC37 | 8B5D 10 | mov ebx,dword ptr ss:[ebp+10] | move 4 byte ebp+10 into ebx
004ADC3A | 56 | push esi | push esi onto the stack
004ADC3B | 8B75 0C | mov esi,dword ptr ss:[ebp+C] | Move location of packet buffer into ESI
004ADC3E | 57 | push edi | push edi onto the stack
004ADC3F | 2BDE | sub ebx,esi | get buffer size. ebx holds that value
004ADC41 | BF 10000000 | mov edi,10 | move 10 into edi
004ADC46 | 3BDF | cmp ebx,edi | compare buffer and counter
004ADC48 | 895C24 14 | mov dword ptr ss:[esp+14],ebx | store buffer length
004ADC4C | 0F82 31010000 | jb dekaron.4ADD83 | jump below zero
004ADC52 | 8B4D 04 | mov ecx,dword ptr ss:[ebp+4] | move 4 bytes at ebp+4 into ecx
004ADC55 | E8 76E9FFFF | call <dekaron.sub_4AC5D0> | move ecx+0c into eax
004ADC5A | 8A48 01 | mov cl,byte ptr ds:[eax+1] | / move the low byte of eax+1 into low byte of ecx
004ADC5D | 3208 | xor cl,byte ptr ds:[eax] | \ xor low byte of ecx by low byte of eax
004ADC5F | 397D 18 | cmp dword ptr ss:[ebp+18],edi | compare current counter to max counter value
004ADC62 | 884C24 13 | mov byte ptr ss:[esp+13],cl | move low ecx byte to esp+13 | Will have XOR key in cl
004ADC66 | 73 54 | jae dekaron.4ADCBC | jump above or equal
004ADC68 | EB 06 | jmp dekaron.4ADC70 | jump
004ADC6A | 8D9B 00000000 | lea ebx,dword ptr ds:[ebx] | NOP operation
004ADC70 | 8B4D 18 | mov ecx,dword ptr ss:[ebp+18] | move current index counter into ecx
004ADC73 | 8A1431 | mov dl,byte ptr ds:[ecx+esi] | initial is get 5th byte in the packet. After that it gets byte based on counter
004ADC76 | 8B45 1C | mov eax,dword ptr ss:[ebp+1C] | get checksum value
004ADC79 | 8ADA | mov bl,dl | move encrypted byte from low edx to low ebx
004ADC7B | 33D8 | xor ebx,eax | xor last checksum value by encrypted byte
004ADC7D | C1E8 08 | shr eax,8 | shift checksum right by 8
004ADC80 | 81E3 FF000000 | and ebx,FF | get low byte from checksum
004ADC86 | 33049D D801A500 | xor eax,dword ptr ds:[ebx*4+A501D8] | xor eax by lookup_table+offset (offset from ebx*4) which gives new checksum value in eax
004ADC8D | 8945 1C | mov dword ptr ss:[ebp+1C],eax | move checksum value into ebp+1C
004ADC90 | 8BC1 | mov eax,ecx | move counter to eax
004ADC92 | 25 FF000000 | and eax,FF | keep lowbyte of eax
004ADC97 | 8A0485 D801A500 | mov al,byte ptr ds:[eax*4+A501D8] | move low byte into eax from the value at the lookup_table
004ADC9E | 32C2 | xor al,dl | xor lookup_table byte and current encrypted byte
004ADCA0 | 324424 13 | xor al,byte ptr ss:[esp+13] | xor al by xor key
004ADCA4 | 880431 | mov byte ptr ds:[ecx+esi],al | move unencrypted byte to position in buffer based on index
004ADCA7 | 8345 18 01 | add dword ptr ss:[ebp+18],1 | increment counter
004ADCAB | 397D 18 | cmp dword ptr ss:[ebp+18],edi | compare max (16) to the new incremented counter
004ADCAE | 72 C0 | jb dekaron.4ADC70 | jump if below
004ADCB0 | 8B4D 0C | mov ecx,dword ptr ss:[ebp+C] | move buffer into ecx
004ADCB3 | E8 880B0000 | call <dekaron.sub_4AE840> | Does something with bytes 4-16. After return EDX will have packet ID
004ADCB8 | 8B5C24 14 | mov ebx,dword ptr ss:[esp+14] | get buffer length
004ADCBC | 8B4D 0C | mov ecx,dword ptr ss:[ebp+C] | get buffer
004ADCBF | 0FB779 06 | movzx edi,word ptr ds:[ecx+6] | sets up new counter length based on the payload size in packet
004ADCC3 | 3BFB | cmp edi,ebx | compare buffer lengths?
004ADCC5 | 0F87 B8000000 | ja dekaron.4ADD83 | jump if above
004ADCCB | 81FF 00040000 | cmp edi,400 | compare buffer length to max buffer size
004ADCD1 | 0F87 AC000000 | ja dekaron.4ADD83 | jump if above
004ADCD7 | 397D 18 | cmp dword ptr ss:[ebp+18],edi | compare buffer length to counter
004ADCDA | 73 48 | jae dekaron.4ADD24 | jump if above or equal to
004ADCDC | 8D6424 00 | lea esp,dword ptr ss:[esp] | NOP
004ADCE0 | 8B4D 18 | mov ecx,dword ptr ss:[ebp+18] | set counter which should be 16
004ADCE3 | 8A1431 | mov dl,byte ptr ds:[ecx+esi] | get byte based on index in the buffer
004ADCE6 | 8B45 1C | mov eax,dword ptr ss:[ebp+1C] | store checksum
004ADCE9 | 8ADA | mov bl,dl | get encrypted byte into ebx
004ADCEB | 33D8 | xor ebx,eax | xor ecrypted byte by the checksum
004ADCED | C1E8 08 | shr eax,8 | shift right eax by 8 bits or 1 byte
004ADCF0 | 81E3 FF000000 | and ebx,FF | get low byte of ebx
004ADCF6 | 33049D D801A500 | xor eax,dword ptr ds:[ebx*4+A501D8] | xor eax by lookup_table+offset (offset from ebx*4) which gives new checksum value in eax
004ADCFD | 8945 1C | mov dword ptr ss:[ebp+1C],eax | save checksum value
004ADD00 | 8BC1 | mov eax,ecx | move counter into eax
004ADD02 | 25 FF000000 | and eax,FF | mask it
004ADD07 | 8A0485 D801A500 | mov al,byte ptr ds:[eax*4+A501D8] | get some value by xoring counter and value from lookup_table
004ADD0E | 32C2 | xor al,dl | xor encrypted packet by that byte
004ADD10 | 324424 13 | xor al,byte ptr ss:[esp+13] | xor encrypted byte by xor key
004ADD14 | 880431 | mov byte ptr ds:[ecx+esi],al | move unencrypted byte to array pos
004ADD17 | 8345 18 01 | add dword ptr ss:[ebp+18],1 | increment counter
004ADD1B | 397D 18 | cmp dword ptr ss:[ebp+18],edi | compare counter to buffer length
004ADD1E | 72 C0 | jb dekaron.4ADCE0 | jump if below
004ADD20 | 8B5C24 14 | mov ebx,dword ptr ss:[esp+14] | get buffer length
004ADD24 | 8B4D 1C | mov ecx,dword ptr ss:[ebp+1C] | get last checksum
004ADD27 | 8B45 0C | mov eax,dword ptr ss:[ebp+C] | get buffer start
004ADD2A | F7D1 | not ecx | flip bits essentially. All 1's become 0's vice versa
004ADD2C | 3B08 | cmp ecx,dword ptr ds:[eax] | compare not on checksum to see if it's the same as the first 4 bytes
004ADD2E | 894424 14 | mov dword ptr ss:[esp+14],eax | save checksum
004ADD32 | 75 4F | jne dekaron.4ADD83 | jump if checksums do not match
004ADD34 | 68 00040000 | push 400 | Arg1 = 400
004ADD39 | E8 41534A00 | call <dekaron.sub_95307F> | sub_95307F
004ADD3E | 2BDF | sub ebx,edi | subtract buffer length from 0400??
004ADD40 | 03F7 | add esi,edi | add 40 to esi
004ADD42 | 8945 10 | mov dword ptr ss:[ebp+10],eax | store the new location?
004ADD45 | 8945 0C | mov dword ptr ss:[ebp+C],eax | store new location again?
004ADD48 | 8D90 00040000 | lea edx,dword ptr ds:[eax+400] | load effective address or eax+400
004ADD4E | 8BCB | mov ecx,ebx | idk whats going on anymore
004ADD50 | 8BF8 | mov edi,eax | move new memory address location to edi
004ADD52 | 8BC1 | mov eax,ecx | at this point eax, ecx, and ebx are cleared out
004ADD54 | C1E9 02 | shr ecx,2 | shift ecx right 2 bits
004ADD57 | 8955 14 | mov dword ptr ss:[ebp+14],edx | save edx at ebp+14
004ADD5A | F3:A5 | rep movsd | copy 4 bytes in a loop from esi to edi
004ADD5C | 83C4 04 | add esp,4 | add 4 to esp
004ADD5F | 8BC8 | mov ecx,eax | 00 at this point
004ADD61 | 8B4424 14 | mov eax,dword ptr ss:[esp+14] | get pointer to buffer
004ADD65 | 83E1 03 | and ecx,3 | clear some bits?
004ADD68 | F3:A4 | rep movsb |
004ADD6A | 015D 10 | add dword ptr ss:[ebp+10],ebx |
004ADD6D | 5F | pop edi |
004ADD6E | 5E | pop esi |
004ADD6F | C745 18 04000000 | mov dword ptr ss:[ebp+18],4 | reset counter
004ADD76 | C745 1C FFFFFFFF | mov dword ptr ss:[ebp+1C],FFFFFFFF | reset checksum
004ADD7D | 5D | pop ebp |
004ADD7E | 5B | pop ebx |
004ADD7F | 83C4 08 | add esp,8 |
004ADD82 | C3 | ret |
004ADD83 | 5F | pop edi |
004ADD84 | 5E | pop esi |
004ADD85 | 5D | pop ebp |
004ADD86 | 33C0 | xor eax,eax |
004ADD88 | 5B | pop ebx |
004ADD89 | 83C4 08 | add esp,8 |
004ADD8C | C3 | ret |
I also took a look at packet 20081 and reversed that for a bit and seen how the Low and High byte gets set so that made it easier to keep track of.
@  I appreciate you always extending your help. You really are the guru around here. I wanted to figure it out on my own, otherwise I'd be like everyone else on this forum. Just waiting for someone to release something updated.
|
|
|
|
 |
Similar Threads
|
[Help] How to deal with empty string data in packet?
03/26/2015 - Mabinogi - 1 Replies
Hi All,
I'm trying to send a packet to load a skill but I can't seem to be able to reproduce the packet that's being sent when a skill hotkey is pressed. Here's the packet for loading smash:
Opcode: 00006982
00 T_WORD : 20002
01 T_STR :
I have tried to treat the T_STR data as "" and '\0' but neither of them worked. The client simply crashes when executing len = pkt_XXXX.BuildPacket( &p );
I've also tried to ignore the second data and send the packet with only T_WORD, this brings...
|
help about Char Data Packet
02/14/2013 - SRO Coding Corner - 6 Replies
hi gys
any one know C# code that can skip quest part in char data
// skill
02 //skill end
// quest part
|
[Help] Packet Editor - Comparing Socket Data.
07/29/2011 - General Coding - 9 Replies
Hello, I want to save and compare the data of a 2 packets,
and finding out if they contain the same data...
Thanks to u-coRe & Metin2Spieler97 i have something like this, and its working great!
Thanks for the help!!!
This part saves the 1rst packet to be compared.
bool paso0(const char* buf,int len){
|
[Question] Packet data , packet editing ??
10/13/2009 - 9Dragons - 2 Replies
I would like to know :
What is packet data?
How do i get the address for hacking a item in game?
How to use it ??
|
[help] Max HP/VE packet data
09/03/2009 - 9Dragons - 11 Replies
I've been trying for 2 days trying to find the maximum HP/VE in the socket data to no avail. Getting the current HP/VE is no problem. Just trying to find the your current max hp/ve is being tricky. Anyone else figured this out?
I'm beginning to think it is calculated within the client.
|
All times are GMT +1. The time now is 06:24.
|
|
![[Research / Help] Packet Data](https://www.elitepvpers.com/forum/iconimages/dekaron/research-help-packet-data_ltr.gif){kind=small}
