[RedBean]

[ QUOTE ]
[ QUOTE ]
Just FYI, someone actually decompiled the AP client and told me that there was not a mechanism in the client for receiving hole cards. I don't know if he wants me to mention him by name, so I'll err on the safe side and not reveal it.

I am pretty sure that the hole cards were not received by the client. What the de-compilation told me lined up with what my sources told me.

[/ QUOTE ]

We don't really need to trust sources. There is just no way anybody making a poker client would ever send all the hole cards. While retards are apparently running the company, there is no way any software developer would ever do that.

I think it is likely there exists a "backdoor" or "superuser" account, and common sense would put it all server side. The authenticated user gets his/her own hole cards, however if certain "superuser" accounts are observing a table it is very possible the server sends them all the hole cards.


[/ QUOTE ]

The main goal in decompiling the client was to eliminate the possibility that the v8 client or later had malicious code that sent each player's hole cards to a third party source that could then be accessed independent of comprimising the server. This was not the case.

That leaves the following possibilities:

1. Custom client that can see hole cards, but is also verified by the AP server for use, despite not being the standard client.
2. Standard client may recieve all hole cards when a certain user account logs in that the server verifies to have sufficient privileges to send all hole cards.
3. Server is comprimised directly and hole cards are grepped real-time from logs or other means outside of client.

Either way, the security was comprimised internally by someone with access to the AP server and the ability to manipulate it in an ongoing fashion. This was obvious to many based on evidence, but it was necessary to do the legwork on the client to eliminate other possibilities.

Decompiling the client, in my opinion, eliminated the possibility of a "rogue software geek" inserting malicious code into an AP client update that sent hole card information to a third party.....as what looked to be one of the many versions of the story AP had appeared to try to throw against the wall initially....in effect to blame it on an isolated client version with malicious code, rather than admit a consistent and ongoing comprimise of their game servers located at MIT.

Another possibility, of course, albeit more remote... is the RivieraLtd.com server, which sits on the same subnet as the AP server, most likely in the same rack, but either way, behind the same switch....if it were to sniff packets in promiscious mode and then use the same decryption routines as the client, it could see every card going in and out of the game server for every table on AP. It would be quite an undertaking to employ this method when they just as easily seem to have had access to the AP server itself....but either way it's a little fishy when the guy sitting across the table from you has his profile information registered from a domain that sits inside the same protection boundary as the "secure" game server.

A true forensics audit on the Mohawk servers would answer all questions, but I highly doubt they would submit or agree to allowing this to happen, and I'm sure they'll give the appearance of one through their many close relationships with other "independent" companies.

But either way, knowing that Mr. Tom still has his own Riviera servers sitting alongside the AP game servers, and within the IP range assigned to AP by the Mohawks...that tells me that this guy is definately still involved on some level, and anyone who tells me otherwise is trying to blow smoke up my ass.