-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WorldEncryption is not similar to the official server in some packets. #4
Comments
Hello, thanks for your report. May I know how did you get the "official" payload? This is easy to change in the repo (in fact you just need to replace the encryption/decryption tables from Server.py with those from Client.py), however I remember I introduced it on purpose, because I saw the server has got the new line character in the encryption table. I need to double check it. |
Thank you very much for the prompt reply. I guess replace the encryption table won't solve the problem. plain text => "clist_start 0\n" plain text => "clist_end\n" As the result, the way that new line is packed is depend on the previous character. |
When you change the lines number 3 & 4 in Server.py from
to
does it work as intended? That is how it works after the change:
So it looks like the "clist_start 0\n" is encrypted correctly, but what about "clist_end\n"? What is the desired output for this in your opinion? |
sorry for late response. Your result after change encrypted table.
The correct one is
It seems like the last 4 bytes is in correct. Here is a full packet that I received from official.
Decrypted:
|
Hi.
I found that packet that has '\n' followed by the char(the char that should XOR by 0xFF only ex. "clist_end\n") the new line should XOR by 0xFF as well, but in this repo, the new line is consider to be encrypted in encryption table.
example :
plain packet => "clist_end\n"
encrypted packet from the official => "\x0A\x9C\x93\x96\x8C\x8B\xA0\x9A\x91\x9B\xF5\xFF"
encrypted packet from this repo => "\x09\x9c\x93\x96\x8C\x8B\xA0\x9A\x91\x9B\x81\xE0\xFF"
This won't affect the decryption in the client.
The client decryption is capable to decrypt both encrypted packets to the desired result.
The text was updated successfully, but these errors were encountered: