
Reversing The Pokerstars Protocol, Part 1: Compression and transport basics - daeken
http://daeken.com/reversing-the-pokerstars-protocol-part-1-comp
======
matt1
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...

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

------
sgrove
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?

~~~
daeken
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!

~~~
BrentRitterbeck
This is a discussion of the LZH-Light algo.

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

~~~
daeken
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.

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

~~~
sgoranson
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.

