More like a desperate attempt to keep their players. lol @ the guy who was saying that all the threads and stickies on the Cake issue had no impact on their finances....

Also...Mason is the MAN!

What's happening in this thread is just amazing.

OP - you are ███ clueless. Anyone with physical access to the servers or credentials to them CAN read holecards, REGARDLESS if SSL is used for the communication or not, and this is true for any Poker site. This thread is pointless.

yeah, i cashed out recently. not going to reload any time soon.

+1

and get out whilst you can Lee. Your one of the good guys in my eyes.

Doug Lee move over, we have a contender.

Still hasn't been resolved by now... very interesting

nice wannabe corporate response from some company located in a potato cellar.

You are missing the point. Reading holecards is normally only possible if someone is able to change the source-code of the server. A programmer could change the source code to include malware that does this, but this malware would be visible to all other programmers and QA, and it leave a trace in the version management software pointing at who exactly put it there. There's normally pretty much no way to read holecards without alerting others and leaving a big red arrow pointing your way.

With no encryption, one of their techs could read everything without changing anything in the server software, even without changing anything on the physical server. They could do this without leaving a trace, without notifying anyone else.

Also, that's only part of the reason this thread is here: the others are Lee's complete stonewalling of any questions related to: the encryption issue, our trust in Cake's competence and when, how and why the fake encryption was used in the first place.

This is where you are missing the point, sir. You can read holecards simply by placing an executable on the server that reads the Poker software memory, without modifying the source code or taking down the server.

But you leave evidence by placing the executable, whereas just leaving a security hole open can be explained away as "Oops, my bad".

It's like the difference between stealing from a bank by just grabbing hundreds from the vault vs. "accidentally" putting hundreds in an ATM.

Why should ANY OF US ever feel safe playing online poker on ANY site?

Cake was pure crap, haven't played there in months except to use up my stupid gold chips and gold cards.

But these stories end up tainting "online poker" in a collective sense... IT IS FAR TOO EASY FOR SITES TO CHEAT AND SKIM MONIES. IMO, of course.

Thank God I have live casinos near me. Others are not so lucky obv.

Actually, no, you can't. Protected memory, which is a staple of every modern OS for the past decade or so, prevents that.

Even if you could "peek" into an other process's address space, data like this is so temporal that it'd be constantly overwritten in RAM.

THANK YOU

even if you did manage to read memory undetected you'd still need to send that info over the internet to your home in order for you to use it and own someone at the tables and those packets could be detected.

I'm not really sure what all the nitpicking about all the tech info has to do with any of this.

Fact: Customers are making claims about the whole "superuser" issue on Cake's network.

Fact: Lee Jones has yet to address any of these allegations directly to us, instead choosing to PM Mason.

Let's focus on the facts and the actual reason this thread was created and less on all the technical aspects of it. Arguing and trying to one up each other in this thread only lessons from the main focus of the thread itself. let's stay together on this and actually try to accomplish what we are after here. Eyes on the prize fellas (or ladies).

loooool that was funny

So stop asking about why OP's name is blacked out.

is this a level? You re wrong, please stop this pathetic hijacking. You would never get rights to run any sort of "executable" on the gameservers let alone dumping and decoding wholecards from ram in real time. Baring you bypass all the OS security it would still be appearant in logs. Meaning you need root or high level access to the servers, and it would still involve cooperative network management & security team.

No ssl means packets can be sniffed passively on the server side network, you then can process this data on your laptop or even forward it out through the internet and there is afaik no technical way to prove or even detect anything anormal is happening. Do you understand?

Please don't post if you don't know what you are saying. Every off the shelf debugger can attach to, read and write to another program memory.
.
No, it won't, certainly not in the middle of a hand.

Cake's lack of response is weird and inappropriate but if the community suspects there's something wrong with cake it should suspect any other site just as well.

MaybeYesMaybeNo - someone that works with the game company can certainly do anything that I just said, not just someone out of street. And no it won't appear in any logs. Get out of the holywood movie you're living in. Oh yes - I understand because I just happen to program a production poker web-site.

The above is the only post in this thread with correct information about the security risk.

2 things:

1. If this was an intentional lack of encryption by the programmers, how dumb were they to not immediately close down the site and add SSL once PTR started tracking their hands?

2. Was allowing people to change screen names and not allowing a HUD was an attempt to make it harder to catch the cheating? This seems unlikely since it would basically require management to be in on any possible cheating, but after AP who knows.

1) There was no reason to believe PTR would check for this, and even if there was, they might be unaware of PTR.
2) We are not saying that these policies were created to prevent people from finding superusers -- that's merely the result of these policies. (Part of) what we want to know is how we can be sure that there have not been any superusers, considering we cannot check this ourselves because of these policies.

It's somewhat related, but for me it's just a way of bumping an important thread while staying entertained.

As a software developer for 20 years or so, I'm pretty sure I'm aware of this. As an exercise in knowing WTF you're talking about, I'd love to see you attach to the server process to statefully inspect data with gdb without disturbing the program from running.

You're missing a whole host of points. Physical access to development doesn't mean physical access to deployment. The developers very likely don't even have accounts on the production servers. They'd not only need an account on the production server, they'd need an account with root access to run a debugger to even attempt the above.

Even if they had all of this, what you're suggesting is simply not going to happen. It'd be like trying to use a sledgehammer to screw in a lightbulb.

It is far, far easier to intercept inbound and outbound packets, filter them by IP address. You can do it from any any machine on the same subnet at the server, you don't need a privileged account, there are no "fingerprints" or interruptions in the server services. Heck, you could even have a box on the subnet forward packets elsewhere.

Do you even have the vaguest notion about how computer software actually works?