[Question] Proxy - deciphering server key packet

Page 3 of 4

11/22/2010 01:43 denominator#31

I`m sure the password for the rar is "Send"

11/22/2010 02:35 shitboi#32

Quote:

Originally Posted by pro4never

So you know... all packets for game server are decrypted/encrypted even before the exchange is complete.

Not all values are initiated yet. That could be some of the problems you are having with setting up the keys.

@ bad image exception. I'm fairly sure that had to do with the loading method of the native calls or possibly it referencing x84 vs x64 files... I forget which (usually when I've seen that error it has to do with needing to change the dllloader settings or use a different dll)

For some reason i am still having a bit of issues with server DH packet. I logged a few of my decrypted DH packets and realized an astonishing pattern ( which should not be happening) that is, all the readable spectrum of the packet are exactly the same for all packets logged. See quote

Quote:

[Sun Nov 21 21:33:22 2010]�l"��3x�!�^ ( ( "�v
��ܟ|��l��J)�%��b�d˔Y�`Ǐ�[� ��p+1� S�T-��}ـ A320A85EDD79171C341459E94807D71D39BB3B3F3B5161CA84 894F3AC3FC7FEC317A2DDEC83B66D30C29261C6492643061AE CFCF4A051816D7C359A6A7B7D8FB 05� 660811FF745F03973DE6DA19F81BC651A6B09C7B1816A2937C 6BDADBE78E9FB9A66C6F98873B3CA49DB3E8F47E1E8DC860EB 941E3A6D9FF13A613A5A603053E2TQServer

[Sun Nov 21 21:33:49 2010]��[=>�`X " ��g��?c)�Z%�b�,�2K��T��- s�m�̅!� �0W�U�� A320A85EDD79171C341459E94807D71D39BB3B3F3B5161CA84 894F3AC3FC7FEC317A2DDEC83B66D30C29261C6492643061AE CFCF4A051816D7C359A6A7B7D8FB 05� 660811FF745F03973DE6DA19F81BC651A6B09C7B1816A2937C 6BDADBE78E9FB9A66C6F98873B3CA49DB3E8F47E1E8DC860EB 941E3A6D9FF13A613A5A603053E2TQServer

[Sun Nov 21 21:34:36 2010]|G ��ޫ&ĆF j�}�\3A@
^�"~ �6f�1�� ᕃ��Gπ A320A85EDD79171C341459E94807D71D39BB3B3F3B5161CA84 894F3AC3FC7FEC317A2DDEC83B66D30C29261C6492643061AE CFCF4A051816D7C359A6A7B7D8FB 05� 660811FF745F03973DE6DA19F81BC651A6B09C7B1816A2937C 6BDADBE78E9FB9A66C6F98873B3CA49DB3E8F47E1E8DC860EB 941E3A6D9FF13A613A5A603053E2TQServer

[Sun Nov 21 21:35:04 2010]��q��B ��r�;�,�� 9� �Q��,6�p� A320A85EDD79171C341459E94807D71D39BB3B3F3B5161CA84 894F3AC3FC7FEC317A2DDEC83B66D30C29261C6492643061AE CFCF4A051816D7C359A6A7B7D8FB 05� 660811FF745F03973DE6DA19F81BC651A6B09C7B1816A2937C 6BDADBE78E9FB9A66C6F98873B3CA49DB3E8F47E1E8DC860EB 941E3A6D9FF13A613A5A603053E2TQServer

[Sun Nov 21 21:35:40 2010]��m�"/�D @ �-� n�� CJl(��8 %.Dӝ�� A320A85EDD79171C341459E94807D71D39BB3B3F3B5161CA84 894F3AC3FC7FEC317A2DDEC83B66D30C29261C6492643061AE CFCF4A051816D7C359A6A7B7D8FB 05� 660811FF745F03973DE6DA19F81BC651A6B09C7B1816A2937C 6BDADBE78E9FB9A66C6F98873B3CA49DB3E8F47E1E8DC860EB 941E3A6D9FF13A613A5A603053E2TQServer

[Sun Nov 21 21:36:14 2010]L9��|�=@�@
3
�5q:̓ ��
n�? ��x;k:�� A320A85EDD79171C341459E94807D71D39BB3B3F3B5161CA84 894F3AC3FC7FEC317A2DDEC83B66D30C29261C6492643061AE CFCF4A051816D7C359A6A7B7D8FB 05� 660811FF745F03973DE6DA19F81BC651A6B09C7B1816A2937C 6BDADBE78E9FB9A66C6F98873B3CA49DB3E8F47E1E8DC860EB 941E3A6D9FF13A613A5A603053E2TQServer

[Sun Nov 21 21:36:37 2010]��ڛ�<��F j o�6l��-T�A�cp ��'�Ȁ� -�)�*׀ A320A85EDD79171C341459E94807D71D39BB3B3F3B5161CA84 894F3AC3FC7FEC317A2DDEC83B66D30C29261C6492643061AE CFCF4A051816D7C359A6A7B7D8FB 05� 660811FF745F03973DE6DA19F81BC651A6B09C7B1816A2937C 6BDADBE78E9FB9A66C6F98873B3CA49DB3E8F47E1E8DC860EB 941E3A6D9FF13A613A5A603053E2TQServer

This puzzles me because after seeing the trailing stamp - TQServer, i am certain that this packet has been successfully decrypted. yet i am seeing weird headers and repeating body. The packet should theoractically include clientIV, serverIV, p, g, ServerPublicKey. At the very minimum, it makes sense for the first 4 fields to be constant, but ServerPublicKey has to be a variant.

I tried to perceive the occurrences of 05 as the g field of the packet. but when compared to tannel's source, g should be of an Int32, but 05 is only 1 byte, that leads me to wonder if the other empty bytes contributes to the weird chars around 05. Similarly, On conquerwiki, clientIV and serverIV are supposely 8 bytes, which is algorithmically true. However in tannel's source,

Code:

            ServerIV = BR.ReadBytes(BR.ReadInt32());
            ClientIV = BR.ReadBytes(BR.ReadInt32());
            P = Encoding.ASCII.GetString(BR.ReadBytes(BR.ReadInt32()));
            G = Encoding.ASCII.GetString(BR.ReadBytes(BR.ReadInt32()));
            Server_PubKey = Encoding.ASCII.GetString(BR.ReadBytes(BR.ReadInt32()));

ServerIV and clientIv are only 4bytes? I am really confused. Well, up to this stage, everything is deduced from observations.

Am i missing something ? Are these packets really valid?

11/22/2010 13:18 pro4never#33

Quote:

Originally Posted by vDrag0n

Has anything changed till then? Thought it wasnt

It consists of like 5 minutes of packet changes to make it work again lol...

11/22/2010 13:54 Kiyono#34

Quote:

Originally Posted by pro4never

It consists of like 5 minutes of packet changes to make it work again lol...

But how are you supposed to log the packets you need without a working proxy in the first place?

11/23/2010 06:57 pro4never#35

Quote:

Originally Posted by Kiyono

But how are you supposed to log the packets you need without a working proxy in the first place?

The proxy works just fine. It simply needs its handling of packets updated. AKA log what the server is sending and then change a few lines of code in the proxy.

11/23/2010 10:03 xmen01235#36

p,g, clientIV, serverIV and Server Public were already on that packet. You can use binary reader to get those values. I forgot the number of junk bytes but that is where you are going to start on reading your known(p,g,etc..) data.

After you figured out that one you can start setting up your DH key exchange for both the server-proxy and proxy-client connection.

And finally you will go to korvacs wiki for packet information.

11/23/2010 16:53 denominator#37

Code:

AKA log what the server is sending and then change a few lines of code in the proxy.

By using the proxy to log what the server sends?

11/23/2010 21:54 shitboi#38

Quote:

Originally Posted by xmen01235

p,g, clientIV, serverIV and Server Public were already on that packet. You can use binary reader to get those values. I forgot the number of junk bytes but that is where you are going to start on reading your known(p,g,etc..) data.

After you figured out that one you can start setting up your DH key exchange for both the server-proxy and proxy-client connection.

And finally you will go to korvacs wiki for packet information.

Awesome ... This is what i need to solve my problem. On first page pro4never posted tannel's codes, which suggests 11 bytes of junk data.

Test result. packet_size - packet_data_size is always 11 -> junk size.
Also, i have correctly obtained all the information.

However just a side track, why is it that p,g,A always the same? are we going to solely rely on the clientiv and serveriv for encryption/decryption? I have yet to verify if clientiv and serveriv is varying or constant.

11/24/2010 09:10 xmen01235#39

Quote:

Originally Posted by shitboi

Awesome ... This is what i need to solve my problem. On first page pro4never posted tannel's codes, which suggests 11 bytes of junk data.

Test result. packet_size - packet_data_size is always 11 -> junk size.
Also, i have correctly obtained all the information.

However just a side track, why is it that p,g,A always the same? are we going to solely rely on the clientiv and serveriv for encryption/decryption? I have yet to verify if clientiv and serveriv is varying or constant.

Check your PM ....

11/24/2010 11:28 ChingChong23#40

strip tanels C# proxy and when they log in, after packet gets decrypted send the whole decrypted packet to your java proxy, do what you want, then send it back to the C# proxy to get encrypted and sent.

throwing the options out there.

11/24/2010 14:16 shitboi#41

Quote:

Originally Posted by xmen01235

Last time I check
...
...

The code snippet above is just for example purposes and you may need to debug it if you want to use it.

Goodluck...

Wow, that was comprehensive.. That actually make me wonder. did you have a similar post like this on c@deXpl0si0n? I think you even used the exact same forumname, lol. But this time it is alot more clearer.

However i do have another question. If i remembered correctly every blowfish decrypts or encrypts something, it only requires ONE initial vector.

so. in the case of Server-Client interaction ...

client initialize blowfish with serverIV to decrypt packets?
eg: Blowfish clientBlow = new BlowFish();
clientBlow.initialize(key, serverIV);
clientBlow.decrypt(packet);

client initialize blowfish with clientIB to encrypt packet?
eg: clientBlow.initialize(key, clientIV);
clientBlow.encrypt(packet);

Are above what is really happening? I have not really checked if btoh IV are the same (shouldn't be) and I thought this is sensible because there is no reason to send 2 IV to client if client doesn't need to use them both.

11/25/2010 01:36 xmen01235#42

Quote:

Originally Posted by shitboi

Wow, that was comprehensive.. That actually make me wonder. did you have a similar post like this on c@deXpl0si0n? I think you even used the exact same forumname, lol. But this time it is alot more clearer.

However i do have another question. If i remembered correctly every blowfish decrypts or encrypts something, it only requires ONE initial vector.

so. in the case of Server-Client interaction ...

client initialize blowfish with serverIV to decrypt packets?
eg: Blowfish clientBlow = new BlowFish();
clientBlow.initialize(key, serverIV);
clientBlow.decrypt(packet);

client initialize blowfish with clientIB to encrypt packet?
eg: clientBlow.initialize(key, clientIV);
clientBlow.encrypt(packet);

Are above what is really happening? I have not really checked if btoh IV are the same (shouldn't be) and I thought this is sensible because there is no reason to send 2 IV to client if client doesn't need to use them both.

Yep I am using same forum ID here in epvp and cxp. There is much more comprehensive posting there in cxp which was created by Zaad but nonetheless the posting above will just summarized as exactly same with him.

You don't need to initialize the vectors for each blowfish crypthographer in the pre-handshaking stage but you will use and update these blowfish vectors after the handshaking where you have computed already the shared key for both connections.

11/26/2010 06:09 denominator#43

Ok I now have a 64bit PC and libeay32 doesn`t seem to want to get rid of the bad image thing >.< Where should I put the libeay32.dll? Or will I need a libeay64.dll o.0?

11/26/2010 15:12 gorgone#44

im try to start a proxy but work with memory is more easy

if is possible can i have the password of rad' ,... isn t SEND

thx

11/27/2010 01:15 denominator#45

No it isnt SEND it`s Send lol. Password is case sensitive.

Page 3 of 4