pouët.net

Hi all!

DICE are looking for some badass lowlevel programmers who want to do anti-cheat work. Are you interested in living in Stockholm and working with me and the rest of the crew and improving the online experience in the Battlefield series?

If you are fly with OllyDbg / IDA Pro, know your way around the Windows kernel, can spot dodgy practices hidden deep within the bowels of massive C++ codebases, and want to evangelize security-aware development practices to the rest of the games team, then this might be the gig for you.

The original job ad is available here.

Comments? Questions? Ask them here, or contact me directly at <mikael dot kalms at dice dot se>.

http://www.youtube.com/watch?v=dAOvNRA3G7c

Yup. Which is one of the arguments for why we should staff up and put in a more serious effort against cheating in the game.

compared to mw3 bf3 is like 100% safe & hackfree ;) - i love it..

Taking the fun out of wireshark :(

god all I see is people stabbing and shooting each other....

Navis: Well, that's just because this is montage of kills. I really hope that this game is a bit more than that. Or at least the amount of killing is not as huge as on that video.

(never played that game)

What the hell were you expecting from a game called Battlefield? :D

It really, really is :)

I dunno... bunnies and flowers? :)

you mean t-rexes and teddybears!

IDA Pro <3 :)

if( crc(collision_check_and_stuff_routs) != VALID_ID )
{
if( (gui_items_disable_counter--) < 0)
disable_gui_items();
}

that's what at least Dragonflight on Atari ST did in some very strange way.

Does this mean there will be a new TBL demo again? Amigaaaaa!!!! :)

lsl: That's kindergarten stuff, all of that in BF3 (I suppose) is done server-side with client-side prediction, everything is safe and validated. The actual trickery comes from the client knowing data the player shouldn't know, like positions of the enemy on the map - it's a fairly tactical shooter, and seeing the enemy before they do you is important. If you can modify the client (or hook) in a way that the enemies have big yellow rings around them, you basically won the match before it started. Consider also stuff like automatic aiming and firing (i.e. the client calculates line-of-sight to the hitbox with the biggest damage and fires the appopriate weapon as soon as an enemy is visible) and you're basically playing with a bot.

Plus add to the mix that this stuff isn't done with patching anymore, they simply route out function calls in memory (the very same way .kkapture does) and trick the game into thinking it's completely legit. As far as I know, most of the protection against this is done via the game constantly checking other processes and looking for footprints of detouring. (I've done something similar for our game, which resulted in a hilarious little episode where the engine refused to run, because it thought .kkapture was a cheat app.)

i'll just leave it here: http://graphics.stanford.edu/~mdfisher/GameAIs.html

sry, forgot to prettify: http://graphics.stanford.edu/~mdfisher/GameAIs.html

so it was that much "kindergarten stuff" that no one managed to crack that game until 2006 ?
Come on...

how'd you void the trickery to let clients know what they shouldn't? simulate all clients on the server and only send the clients data they should see. there're costs on it.

dunno much about trampolines but how'd you hook a client to calc los if the engine itself is a closed and verified code and the only valid input should be buttons?!

The engine itself might be closed but you can usually expect the codebase to be too large and complex to be 100% verified. So there are weak areas there, which are impossible to see by running the game normally, but can be exploited.

Then you have the inherent latency of the Internet. Sometimes you do want to send more information down to the client than you ideally should, in order to allow the client to run a low-latency simulation of the local world. Imagine for instance if the server did visibility tests, and only sent location informations about players to those which are able to see them (according to the server's world simulation state). What happens when a client turns around quickly? Will that client have to wait for the server to realize that the client has turned around, before the client receives info about the players that came into view? Or is that too game-breaking?
There is a large number of tradeoffs there that are about masking networking lag, where improving the player experience requires the client to know a bit more than it ideally should.

lsl: i dont know how old the game is, but i suppose at the time it was a tough cookie (given the devenvironments at the time) and then at some point some people stopped caring? it's not like people constantly tried to crack it for 15 years.

yumeji: example - i hook all d3d calls and render all objects that use the skinning shader without the z-buffer and with a large glow -> all human characters are easily visible through objects.

Also known as the "All Points Bulletin server-side vehicle simulation" syndrome :)

[qoute]example - i hook all d3d calls and render all objects that use the skinning shader without the z-buffer and with a large glow -> all human characters are easily visible through objects.[/quote]

yeh. I get this. but that's something you could trap cause the call destination isn't the same anymore if you inject detours. you could even hash the whole d3d.dll to verify an injection. but sure it's a bit costly to do lots of times in a game.

and about that turn around thing: this is what I meant with costs. you'd need a fast responding system which is not necesarily available.

or you just go for console only and get rid of all cheaters.. which kind of suck too..

I don't know what DICE are thinking, wanting to hire actual experts, when they can get advice like this for free on Pouet!