afaik you read the data out from some graphic/text rendering windows api. so programmers build a detour and filter the data when it's being rendered.

c'mon, we are talking technical stuff here. software automation.

there is nothing "broad" to it when a natural starting point would be to ban all the kiddies throwing EasyHook.dll at the client. there you got your human reaction speed.

I like stars because if they do stuff, they do it the right way. Having a look only at EasyHook.dll does solve nothing.

I like the part where mme told Derek to gtfo and he did

Was this ever solved?

I was randomly going through my Task Manager and Resource Monitor trying to find out why my CPU usage was so high when this caught my eye


I don't really know much about named pipes nor do I want to go poking around in case I get banned from stars or something but I thought this could be interesting. Or not idk..

at least something interesting to have a look at, thx

hi guys. still going this thread? it was so much fun, i remember laughing all the way through.

btw, a quick google showed no hit for "ZoomXMLPipe". let's see if we can change this :-)

i had a look on it, it's only there when pokerstars and hem is running.... so, my first guess would be, that it's just a communication between hem and a dll injected by hem..... but can be wrong ofc...

it's a "named pipe", a mechanism for inter process communication.

http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

if you happen to know some programming, you should be able to easily connect to it via ConnectNamedPipe() and read it via PeekNamedPipe().

other than that, if you digg around in the PokerStars process with "Process Explorer" you should be able to verify if HEM has injected something into the client or not.

hmm, basicly what i said....

I'd be pretty surprised if it's stars themselves who've added this... I think it's most likely just HEM injecting code and them communicating using it (IIRC, for FPHG I used "WM_COPYDATA" messages to communicate between an injected DLL and the FPHG process in a very similar way).

Juk

let's put it this way ..stars is accepting HEMs trunk quite willingly into the pooper. so, what difference would it make if it was the other way around?

Well unless they go public with any API they are revealing for HEM, it would seem to me that they were favouring one piece of 3rd party software over others?

Juk

ianal, but i would think things could get interesting either way if someone decided to file a case to a EU court.

Why wouldn't a private company be allowed to favor one 3rd party tool over others?

But ok, so getting real time data requires injecting something into the PS client. Do you even need anything special from PS to do that? I assume StarsHelper is injecting **** with it's $$ to bb conversion and I doubt he got any special treatment from PS before doing that. I assume he just went in, did what he did and asked whether it was OK afterwards (before going public obv). Now he's on the PS "accepted tools and services" list. They accepted his trunk into the pooper quite willingly too. And getting the player names etc. can't be much different from getting the stack sizes.

Funny thing is, i very much doubt he injects anything..... even if i did expect it at first also....

he said:

i'm pretty sure you must inject a dll before you can write into another process's memory

CreateRemoteThread() is a candidate - execute code in another process. may be used to execute a LoadLibrary() call to inject a dll, but can run any other code as well:
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

no, you don't have to do it... basicly you could locate some function within another process and overwrite it with your own code.... no injection needed.... even if i usually use code injection because it's easier.....

i never scratched more than the surface of the subject ..what could stars do to make this a really tough challenge?

I've never tried it, but there is a WriteProcessMemory function. Perhaps the OS is more stringent about WriteProcessMemory() than ReadProcessMemory() though and it won't work.

Juk

nope. you may read another processes memory and you may write it at will, as long as you have access to it. off cause you have to be more careful when writing it because you don't want to end up writing to arbitrary memory locations.

but back to the question: how could poker sites raise the hurdle if they really intended to do so?