obviscating python code for distribution

harrismh777 harrismh777 at charter.net
Mon May 16 15:40:39 EDT 2011


Steven D'Aprano wrote:
> To put it in a
> nutshell, you can't trust*anything*. See the classic paper by Ken
> Thompson, "Reflections on Trusting Trust":
>

This is true, but there's another way to put it pro-active---


... expect the client to be untrustworthy.


In other words, write the server code with a protocol that 'expects' the 
client to be hacked. Yes, it takes three times the code and at least 
five times the work, but its worth it.

What do you do with syn floods?

What do you do with attempted overruns?

What if someone builds a client emulator, just to hammer your protocol 
and slow the server down, just for fun...?

You must build your server side 'assuming' that *all* of these things 
are going to happen (and more), and then be able to handle them when 
they do. That is what makes server-side coding so difficult.

In other words, you build the server in such a way that you can 
confidently hand Mr junior cracker your client source code and be 
confident that your gaming server is going to be a.o.k.

Many, many, coders don't want to go to all this trouble (and don't)... 
mainly because they're just glad if they can get simple sockets to work. 
So, they don't handle attempted overruns, or syn flood open attempts, or 
other.

One thing to remember (think about this) is whether your server/client 
is in a push or pull mode. *Never* allow the client to be in control 
(pushing) while your server is passively (pulling). The server must 
control everything so that the untrusted client will be *controlled* 
regardless  of client side hacks.

I realize that this probably means redesign of your server. Do it.

Happy gaming!

m harris







More information about the Python-list mailing list