Difference between revisions of "Warden Packets"

From SkullSecurity
Jump to navigation Jump to search
Line 25: Line 25:
On Starcraft, the first 4 bytes of the CDKey hash are used. That's the actual CDKey has that's sent over the wire as part of SID_AUTH_CHECK.  
On Starcraft, the first 4 bytes of the CDKey hash are used. That's the actual CDKey has that's sent over the wire as part of SID_AUTH_CHECK.  


==Packet codes==
==Packet Codes==
The packet structure for Warden is very simple. The received packets, once decrypted, are in the form:
[1 byte] code (0, 1, or 2)
[array] data
 
And the response is usually a single encrypted byte, either 0 (for "fail") or 1 (for "success"). The exception is the response to the 0x02 packet.


===0x00===
===0x00===
Line 33: Line 38:
[4 bytes] length of the current module
[4 bytes] length of the current module


There are two possible responses, both one byte:
A response of 0 will tell Battle.net to send you the current module, and you'll receive a slew of 0x01 packets. 1 will tell Battle.net you already have the module, and you'll receive a 0x02 packet.
{ 0 }


===0x01===
===0x01===
0x01 packets have the form:
[1 byte] code (0x01)
[2 bytes] length (without the 3-byte header)
[array] data
You will receive a number of 0x01 packets, until the total length of "data" received is equal to the length sent in packet 0x00.
===0x02===
===0x02===
This packet is a request to validate the running game to verify it's legit.
I haven't reversed it yet, and don't plan to in the near future.

Revision as of 04:10, 27 February 2008

This is about how to encrypt/decrypt the Warden packets, and what they mean.

Generating encryption keys

Generating the keys used for encrypting Warden packets is a somewhat convoluted algorithm, but it is fairly simple to implement. Here are the basic steps:

  1. Create a source of shared random data based on a seed
  2. Generate the outgoing key from the first 0x10 bytes
  3. Generate the incoming key from the next 0x10 bytes

The random source is basically a struct with 4 fields, which are initialized as such:

  • Current position [0x04 bytes]: 0
  • Data 1 [0x14 bytes]: 00 00 00 ....
  • Data 2 [0x14 bytes]: WardenSHA1(first half of seed)
  • Data 3 [0x14 bytes]: WardenSHA1(second half of seed)

Data is read one byte at a time, and Current position is incremented. Immediately after being created, or when Current position reaches 0x14, an update is performed:

  • Current position = 0
  • Data 1 = SHA1(Data 2, Data 1, Data 3)

That's it! All that's left is to read 0x10 bytes, generate the outgoing key (using the key generation function in Crypto_and_Hashing#Xor_Encryption), read 0x10 more bytes, and generate the incoming key.

Here is the code in C and in Java.


The Key

On Starcraft, the first 4 bytes of the CDKey hash are used. That's the actual CDKey has that's sent over the wire as part of SID_AUTH_CHECK.

Packet Codes

The packet structure for Warden is very simple. The received packets, once decrypted, are in the form: [1 byte] code (0, 1, or 2) [array] data

And the response is usually a single encrypted byte, either 0 (for "fail") or 1 (for "success"). The exception is the response to the 0x02 packet.

0x00

0x00 is a request sent from the server asking if you have the current warden module. It is in the following form: [16 bytes] name of the current module [16 bytes] decryption key for the current module [4 bytes] length of the current module

A response of 0 will tell Battle.net to send you the current module, and you'll receive a slew of 0x01 packets. 1 will tell Battle.net you already have the module, and you'll receive a 0x02 packet.

0x01

0x01 packets have the form: [1 byte] code (0x01) [2 bytes] length (without the 3-byte header) [array] data

You will receive a number of 0x01 packets, until the total length of "data" received is equal to the length sent in packet 0x00.

0x02

This packet is a request to validate the running game to verify it's legit.

I haven't reversed it yet, and don't plan to in the near future.