Luigi Auriemma

I'm not sure if you had much time to invest into looking at the exploits or vulnerabilities of call of duty 5.

I was hoping you found some good tricks, such as you did with Call of Duty 4 such as the in game denial of service bug.

The game is set to release on Tuesday.

well what i found is that the beta has lots of bugs, but i didn't record any o_o

lol alright. I know there was the roundhouse glitch.. that was fun..

I was just curious if there were any proof of concepts such that as of Call of Duty 4.

I tried it with CoD 5 Version 1.1, any idea how to fix that?

depends by the entire "connect" packet expected by the server.
I don't have the game so I can't test it anyway if you can catch the "connect" packet with wireshark (it's really simple, this one is one of the first packets) when you connect your client to a server I can give a look to it although I bet it uses some authorization/internet checks.

I'll download the retail game again and try to get some captured packets for you guys to look at. I tested it out for the cod5 beta a while ago, and had no luck with fake players. You can take a look at my latest post here to see what I came up with: fake-player-dos-cod4-t454.html#p4611

I'll post back when I get some captured packets.

today I have given a quick look to the cod5 beta server and I have made a blind research to figure the bdTicket and bdTicketTime parameters (thanx to SomaFM who talked about them in the other post).
I have defined it a "blind" research because the beta client doesn't work so I have worked only on the server.

the authentication (?) mechanism and the algorithms (bdcrypto) are parts of DemonWare so this stuff is not related uniquely to cod5 but probably to any game which use DW.
bdcrypto is constituited by the following parts:
- the encryption key: provided by the server, it's the Tiger192 hash of the server's cdkey
- 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 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 (0xdeadbdef in big endian), if it differs the client is rejected with that command showed in q3fill.

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.

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).

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.

*EDIT* removed the useless quoting

uhm

this would me you only need to know this magic hash of server and you could connect to server ?

if i would get this hash manually and insert it in code of fakeplayer eg

would it be possible to establish a connection and receive the challengeresponse packet from a waw server without communicating to the demonware services? but i do think a cdkey packet to the master server is still needed for keyauthrize?

if you get the remaining part of the hash it's enough that you specify it in q3fill with the -d option and it does the job.
if you want to make the test with your own server just put there the full cdkey and it will work too (in my tests with cod5 beta worked perfectly).

for the rest I don't know because I don't have the game and so have not checked the master server's protocol or how to get that remaining part of the hash

yes i was about doing it on my own server, so i do only need the hash of server

but,

i still dont know howto make the guid from a codwaw cdkey without the game

with cod4 it works fine

hmm ill try it

Hello, i tested it with the q3fill and it doesnt work. As you said the problem i think is demonware