SRO encryption/decryption algoritm

I need help to build packet sniffer. Private keys, crption algorithm...
Could you help me obtain up-to-date information?

All you need is [Only registered and activated users can see links. Click Here To Register...] stuff. Here are introduction into silkroad security, for more just check his other threads.
Here is C# code [Only registered and activated users can see links. Click Here To Register...]

Quote:

Originally Posted by YuBeDev All you need is [Only registered and activated users can see links. Click Here To Register...] stuff. Here are introduction into silkroad security, for more just check his other threads. Here is C# code [Only registered and activated users can see links. Click Here To Register...]

Thanks bro:bandit:

There isn't one static server private key that you can extract once and reuse. SRO derives a Blowfish session key for each connection during the 0x5000 security handshake.

The handshake uses a customized Diffie-Hellman exchange, basically G^X mod P with 32-bit values, plus Silkroad's own key transforms. Flow's roughly: server sends 0x5000 with flag 0x0E, including the security configuration, count/CRC seeds and handshake values; client replies with its public value and handshake data; server sends 0x5000 with flag 0x10; client finishes with 0x9000. From that handshake, both sides derive the final Blowfish key for the connection.

After that, packets with the 0x8000 bit set in the size field are Blowfish-encrypted. One gotcha with the old security guide: some copies use size & 0x7FF, which is wrong. The real size is the low 15 bits: size & 0x7FFF.

Encryption is separate from the count/CRC security bytes. For passive decoding, you don't need to generate them, but if you modify or inject packets, you need to get them right, or you'll get disconnected.

For a sniffer, I'd start with a security-aware local proxy using SilkroadSecurityAPI, so it maintains the handshake/session state and hands you decrypted packets directly. JellyBitz's srodevs-docs repo collects most of the old material worth reading, including Drew Benton's security guide, jMerlin's security-byte writeup, and the protocol docs.

Quote:

Originally Posted by RyuzakiH There isn't one static server private key that you can extract once and reuse. SRO derives a Blowfish session key for each connection during the 0x5000 security handshake. The handshake uses a customized Diffie-Hellman exchange, basically G^X mod P with 32-bit values, plus Silkroad's own key transforms. Flow's roughly: server sends 0x5000 with flag 0x0E, including the security configuration, count/CRC seeds and handshake values; client replies with its public value and handshake data; server sends 0x5000 with flag 0x10; client finishes with 0x9000. From that handshake, both sides derive the final Blowfish key for the connection. After that, packets with the 0x8000 bit set in the size field are Blowfish-encrypted. One gotcha with the old security guide: some copies use size & 0x7FF, which is wrong. The real size is the low 15 bits: size & 0x7FFF. Encryption is separate from the count/CRC security bytes. For passive decoding, you don't need to generate them, but if you modify or inject packets, you need to get them right, or you'll get disconnected. For a sniffer, I'd start with a security-aware local proxy using SilkroadSecurityAPI, so it maintains the handshake/session state and hands you decrypted packets directly. JellyBitz's srodevs-docs repo collects most of the old material worth reading, including Drew Benton's security guide, jMerlin's security-byte writeup, and the protocol docs.

That was an informative answer, thank you. I see there are many silkroad versions. Which one is worth playing or experimenting with officially?

Quote:

Originally Posted by blacklogic That was an informative answer, thank you. I see there are many silkroad versions. Which one is worth playing or experimenting with officially?

In my opinion the best way to play and understand it is to start your own local vsro pserver.
It is easy to do, you can even have it on virtual machine.

That way you will have ideal test environment. Once you know how vsro does it you can work with other versions.