Can You Write a Sure-fire Algorithm to Stop Bots?

[BluffTHIS!]

grader,

Thanks for the reply again. If there is no way to stop scraping, then the only way to combat the bots seems to be to try to fool their inputs as mentioned in my first post, *if* there are relatively easy ways to do that. Even if it took a weekly mini-update on the part of the sites changing graphics, it would seem there is some way, but perhaps not.


dave,

No I never programmed GUI apps at all, let alone manually in C. I am older (40s) than most of you guys here. As a clue, my first programming was via punch cards in COBOL and Fortran. I got into PCs in the early 80s and programmed in Pascal, C, Basic and some assembler (hated that). I do read things on programming theory occasionally and have screwed around with java a little as well as of course HTML, but that's about it for the past 15 years.

[nuclear500]

[ QUOTE ]
grader,
Thanks for the reply again. If there is no way to stop scraping, then the only way to combat the bots seems to be to try to fool their inputs as mentioned in my first post, *if* there are relatively easy ways to do that. Even if it took a weekly mini-update on the part of the sites changing graphics, it would seem there is some way, but perhaps not.


[/ QUOTE ]

Without writing a Poker client to access the hardware directly, I do not believe you will be able to ever code the client to prevent another windows API program from interfacing with it.

[LeapFrog]

[ QUOTE ]
I got into PCs in the early 80s and programmed in Pascal, C, Basic and some assembler (hated that).


[/ QUOTE ]

Blasphemy man, how can you hate assembler? Push,pop, mov dx,ax! Good times, and who doesn't like hex [img]/images/graemlins/wink.gif[/img] Crazily enough the only program of any substance that I belted out perfectively the first time was a translation of a C program into assembler.

Anyways, onto the bot stuff. I really feel the key defense against bots is statistical analysis of play and analysis of input. It seems that most of the bots in play (at least the ones that have been found) are fairly crude and should be identifiable by either of these means.

In terms of input for example there would I assume, in most cases, be a significant difference between even a macro/script using player and a bot. I use macro express for example (mainly for folds, but on checks/calls as well) but, my mouse is still darting around a bit as I am going to another monitor, moving between windows, etc. I would hazard a guess that most of the bots out there are going to have a fairly easily identifiable 'fingerprint' in terms of how they handle input to the client.

The sites really do need to get on the case though as the best training ground for the bots of the future is the sites themselves (not getting into crazy neural net stuff). A stitch in time saves 9.

[jjshabado]

[ QUOTE ]
[ QUOTE ]
I got into PCs in the early 80s and programmed in Pascal, C, Basic and some assembler (hated that).


[/ QUOTE ]

Blasphemy man, how can you hate assembler? Push,pop, mov dx,ax! Good times, and who doesn't like hex [img]/images/graemlins/wink.gif[/img] Crazily enough the only program of any substance that I belted out perfectively the first time was a translation of a C program into assembler.

Anyways, onto the bot stuff. I really feel the key defense against bots is statistical analysis of play and analysis of input. It seems that most of the bots in play (at least the ones that have been found) are fairly crude and should be identifiable by either of these means.

In terms of input for example there would I assume, in most cases, be a significant difference between even a macro/script using player and a bot. I use macro express for example (mainly for folds, but on checks/calls as well) but, my mouse is still darting around a bit as I am going to another monitor, moving between windows, etc. I would hazard a guess that most of the bots out there are going to have a fairly easily identifiable 'fingerprint' in terms of how they handle input to the client.

The sites really do need to get on the case though as the best training ground for the bots of the future is the sites themselves (not getting into crazy neural net stuff). A stitch in time saves 9.

[/ QUOTE ]

I agree with you, but I think this is why online poker as we know it has a limited shelf life ( maybe a decade or two, I don't know). All of these problems can be overcome by the bot writers. The poker sites have to come up with a way to sort real live users from bots, using only a very very limited interface ( the poker client itself). The advantage is clearly on the side of bot writers and with time and improvement I don't see any algorithm that will be able to overcome that.

The only potential solutions are to expand the interface users have to communicate with the poker sites. For instance making real-time video of you playing mandatory. But even that I can see being overcome by bots in time.

[_dave_]

[ QUOTE ]

dave,

No I never programmed GUI apps at all, let alone manually in C. I am older (40s) than most of you guys here. As a clue, my first programming was via punch cards in COBOL and Fortran. I got into PCs in the early 80s and programmed in Pascal, C, Basic and some assembler (hated that). I do read things on programming theory occasionally and have screwed around with java a little as well as of course HTML, but that's about it for the past 15 years.

[/ QUOTE ]

Hi,

You don't have too many years on me [img]/images/graemlins/smile.gif[/img] My first programming was BBC Micro, ZX Spectrum, and ASM on Motorola 68030? chips [img]/images/graemlins/smile.gif[/img]

The reason I ask about Win32 GDI apps is to see if you were familiar with the way Windows abstracts hardware inputs and outputs from the apps running on it - obviously not, since no experience - so I will give a simplistic description.

it goes something like this:

Input devices -> Windows -> Applications -> Windows -> Output devices


Basically, each windows app implements a "message loop", which checks for input / events. Like a mouse click on an application is received by Windows - it notices the app under the mouse click - then passes the click message to the app in question for handling.

A "real" event, such as a mouse click, can place an event in to the applications message loop - but so can simple applications. In parts, this is how AHK works.

It is this behavior that makes it VERY hard for any app to know if an mouse click event was produced by a real person or an another app - one would have to hook the whole desktop and track all "mouse move" events just to make sure the click originated from the mouse location - and even then, another program can easily move the mouse around if a human isn't interfering.


I can think of a way sites could make hack/bot proof systems, but it wouldn't likely go down well.

Presumably you are familiar with MD5sum etc systems of ensuring the integrity of a file?

Sites could create bootable CDs, based on for example BartPE or a Linux variant.

Deny connections from any client whose (encrypted) root filesystem does not pass integrity checks, include zero capability in the liveCD for mounting other filesystems.

Might work, and would make a PC appear playstation-like, hell, a linux variant would run on a playstation / xbox (bring on the fish!!!) - but something I may not be thinking of may make such impossible - and it would render the AHK scripts i have become reliant upon useless - but such would create a very secure system, maybe?

dave.

[BluffTHIS!]

dave,

Thanks for that explanation. Yes your idea though good, would seem to impose do many difficulties on the user and the play of the client, that the sites wouldn't want to implement it.

From what I understand in reading threads on bots, the bot sites have to make updates for their bot users (who are basically just script kiddies). I presume this is in response to graphics changes in client updates that the sites do. But focusing on the process of the screen scraping, I alos presume the process is read the screen memory addresses and then compare the bot's hole cards and the board to a table of images to determine the card values.

Would it be correct to then presume again that they simply acquire that table of images from the client files that are installed on a user's computer in the client's directory? It would seem that would be the most likely avenue. Could not then the sites delay the bot writer's updates by encrypting those image files (perhaps they do already??) so as to make the writer have to capture all the images from the play on the screen and parse same for the table? And then for the site to have a weekly update for graphics file with changes? Obviously the question I am getting at is whether there is a way for the sites to update less often than daily but still significantly lengthen the time for the bot writer to adapt to changes and make him constantly have to maintain and update his program, instead of a more leisurely situation where he only has to do so once a month or even longer. Anything like that seem possible to you?

Since screen scraping is basically similar to OCR, I am also asking whether it can be made not only more difficult but less reliable as well and produce errors. Most OCR programs I have seen operate fairly well with modern typefaces, simply because the type libraries are readily available. But with historic documents like newspapers and docs from a myriad of old typewriter faces, they don't seem to do as well. Thus if the bot writer can be denied the easy route of access to those image files and has to implement some type of fuzzy logic to get his image table, it might induce a certain error rate.

A related idea to that would be for the poker client to randomly "smear" the card graphics with a fractal algorithm, but not where the product was unreadable to the player. Just one card from the combination of the hole cards and board, intead of all of them at once being screwed with at once like a captcha image.

Any promise in these ideas or I am still just dreaming?

[pokergrader]

It is dreaming. Current OCR and image processing is so powerful the level of "smearing" necessary for a computer to mess up would make it totally unreadable for the human players.

Just look at how complex current CAPTCHAs have to be in order to fool the bots.

And while messing around with the card images and making them harder to modify would certainly be a good step to prevent casual bot makers, slightly more complex software would easily handle it.

dave's idea up there seems pretty bullet-proof, but of course nobody would play on a system like that.

[LeapFrog]

[ QUOTE ]

dave's idea up there seems pretty bullet-proof...


[/ QUOTE ]

Dave's idea is pretty cool but along with any extreme measure (such as smearing, etc) I would think the sites would be against it if for no other reason then because they scream 'we have bot problems'. This is an issue I'm sure they would much rather have the players in the dark about.

The 'best' algorithms imo should be implemented server side.

[TreyOfLight]

Dave's idea doesn't work, because you can boot the CD from a virtual machine and run the bot on the supervisor OS. If the client takes pains to verify it's not virtualized, you can attach an IP-KVM to a physical machine and run the bot against the KVM viewer.

Random pop-up catchas don't work because it's worth it for a human to sit there and respond to them on 20 PC's.

Having every card be a captcha (or, more generally, making the whole play area an ever-changing visual puzzle) is probably the most effective and practical solution.

[jjshabado]

[ QUOTE ]

Having every card be a captcha (or, more generally, making the whole play area an ever-changing visual puzzle) is probably the most effective and practical solution.

[/ QUOTE ]

Yeah, but this is not a long term solution at all. Image processing will improve, computer hardware will improve, and soon computers will be just as good as humans at reading the images.