Top Mud Sites Forum - View Single Post

shadowfyr · 08-25-2006, 06:48 PM

One presumes that the clients needs to recieve the code, that it doesn't change over time (one that does could go out of sync real easy, but its not impossible) and that your making the laughable assumption that the client couldn't do what I already said, check every incoming packet for the data, then send back the predetermined code? Seriously, the only way I could see that working is if you used:

1. Server side seed code.
2. Server side scrambler.
3. Client side scramber.

Basically, the same you see in the bond movie involving GPS. A constantly changing, synced code, where both the code returned, and the code expected, change in a known way, each time you make a request for it. And that just makes it inconvenient, not impossible. As the_logos points out, this is basically like using an a DRM or encrption code, which would make it illegal under the DMCA for one person to solve it "then" provide others with that solution. But, is a mud "capable" of defending its DRM rights? Is it even worth it. If not, then your right back to, "All that needs to happen, is for one person the break the code." And all that takes is a proxy, which logs a sufficient number of responses for someone to derive the scrambler you use. I.e., anything from extremely trivial, to so complicated that the code to track both ends might result in the game lagging, on both ends, every time a request for the code is made.

Worse, I doubt you will have encyrption experts on this, so the solution might even "look" complex, but be breakable with far less code and way less effort. So no, any client able to catch the packets, parse them for requests, and send back the proper response *won't* be detected, no matter how random the requests. That was my point. And even if you changed it frequently, without warning, "the client" still needs to get the new code, so it knows what to respond with. If they captured the code when it started the first time anyway, that won't matter. In fact, even if you changed it so randomly that two days had the same code for the last 10 minutes of the prior play and the first five the next day, variables in Mushclient plugins are "persistent" across executions. Worse, all they would need to do is wait a significant span of time, like only playing every friday, to make sure that they got a new code every time they connected.

"Sniffing up" the code is so rediculously silly, in any context that you can guarrentee the players can get it at all, so as to render it either a) too rediculous and inconvenient for them to bother (like an email of the code for the day) or using some sort of automated sequence at start up, which is just as trivial to manage as send the code after you have it.

I really don't think you understand what some modern clients are capable of, using just their standard functions, never mind added libraries.

08-25-2006, 06:48 PM	#10
shadowfyr Senior Member Join Date: Oct 2002 Posts: 310	One presumes that the clients needs to recieve the code, that it doesn't change over time (one that does could go out of sync real easy, but its not impossible) and that your making the laughable assumption that the client couldn't do what I already said, check every incoming packet for the data, then send back the predetermined code? Seriously, the only way I could see that working is if you used: 1. Server side seed code. 2. Server side scrambler. 3. Client side scramber. Basically, the same you see in the bond movie involving GPS. A constantly changing, synced code, where both the code returned, and the code expected, change in a known way, each time you make a request for it. And that just makes it inconvenient, not impossible. As the_logos points out, this is basically like using an a DRM or encrption code, which would make it illegal under the DMCA for one person to solve it "then" provide others with that solution. But, is a mud "capable" of defending its DRM rights? Is it even worth it. If not, then your right back to, "All that needs to happen, is for one person the break the code." And all that takes is a proxy, which logs a sufficient number of responses for someone to derive the scrambler you use. I.e., anything from extremely trivial, to so complicated that the code to track both ends might result in the game lagging, on both ends, every time a request for the code is made. Worse, I doubt you will have encyrption experts on this, so the solution might even "look" complex, but be breakable with far less code and way less effort. So no, any client able to catch the packets, parse them for requests, and send back the proper response won't be detected, no matter how random the requests. That was my point. And even if you changed it frequently, without warning, "the client" still needs to get the new code, so it knows what to respond with. If they captured the code when it started the first time anyway, that won't matter. In fact, even if you changed it so randomly that two days had the same code for the last 10 minutes of the prior play and the first five the next day, variables in Mushclient plugins are "persistent" across executions. Worse, all they would need to do is wait a significant span of time, like only playing every friday, to make sure that they got a new code every time they connected. "Sniffing up" the code is so rediculously silly, in any context that you can guarrentee the players can get it at all, so as to render it either a) too rediculous and inconvenient for them to bother (like an email of the code for the day) or using some sort of automated sequence at start up, which is just as trivial to manage as send the code after you have it. I really don't think you understand what some modern clients are capable of, using just their standard functions, never mind added libraries.