Recent Features
| |||||||||||||
On the defense of piracy enablersOn the defense of piracy enablersPosted Aug 24, 2005 8:59 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246)In reply to: On the defense of piracy enablers by jvotaw Parent article: On the defense of piracy enablers
I can think of at least one way for it to work with the pass-through method. Since all the CD Keys are unique, require all copies to play on the Blizzard server network at least once.
When the CD key's registered, issue that client a public key and Blizzard keeps the private key. Whenever a client connects to a 3rd party server, pass the CD-Key through to Blizzard. After Blizzard checks that the key's unique and not being played by more than one machine, they then send back a date code signed by the private key. The 3rd party server needs to send this back to the client before the client agrees to trust the server.
All this assumes the client and the Blizzard servers are not modified and the only thing non-original is the 3rd party server. So, every so often the client makes a request for Blizzard server auth, and if it doesn't reply with an appropriately signed date code within an appropriate time frame, it disconnects. It's that simple. The 3rd party server only needs to pass through these requests to Blizzard. And Blizzard can choose whether to preemptively send signed date codes down to the 3rd party server to prevent disconnects due to network instability.
So, yeah, you could do #3 and do it in a way that can't be circumvented by "return TRUE;"
(Log in to post comments)
On the defense of piracy enablers Posted Aug 24, 2005 15:38 UTC (Wed) by zblaxell (subscriber, #26385) [Link] Did I miss something?
I thought the whole point of the server authentication was to prevent unauthorized clients. I assume that an authorized client implements its own CD key checks, and that to get it to work at all, you'd have to modify the client to bypass at least its own checks, before you could do anything else--this is typical of pirated closed-source software anyway.
With such a client, the server could return anything--TRUE, FALSE, NULL, or 3.141592653 signed by $DEITY's PGP key--and the client would just ignore it.
On the defense of piracy enablers Posted Aug 24, 2005 16:11 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link] Actually, what Blizzard was arguing was that the bnetd SERVER allowed two completely unaltered bog standard clients with the same CD-Key to connect. My scheme would prevent that.
Blizzard's concept of "authorized" in this context is merely "unique CD-key with respect to all other currently logged in clients."
Remote integrity checking of the client itself can be layered onto this. I was merely discussing the CD-Key uniqueness check.
On the defense of piracy enablers Posted Aug 26, 2005 5:40 UTC (Fri) by mebrown (subscriber, #7960) [Link] Duh... maybe I'm missing something, but isn't bnetd open source? What is to prevent Evil Pirate(TM) from just commenting out your checks?
On the defense of piracy enablers Posted Aug 26, 2005 13:32 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] Right, but neither the client nor Blizzard's servers are. In this protocol, the client refuses to talk to a server unless it verifies that it can get ahold of Blizzard's servers indirectly via that server. That is, bnetd can do whatever the hell it wants. But, if it can't get the specially signed auth token from Blizzard's servers for the client, the client simply refuses to talk to it.
Like I said, this would allow any 3rd party server to work, as long as it passes through authentication requests between Blizzard's servers and clients. The bnetd server would not be able to break this due to the fact everything going each direction is cryptographically signed and thus tamper proof.
On the defense of piracy enablers Posted Aug 26, 2005 18:12 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] Let me be a little more clear:
I'm saying it's possible to achieve Blizzard's aims IF they modify their protocol and the behavior of the client.
The client needs to insist on receiving a time-stamped "token"--the time stamp's there to prevent replay attacks--that it can determine easily came from an official Blizzard server. Digitial signatures such as RSA can achieve this.
The Blizzard servers enforce the "one copy of a given CD-Key online at a time" policy by being the only source of these tokens.
A 3rd party server (such as bnetd) can still exist, passing through auth requests to Blizzard's servers and passing back replies to the clients. The 3rd party server can't fake the auth token because it doesn't have Blizzard's private key.
Such a system works because the client insists on getting a time-stamped token signed by an official Blizzard server. Now if someone hacks the client, then you're back to being a pirate. But the bnetd authors certainly cannot be blamed for others hacking their clients.
Now, you may wonder what value bnetd would have if you still needed to contact the Blizzard servers. Easy: The Blizzard servers are only handling authentication. Once the client is satisfied that Blizzard blesses its existance, the local bnetd can run the whole game. That could offer latency benefits etc.
I don't know how I could make this approach more clear. Like I said, for it to work, it requires the client to insist on reaching a Blizzard server, and for the Blizzard server to produce auth tokens that no one else can fake.
Your are correct Posted Aug 27, 2005 3:03 UTC (Sat) by jvotaw (subscriber, #3678) [Link] I hadn't thought of this (and I have never heard of anyone who has), but I believe it would work.
You should patent it. ;)
-Joel
|
|||||||||||||