i had a conversation with stars support/security recently on the subject. HUDs are allowed, but there s no obvious way to get the required data for them. so i wondered how PokerTracker (and others) are doing this. all i have is the somewhat cryptic sttement from stars that while they can not disclose what PT does they don't mind them doing so. and that intercepting messages (on the windows client) is not considered a breach their ToS. chances are i am overlooking something obvious, but poking around in the client i could not get much of the required information:

- from the log file one could potentially take number of players being dealt in a hand and their seat numbers
- from tables child window with class name "PokerStarsNoteSelectorClass" one can get the list of players seated (in cash-game this list may contain players from other tables and players who already left)
- hand histories are useless for the task because they get send from server to client no sooner than when a hand is completed. for zoom poker this means that the user may be seated many hands away when this happens.

the missing piece of information is a mapping from player names to seat numbers. so here comes the challenge: how to obtain data regarding this from the client ? as a note: any form of OCR is ruled out for, as i hope obvious reasons. and yes, all code here should be open source.


to make a start, here is what i found out about the "PokerStarsNoteSelectorClass" child window:
it behaves like a standard ComboBox, that is you can send CB_* messages to it as defined in comctrl.h.

- (CB_GETCOUNT, wParam 0, lParam 0) will get you the number of items in the notes box
- (CB_GETLBTEXTLEN, wParam indexItem, lParam 0) will get you the text length of the specified item
- (CB_GETLBTEXT, wParam indexItem, lParam buffer) will get you the actual item text, crossing application boundaries (love or hate windows for that)


whenever i find out something more i will update this thread. hopefully other interested coders will join the challenge to make it a real fun project. feel free to comment or ask questions. i will try my best to answer them.

I always assumed that the hand history file was updated as the hand was being played?
*edit* - Read somewhere that programs are using the chat box

no. the hand gets written to disk when the hand is finished. i would even assume that the text is sent from the server to the client so that nothing is in memory that could be read before it the hand is actually over. note that this is an assumption so far, i could be wrong.

this was possible up to some point when stars closed this hole and stopped using a standard editbox. they started drawing the text by hand using the ExTextOut() api. this got attacked as well by clever coders (using api hooking or so called detouring). so to my knowledge there is currently no reliable way to read the text in the chatbox programmatically.

when i am at it, some more notes on "PokerStarsNoteSelectorClass". i forgot to mention that the list of players is ordered A-Z. so there is no information to be taken regarding where a player is seated. for a small chance i threw a CB_GETITEMDATA message at the box to see if stars has any data associated with individual items via CB_SETITEMDATA. nope ..that would have been too easy.

On OS X:

The data comes mostly from the hand history files.

Additional data from PokerStars preferences allows one to determine a player's "preferred seat". Once this is know, the locations of the other players can be determined from the most recent hand history file.

Even more additional data comes from the window title.

For Zoom Poker, this is clearly insufficient. We use screen scraping to determine who is it at which table. It is not a perfect solution.

welcome copilot,

yes, OSX is a completely different beast when compared to windows. PT does not have a HUD for zoom there because it is impossible on the unix breed of OSes to get the required data by other means than screen scaping or OCR'ing. just out of curiosity (and if you feel like answering): how do you grab players off the table? i'm in contact with the guys from fpdb and they have plans to generate a hash from player name images and use these hashes as keys to their database. does this sound like a good idea to you?

and then another question: PT (and other) programms seem to have found ways to get the data by other means then scraping that work more reliable. i for one feel it is pretty hard to justify putting mac users to a disadvantage. do you have a comment on this?

to continue, here is the listing required to read out player names from noteboxes on all tables (in pseudo code):

Thanks for posting what you have mme. There are so few people who know this kind of stuff and few if any share their secrets

beat: was hoping SretiCentV was going to spill the beans how hem does it

I'm pretty sure the hand history text is indeed built up in Stars program memory as the hand progresses. I'd love to figure out how to read it, in a convenient open manner.

Many years ago I studied Juk's FPHG 1.0, and re-made it for Stars, not for any actual use but for an experiment - and the client does indeed produce HH files in memory for observed tables. My efforts were poor though and it just produced some of the hands, certainly not all. It also produced "half-hands" but I had no idea if the4y were "in progress" (I couldn't match them up with on screen events) or just more likely bad search techniques! I don't know what I'm doing examining a memory dump, so I didn't - just binary searching it for strings in ahk is the opposite of ideal I'm sure! But we know PT3 does a "memory grabber" for observed hands on normal tables, if you know what you're doing it's prob not too hard to extend that to find the current seated players in the memory. We can guess it's almost certainly "searching" due to updates causing PT4 beta to miss players now and again. We also know this can't work on OSX since it doesn't allow processes to examine the memory of other processes so readily as Windows.

very interesting topic!

Yeah for sure!

Finding the names of seated players without a HH seems even harder (ie: before any hand have been generated - which applies SNGs and "rush" type cash).

I've tried all sorts on Party; from opening up the notes windows (too slow/crap) to using the lobby list (too slow to update) to hooking TextOut() type calls (too hard to figure out which table they were sent to).

After reading mme's post though it gives me hope that there is some way of doing this on Party (the ability to have coloured notes on classic tables would be awesome!).

Juk

not if you knew what my contract looks like!

nice comments ty, back to the challenge.

being able to read player names i went through the client to see if there is any functionality in the client that relies on seats.

first candidate i found is "prefered seat". maybe changing prefered seat triggers some messages one could intercept? nope. i remember some point where seat order changed at runtime when adjusting this setting but this no longer works. seat order remains the same, the setting takes effect next time you start the client. well played stars. again, this would have been too easy.

so back to the tables. double clicking a seat selects a player in the notes box. the same can be triggered via seat context menu selecting "Note". deducing what player is seated on what seat should not be too hard. programmatically double click a seat (via the windows SendInput api), check what player name is selected in the notes box by sending CB_GETCURSEL to the box and query the box for the player name given the index it returns. if CB_GETCURSEL returns CB_ERR you found heros seat because heros name is not in the box. this works for zoom tables and zoom tables only (assuming there is never a zoom table with fewer than N-max players) because for zoom the notes box never contains player names from other tables (at least according to my checks). but this method has some serious downsides:

- you have to know where seats are located in the first place
- you actually have to move the mouse to the position you want to click (stars client has a check for this in place and ignores mouse cklicks when the mouse pointer is not at the click position)
- it may or may not work when windows overlapp and may only work for the current foreground window

i haven't checked in detail because this method is far from ideal for another reason: having to move the mouse around programmatically is enough to rule it out for any serious project. you usually end up accidently flipping windows around and cause all kinds of other unintended damage to your users. user presses mouse button on something, your programm starts moving the mouse around ..boom! here we go ..you may have to answer a call from a pissed off user. lesson learned: never move the mouse around programmatically unless you have a very good reason for doing so and the user is informed in detail about what you are doing.

Its ironic that all of that stuff is allowed but probably the best in that field are kids who love to piss Blizzard off.

Think i v told you everything with this.

it's ironic that this and more is possible. but even more ironic is that legitimate services are put to a disadvantage vs illegitimate services by stars in a systematic way. just thinking that ripping data off the client for data mining on windows is possible while HUDs on mac have to go the OCR path is enough to make me puke.

Mac issues have nothing to do with Stars, their operating system handles memory access differently iirc

actually this is a windows issue and a mac (unix) security feature.

the windows operating system allows for tricks to be played on the client that are not possible on mac. see my post for an example where i read out the contents of a combobox from another process by very simple means. this can not be done on the unix breed of oses for well known security reasons. funny enough this could be stopped by stars rather easily. but then they'd have to come to a decission on what data to expose for public use, say for legal trackers, along with securing the hell out of the client on data not intended for public use (many long and winding explanations here). as is right now, all data has to be obtained by hacking into the windows client which may open the door for many more ways to abuse it.

disclaimer: i am not a security expert, just an interested coder.

You shouldnt forget that because of windows security risks alot of reverse engineer professionals make a bread fixing low-level errors that wouldnt be fixable on Mac due to added security.

Nothing is really one-sided, but if i would have to pick a free path or a fixed path i d rather pick a free one where you can make or break things.

pretty sure HEM was using OCR for ftp's rush poker back in the day, whereas PT was using some better method.

maybe they are hooking the stars process to grab the data, ala http://www.codingthewheel.com/archiv...ne-poker-bot-7

i see what you did there. but keep in mind that this thread is about achieving the goal strictly within stars ToS. so failing to reach the goal and being able to proove it beyound doubt is actually win.

i have no idea what you are talking about

I'm curious about this... what does Stars TOS say is allowed and not allowed with regards to this? Is screen scraping/OCRing allowed assuming legitimate purposes? Reading PS process memory? Hooking?

I would think that once you're up and running, a nicely done OCR would be the most reliable. Anything else could be locked out by Stars, and then you're fighting all the time. Learn how to read the screen, and you're probably done the first time (depending on the method used - don't read specific pixels).

read initial post: screen scraping is disalowed in this challenge :-) one day it may be the only way left, until then your exact question was what i got interested in. so i contacted stars on the premise that i want to get the code required up and running for an open source project (that is, the code i write has to open source as well). here is their reply:

---------------------------------------------------
Hello ABC,

Thank you for contacting PokerStars. Your email was escalated to me as a member of the Game Security Team.

Whilst I can't provide you with much instruction on your development efforts, I can perhaps point you in the right direction.

The PokerStars client does not need to be reverse engineered in order to develop a working HUD for Zoom. Screen scraping, log file examination, OCR, and (to a very limited extent) windows message queue hooking (i.e. hooking the Windows message queue with PeekMessage, and watching messages flow by) would not be considered reverse engineering. Everything that a Zoom HUD does can be accomplished without trying to figure out the innards of the PokerStars client.

There is nothing different about a HUD for Zoom versus a HUD for standard tables. After you "fast fold" in Zoom, the IHH (Instant Hand History) window remains attached to the virtual table even after you've moved on to the next. If you fast fold four times, and then sit out, you can watch the IHH view insert the hands (in their correct order) as they complete. Some complete very fast -- when everyone fast folds to the big blind. Others might show up 2 or 3 minutes later, if there's significant action.

The hands are saved, as a "chunk", to the local hand history file as defined in the PokerStars client, and it certainly isn't against the Terms of Service to read the hand histories that PokerStars transmits to the client. That's how to get the data on players. How to identify players in seats is up to you, be it OCR, screen scraping, or windows message queue examinations; I would not define any of those things to be "reverse engineering" in this context (none involve examining the PokerStars executable or its functions).

Finally, please do not be concerned about the open source code that you write being used by others to violate our Terms of Service, such as by using it to develop a poker bot. We prefer to focus our enforcement efforts on prohibiting illicit activity such as developing/operating bot software, rather than a possible symptom. To that end, we have many proprietary tools which are industry leading, and they are under constant improvement.

I trust that this clarifies our position. If you have any other questions or concerns, please let us know. I wish you all the best.

Regards,

XYZ
PokerStars Game Security Team
---------------------------------------------------

..which left me confused for many a reasons: windows hooks? what about mac?

so i am supposed to mess around with a hopelessly outdated client on an operating system that is left over from the stone ages of computing using javelins and hand axes. what stops them from providing the info required in a reasonable way? why do i have to inject dlls and stuff, messing around with the users os, potentially break it just to get some harmless information to make a legal tool work? next i read in PokerTracker forums that their users may have to run their proggy in admin mode to make the zoom HUD work.. ... ... ..rly? so after i stopped laughing i started asking myself, what exactly is it that stars and Poker tracker doing over there?

It is against the PokerTracker EULA to attempt to reverse engineer any part of our software. (I realize that this is not what is happening in this thread YET but I wanted to make that abundantly clear).

Does anyone here believe that a company the size of ours (PokerTracker) is not in frequent communication with PokerStars? Is it that inconceivable that we have a special agreement with PokerStars, that would not be available to your average person or piece of software, that allows us to obtain this information in an accurate and reliable method while operating within the PokerStars TOS? Or maybe we have a special exemption in this case, due to our size and reputation as a company, to operate within a gray area or even outside of the TOS?

Best regards,

Derek

well, starts getting interesting.

feel free to answer: what kind of special agreement are you talking about?