Reversing The Pokerstars Protocol, Part 1: Compression and transport basics | Hacker News Reader

Reversing The Pokerstars Protocol, Part 1: Compression and transport basics

daeken.com

34 pointsdaeken8 comments

Great article.

I built a poker bot (see my submissions for more info) and can safely say that if your original intent was to build one too, you would have been way better off screen scraping. It's not nearly as elegant or as cool, but it gets the job done with minimal effort.

One note, which you all might find interesting. A lot of people have tried to do what daeken has done, not necessarily for botting purposes but in hope that the decrypted traffic would contain your opponent's holecards. I had a program at one point that someone built that decrypted about half of the incoming traffic. Not very useful, but cool nonetheless. A few people succeeded in decrypting the entire thing and discovered, to their dismay, that it doesn't contain holecard information. Go figure.

When a hand goes to showdown, the loser can muck his or her cards, meaning they don't show it to the table. Anyone seated at the table can view the hand history and see what the mucked cards were, but its hidden from people observing the table. The people who cracked the transport algorithm were able to extract this information, meaning they could log all the showdown hands for every game on PokerStars. I'm not sure what they did with this ability, but they could made some money quietly following around high stakes players, recording all of their hands and mucked cards, and selling it to their competition, who could use the information to decypher and exploit their weaknesses.

I wonder what PokerStars will do now...

Thanks much for the article. As a sometimes PokerStars player and fulltime software guy, this stuff (including the Coding the Wheel article set on a poker bot) is super interesting.

I haven't been playing as much online this past year and recently exchanged a series of emails with PokerStars support. Basically, I was arguing for the ability to have a pseudonym instead of a fixed logon displayed as a user and in log files. It seems like a simple step to kind of cut-off lowest hanging fruit for unethical players. Some of the heads-up displays (skins riding on top of the poker stars client) are showing opponent hand ranges based on data mining game logs. This seems like something that should be part of the thinking process of the game, not your HUD tools. No casino is going to let you sit down with your snazzy odds calculator at the poker table.

The official response is that this is info that a player knows about the opponent anyway and doesn't represent any threat to the integrity of the game. Course, maybe I read too many postings from players who are multi-tabling 24 games at once with their backend dbs and HUDs.

Very fun read. I love seeing into the mind of someone as they reverse-engineer protocols and such.

Looking forward to part two - what's the next step?

The next step is documenting how the service connections actually operate, and showing some basic connections, e.g. getting lobby data. I likely will also include my protocol wrappers used in the client and server (they use a common network library) and show the initial steps of the server emulator.

Thanks for reading!

This is a discussion of the LZH-Light algo.

http://www.ddj.com/cpp/184403560?pgno=5

I attempted to implement it based on that and reading the C++ code I found, but the descriptions didn't match up to the code, and it was simply too vague to pull it off. In the end, I think just using the code I found was the best route; wish I hadn't wasted days trying to implement it myself.

I tried to pack a lot of info into this post (perhaps more than I should've), so some of it may be unclear. If anything doesn't make sense or isn't explained well enough, let me know and I'll try and explain it to the best of my ability.

Neat stuff, your Nethooker lib looks pretty nifty. I was confused about how the server emulator worked, or even what it was exactly. From your comment above, maybe that's a part II topic. A high level diagram of the key components would be helpful I think.

Reply on news.ycombinator.com