this is a quick and short description of the mechanism used in Call of
Duty World at War for authorizing the players to join the game servers.
the game uses DemonWare for this job so the following technique can be
valid for other games which use the same authorization mechanism/sdk.

note that my research is INCOMPLETE because I don't know when and how
is got the 16 bytes hash of the server (probably when the client logs
in the authorization server) because I don't have the game and I don't
have much interest in it.

this authorization mechanim adopted by DemonWare is called bdcrypto and
is constituited by the following parts:
- the encryption key: provided by the server, it's the Tiger192 hash of
  the server's cdkey (the original key like AAAA-BBBB-CCCC-DDDD-EEEE)
- the client IV: the first 4 bytes of the bdTicket data, here is
  performed a Tiger192 hash to get the IV data
- the encrypted data: a structure located just after the first 4 bytes
  of the bdTicket data
- bdTicketTime: base64 string of the client's system time, it's used for
  an useless check which can be bypassed using 0xffffffff so don't care

both bdTicket and bdTicketTime are base64 strings.

the encryption is a classical 3DES CBC which uses the cdkey hash of the
server as key and the hash of those 4 bytes of the client as IV (a
sequence of bytes for XORing the output making the encryption
stronger), and its purpose is to allow the client to pass a structure
containing the following fields:
- Ticket challenge (32bit)
- License type (8bit)
- unused (64bit)
- client time (32bit)
- UserID (64bit)
- LicenseID (64bit)

the only "required" field is the first which must be equal to
0xefbdadde (or 0xdeadbdef in big endian), if it differs the client is
rejected.

when the client requests the server's challenge it replies with the
challengeResponse packet containing the classical challenge number
followed by a strange string.
this string is the base64 encoding of the first 8 bytes of the
encryption key used on the server (so the first 8 bytes of the hash of
the server's cdkey).

at this point the only thing which is missed in the client is the rest
of the key, so a 16 bytes string (because the Tiger hash is 24 bytes
long) which I "guess" is provided by the master server during the
authorization/authentication/listing.

so resuming, the following is the tiger hash of the server's cdkey:
  ########OOOOOOOOOOOOOOOO
  |       |
  |       probably got from the authorization server
  received by the same server

what I don't understand is what is the purpose of all this, in fact the
cdkey used on the server is ever the same so it's enough to get the
remaining 16 bytes of the hash one time to no longer need the
authentication (theorically because I don't have the client for the
tests to verify if are performed other cross checks on the server).

for explaining everything better I have built a quick decrypter which
requires only 2 arguments, the cdkey of the server (or directly its
tiger192 hash) and the data contained in the bdTicket field:

  http://aluigi.org/papers/dwbdcrypto.zip

so that code emulates exactly what happens on the server when the
bdTicket is received and can be used to decrypt it from a sniffed
"connect" packet to understand the fields of bdTicket.
