"Listening in" on a server's communication with your computer
I am essentially wondering if this is possible.
Can I listen in on a server's (a poker server for that matter) communications with my computer while I am playing?
The reason I am asking this is as follows: when the server deals me my cards, can a program that I create read what those cards are, and consequently make a decision based on those cards?
If so, how would I go about acheiving this? Through winsock, wininet, what would work? And if you have any related links or helpful suggestions that'd be great!
-On a side note: Instead of pressing the 'Fold' button, would a program I create be able to send messages to the server telling it that my player has folded?
Thanks for all help!
Quote:Original post by Nietsnie
I am essentially wondering if this is possible.
Can I listen in on a server's (a poker server for that matter) communications with my computer while I am playing?
Yes but it would probably be against your end-user agreement.
Quote:The reason I am asking this is as follows: when the server deals me my cards, can a program that I create read what those cards are, and consequently make a decision based on those cards?
Yes (again, but it would probably be against your end-user agreement ).
Quote:If so, how would I go about acheiving this? Through winsock, wininet, what would work? And if you have any related links or helpful suggestions that'd be great!
It's not something trivial to do. You will need to take the time to decipher the packets sent by the server ... packets that are probably encrypted.
Book: "Network Programming for microsoft windows", 2nd edition
Program: "Ethereal" will let you eavesdrop and check packets coming to and from your computer.
Quote:
-On a side note: Instead of pressing the 'Fold' button, would a program I create be able to send messages to the server telling it that my player has folded?
I wouldn't recommend it. Mimicking user input on the program would be a better approch to the problem.
Gizz
I disagree. I see no reason for the server to send the client card data before it is needed; if the server just waited until he could see his cards to tell the client what they were it could easily prevent cheats like this.
Of course, the server programmers might not have thought of that, but you will have to find that out.
Of course, the server programmers might not have thought of that, but you will have to find that out.
Hold up. I am NOT trying to cheat or hack.
I will not be able to know cards that I would not know via the standard interface. To quote the server:
Looking at the first quoted section, I now see the packets are "heavily encrypted". Is it illegal or any such thing to decrypt these packets? If so, any suggestions? (I would prefer to program it myself.)
What do you mean exactly by mimicking user input? Do you mean, for example, send a command saying "mouse click at 450, 500" and then let my computer handle the rest?
Thank you for the suggestions on the books! I will definently look at those.
@ nagromo: They are smart :). They dont send packets before they are needed. But my purpose is to listen to the packets that I will receive anyways.
I will not be able to know cards that I would not know via the standard interface. To quote the server:
Quote:Our server sends out information only on a need-to-know basis, which means that there is no way to predict any coming cards or the other players' cards. The cards are not calculated until the very moment before they are sent out, so there is no way to know them in-advance (because they don't even "exist" in-advance). All sent information is also heavily encrypted.So I repeat: I have no intention of cheating. I simple would wish to have a program automatically make decisions instead of my having to be there.
I don't believe it is. It is purely online- no offline software or anything of that matter. I checked the user agreement and it says nothing about this. The important sectionGizz said:Yes but it would probably be against your end-user agreement.
Quote:Fraud, Money dumping and Collusion:I dont think it is against this agreement. I may be missing something.?
*********.com also has the right to hold any and all of a player's funds indefinitely if it is found that the player has been involved in fraudulent activity on *********.com. Fraudulent activity may include, but is not limited to, stolen credit cards, transfer of funds to other player accounts (chip dumping), forgery, and collusion.
Looking at the first quoted section, I now see the packets are "heavily encrypted". Is it illegal or any such thing to decrypt these packets? If so, any suggestions? (I would prefer to program it myself.)
What do you mean exactly by mimicking user input? Do you mean, for example, send a command saying "mouse click at 450, 500" and then let my computer handle the rest?
Thank you for the suggestions on the books! I will definently look at those.
@ nagromo: They are smart :). They dont send packets before they are needed. But my purpose is to listen to the packets that I will receive anyways.
There are at least two separate problems here:
1) Listening in on a communication stream.
This is easily done using a packet sniffer, a network interface in promiscious mode, or something similar. Google for "Ethereal" for a nice, GUI-based network sniffer that runs on Windows.
If the data is encrypted, it'll be slightly harder to deal with, but the key clearly needs to be in the client program, and thus it should be possible to decrypt.
2) Interjecting traffic into the communication stream.
If you do this when you're not the "true" end-point of the communication, it's Really Friggin' Hard (at least if the underlying protocol is TCP).
Instead, I would look into two options:
a) Post Windows messages to the running client program, to make it believe that the user clicked/typed whatever is necessary to play the appropriate cards.
b) Figure out the protocol of the server/client communication, and write a full replacement for the client. The server doesn't know anything about the client other than what it can see on the communications channel, so with sufficient reverse engineering (or plain documentation from the server side), this is quite possible.
I believe you're already aware that a good poker server wouldn't tell you what your cards are until you can actually see them in the client, so I believe that the reason you want to do this is to write a poker player strategy, and match it up in games against humans.
1) Listening in on a communication stream.
This is easily done using a packet sniffer, a network interface in promiscious mode, or something similar. Google for "Ethereal" for a nice, GUI-based network sniffer that runs on Windows.
If the data is encrypted, it'll be slightly harder to deal with, but the key clearly needs to be in the client program, and thus it should be possible to decrypt.
2) Interjecting traffic into the communication stream.
If you do this when you're not the "true" end-point of the communication, it's Really Friggin' Hard (at least if the underlying protocol is TCP).
Instead, I would look into two options:
a) Post Windows messages to the running client program, to make it believe that the user clicked/typed whatever is necessary to play the appropriate cards.
b) Figure out the protocol of the server/client communication, and write a full replacement for the client. The server doesn't know anything about the client other than what it can see on the communications channel, so with sufficient reverse engineering (or plain documentation from the server side), this is quite possible.
I believe you're already aware that a good poker server wouldn't tell you what your cards are until you can actually see them in the client, so I believe that the reason you want to do this is to write a poker player strategy, and match it up in games against humans.
Heh, I've heard about this recent wave of programs that play perfect games of online poker for money. Seems like a pretty nice scam.
Anyway, to intercept packets, the thing you want is called a "packet sniffer". Something like this
If the packets are indeed encrypted, then you'll probably have a pretty difficult time decrypting them. Easier than that, would be to find where in the program's memory they keep the card values. The decrypted card values will have to be sitting there somewhere.
Anyway, to intercept packets, the thing you want is called a "packet sniffer". Something like this
If the packets are indeed encrypted, then you'll probably have a pretty difficult time decrypting them. Easier than that, would be to find where in the program's memory they keep the card values. The decrypted card values will have to be sitting there somewhere.
Quote:1) Listening in on a communication stream.I would prefer to program this myself for the fun of it. Is there any open-source packet-sniffers that you know of? Or tutorials/books on this subject?
This is easily done using a packet sniffer, a network interface in promiscious mode, or something similar. Google for "Ethereal" for a nice, GUI-based network sniffer that runs on Windows.
Quote:a) Post Windows messages to the running client program, to make it believe that the user clicked/typed whatever is necessary to play the appropriate cards.A appears much simpler, but B seems it would work better in the long run. Must choose now...
b) Figure out the protocol of the server/client communication, and write a full replacement for the client. The server doesn't know anything about the client other than what it can see on the communications channel, so with sufficient reverse engineering (or plain documentation from the server side), this is quite possible.
Quote:I believe that the reason you want to do this is to write a poker player strategy, and match it up in games against humans.Thank you :D.
Quote:Anyway, to intercept packets, the thing you want is called a "packet sniffer". Something like thisThanks! That looks like I'll be able to read the source.
BTW, I am fluent in C++ and have read books on the TCP/IP system. But have done very little network programming.
Thanks for the help all!
Poker bots aren't generally allowed by the license agreement. The site you're playing at may or may not allow them, but don't be surprise when they seize your funds when you're discovered (and you most likely will be).
And incidentally, I sure wouldn't rely on a poker bot to make money. A bot can only rely on card drawing odds and pot odds, but those are only the foundation of a good poker game.
And incidentally, I sure wouldn't rely on a poker bot to make money. A bot can only rely on card drawing odds and pot odds, but those are only the foundation of a good poker game.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement