Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #5461 > unrolled thread

obviscating python code for distribution

Back to article view | Back to comp.lang.python

Contents

  obviscating python code for distribution "Littlefield, Tyler" <tyler@tysdomain.com> - 2011-05-15 20:04 -0600
    Re: obviscating python code for distribution Ben Finney <ben+python@benfinney.id.au> - 2011-05-16 13:29 +1000
      Re: obviscating python code for distribution "Littlefield, Tyler" <tyler@tysdomain.com> - 2011-05-15 21:36 -0600
        Re: obviscating python code for distribution harrismh777 <harrismh777@charter.net> - 2011-05-15 22:48 -0500
        Re: obviscating python code for distribution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-16 04:03 +0000
          Re: obviscating python code for distribution Chris Angelico <rosuav@gmail.com> - 2011-05-16 14:40 +1000
          Re: obviscating python code for distribution "Littlefield, Tyler" <tyler@tysdomain.com> - 2011-05-15 23:41 -0600
            Re: obviscating python code for distribution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-16 08:49 +0000
              Re: obviscating python code for distribution Chris Angelico <rosuav@gmail.com> - 2011-05-16 19:10 +1000
              Re: obviscating python code for distribution harrismh777 <harrismh777@charter.net> - 2011-05-16 14:40 -0500
            Re: obviscating python code for distribution Nobody <nobody@nowhere.com> - 2011-05-16 13:05 +0100
          Re: obviscating python code for distribution James Mills <prologic@shortcircuit.net.au> - 2011-05-16 16:00 +1000
          Re: obviscating python code for distribution Chris Angelico <rosuav@gmail.com> - 2011-05-16 16:12 +1000
          Re: obviscating python code for distribution "Littlefield, Tyler" <tyler@tysdomain.com> - 2011-05-16 00:17 -0600
          Re: obviscating python code for distribution "Littlefield, Tyler" <tyler@tysdomain.com> - 2011-05-16 00:20 -0600
            Re: obviscating python code for distribution Ben Finney <ben+python@benfinney.id.au> - 2011-05-17 10:22 +1000
          Re: obviscating python code for distribution James Mills <prologic@shortcircuit.net.au> - 2011-05-16 16:24 +1000
          Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-16 00:27 -0700
          Re: obviscating python code for distribution Jean-Michel Pichavant <jeanmichel@sequans.com> - 2011-05-16 11:36 +0200
          Re: obviscating python code for distribution "Littlefield, Tyler" <tyler@tysdomain.com> - 2011-05-16 08:44 -0600
            Re: obviscating python code for distribution Ben Finney <ben+python@benfinney.id.au> - 2011-05-17 10:30 +1000
            Re: obviscating python code for distribution alex23 <wuwei23@gmail.com> - 2011-05-16 20:45 -0700
          Re: obviscating python code for distribution Dotan Cohen <dotancohen@gmail.com> - 2011-05-17 09:16 +0300
          Re: obviscating python code for distribution Chris Angelico <rosuav@gmail.com> - 2011-05-17 16:39 +1000
          Re: obviscating python code for distribution "D'Arcy J.M. Cain" <darcy@druid.net> - 2011-05-17 09:36 -0400
        Re: obviscating python code for distribution Ben Finney <ben+python@benfinney.id.au> - 2011-05-16 14:10 +1000
          Re: obviscating python code for distribution Grant Edwards <invalid@invalid.invalid> - 2011-05-16 13:52 +0000
            Re: obviscating python code for distribution Ben Finney <ben+python@benfinney.id.au> - 2011-05-17 10:27 +1000
      Re: obviscating python code for distribution Disc Magnet <discmagnet@gmail.com> - 2011-05-20 14:49 +0530

Page 1 of 2  [1] 2  Next page →

#5461 — obviscating python code for distribution

Hello all:
I have been considering writing a couple of programs in Python, but I 
don't want to distribute the code along with them. So I'm curious of a 
couple things.
First, does there exist a cross-platform library for playing audio 
files, whose license I would not be violating if I do this?
Second, would I be violating the twisted, wxpython licenses by doing this?
Finally, is there a good way to accomplish this? I know that I can make 
.pyc files, but those can be disassembled very very easily with the 
disassembler and shipping these still means that the person needs the 
modules that are used. Is there another way to go about this?

-- 

Take care,
Ty
my website:
http://tds-solutions.net
my blog:
http://tds-solutions.net/blog
skype: st8amnd127
“Programmers are in a race with the Universe to create bigger and better idiot-proof programs, while the Universe is trying to create bigger and better
idiots.  So far the Universe is winning.”
“If Java had true garbage collection, most programs would delete themselves upon execution.”

[toc] | [next] | [standalone]

#5468

"Littlefield, Tyler" <tyler@tysdomain.com> writes:

> I have been considering writing a couple of programs in Python, but I
> don't want to distribute the code along with them.

This topic has been raised many times before, and there is a response
which is now common but may sound harsh:

What is it you think you would gain by obfuscating the code, and why is
that worthwhile? What evidence do you have that code obfuscation would
achieve that?

> Finally, is there a good way to accomplish this? I know that I can
> make .pyc files, but those can be disassembled very very easily with
> the disassembler and shipping these still means that the person needs
> the modules that are used. Is there another way to go about this?

Not really, no. You would be best served by critically examining the
requirement to obfuscate the code at all.

-- 
 \                 “Leave nothing to chance. Overlook nothing. Combine |
  `\          contradictory observations. Allow yourself enough time.” |
_o__)                                                     —Hippocrates |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#5469

I'm putting lots of work into this. I would rather not have some script 
kiddy dig through it, yank out chunks and do whatever he wants. I just 
want to distribute the program as-is, not distribute it and leave it 
open to being hacked.
On 5/15/2011 9:29 PM, Ben Finney wrote:
> "Littlefield, Tyler"<tyler@tysdomain.com>  writes:
>
>> I have been considering writing a couple of programs in Python, but I
>> don't want to distribute the code along with them.
> This topic has been raised many times before, and there is a response
> which is now common but may sound harsh:
>
> What is it you think you would gain by obfuscating the code, and why is
> that worthwhile? What evidence do you have that code obfuscation would
> achieve that?
>
>> Finally, is there a good way to accomplish this? I know that I can
>> make .pyc files, but those can be disassembled very very easily with
>> the disassembler and shipping these still means that the person needs
>> the modules that are used. Is there another way to go about this?
> Not really, no. You would be best served by critically examining the
> requirement to obfuscate the code at all.
>


-- 

Take care,
Ty
my website:
http://tds-solutions.net
my blog:
http://tds-solutions.net/blog
skype: st8amnd127
“Programmers are in a race with the Universe to create bigger and better idiot-proof programs, while the Universe is trying to create bigger and better
idiots.  So far the Universe is winning.”
“If Java had true garbage collection, most programs would delete themselves upon execution.”

[toc] | [prev] | [next] | [standalone]

#5470

Littlefield, Tyler wrote:
> I'm putting lots of work into this. I would rather not have some script
> kiddy dig through it, yank out chunks and do whatever he wants. I just
> want to distribute the program as-is, not distribute it and leave it
> open to being hacked.

Protection via obfuscation is invalid practically as well as 
philosophically. Those of us who work in the free software movement (or 
the open software movement too) specifically believe that obfuscation is 
an incorrect approach.

Obfuscation is the paramount Microsoft strategy for protection and for 
security. It doesn't work. In fact, making the code open permits what 
many of us who consider open source to be 'good science' more secure by 
allowing peer review and community improvement.

Some of us believe that code is not useful unless its open. If I can't 
see what you're doing, comment on it, improve it if I like, and share it 
with others I don't need it (its really that simple).

Nobody can make this decision for you, of course, but please consider 
making your coding free software (GPL license), or at least open and GPL 
compatible licensed.

kind regards,
m harris

[toc] | [prev] | [next] | [standalone]

#5474

On Sun, 15 May 2011 21:36:53 -0600, Littlefield, Tyler wrote:

> I'm putting lots of work into this. I would rather not have some script
> kiddy dig through it, yank out chunks and do whatever he wants. 


The best way to do that is to labour in obscurity, where nobody either 
knows or cares about your application. There are hundreds of thousands, 
possibly millions, of such applications, with a user base of one: the 
creator.

One other alternative is to ask yourself, what's the marginal value of 
yanking out chunks from my code? What harm does it do me if Joe Haxor 
spends hours pulling out one subroutine, or a dozen, from my app, and 
using them in his app? Why should I care?

It never ceases to amaze me how often people write some trivial 
application, like a thousand others, or even some trivial function or 
class, and then treat it like the copyright to Mickey Mouse. I don't know 
what your application is, or how it works. It's conceivable that it's the 
next Microsoft Office. But my advice to you is to take a pragmatic, 
realistic view of the cost of copyright infringement.

If it's going to cost you $1000 in extra effort to prevent $100 of harm, 
it's simply not worth it.



> I just
> want to distribute the program as-is, not distribute it and leave it
> open to being hacked.

Right... because of course we all know how Windows being distributed 
without source code makes it soooooo secure.

You are conflating two different issues:

* Can people "steal" or copy my ideas and code?

* Can people hack my code (in the bad sense)?


I hope this does not offend, because I mean it in the nicest possible 
way, but if you think that not distributing source code will prevent your 
code from being broken, then you are delusional.

Look at Facebook and its periodic security holes and accounts being 
hacked. Not only don't Facebook distribute source code, but they don't 
distribute *anything* -- their application is on their servers, behind a 
firewall. Does it stop hackers? Not a chance.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#5480

On Mon, May 16, 2011 at 2:03 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> The best way to do that is to labour in obscurity, where nobody either
> knows or cares about your application. There are hundreds of thousands,
> possibly millions, of such applications, with a user base of one: the
> creator.

And I'm sure Steven will agree with me that this is not in any way a
bad thing. I've written hundreds of such programs myself (possibly
thousands), and they have all served their purposes. On a slightly
larger scale, there are even more programs that have never left the
walls of my house, having been written for my own family - not because
I'm afraid someone else will steal them, but because they simply are
of no value to anyone else. But hey, if anyone wants a copy of my code
that's basically glue between [obscure application #1] and [obscure
application #2] that does [obscure translation] as well to save a
human from having to do it afterwards, sure! You're welcome to it! :)

However, I do not GPL my code; I prefer some of the other licenses
(such as CC-BY-SA), unless I'm working on a huge project that's not
meant to have separate authors. For something that by and large is one
person's work, I think it's appropriate to give attribution. But
discussion of exactly _which_ open source license to use is a can of
worms that's unlikely to be worth opening at this stage.

Chris Angelico

[toc] | [prev] | [next] | [standalone]

#5486

Hello:
Thanks all for your information and ideas. I like the idea of open 
source; I have a fairly large (or large, by my standards anyway) project 
that I am working on that is open source.

Here's kind of what I want to prevent. I want to write a multi-player 
online game; everyone will essentually end up connecting to my server to 
play the game. I don't really like the idea of security through 
obscurity, but I wanted to prevent a couple of problems.
1) First I want to prevent people from hacking at the code, then using 
my server as a test for their new setups. I do not want someone to gain 
some extra advantage just by editing the code.
Is there some other solution to this, short of closed-source?
Thanks,

[toc] | [prev] | [next] | [standalone]

#5503

On Sun, 15 May 2011 23:41:23 -0600, Littlefield, Tyler wrote:

> Here's kind of what I want to prevent. I want to write a multi-player
> online game; everyone will essentually end up connecting to my server to
> play the game. I don't really like the idea of security through
> obscurity, but I wanted to prevent a couple of problems. 1) First I want
> to prevent people from hacking at the code, then using my server as a
> test for their new setups. I do not want someone to gain some extra
> advantage just by editing the code. Is there some other solution to
> this, short of closed-source? Thanks,

Closed source is not a solution. Please wipe that out of your mind. 
People successfully hack closed source applications. The lack of source 
is hardly a barrier at all: it's like painting over the door to your 
house in camouflage colours so from a distance people won't see it. To a 
guy with a network sniffer and debugger, the lack of source is no barrier 
at all.

You're trying to solve a hard problem, and by hard, I mean "impossible". 
It simply isn't possible to trust software on a machine you don't 
control, and pretty damn hard on a machine you do control. To put it in a 
nutshell, you can't trust *anything*. See the classic paper by Ken 
Thompson, "Reflections on Trusting Trust":

http://cm.bell-labs.com/who/ken/trust.html

Now, in a more practical sense, you might not fear that the operating 
system will turn on you, or the Python compiler. Some threats you don't 
care about. The threat model you do care about is a much more straight-
forward one: how to trust the desktop client of your game?

Alas, the answer is, you can't. You can't trust anything that comes from 
the client until you've verified it is unmodified, and you can't verify 
it is unmodified until you can trust the information it sends you. A 
vicious circle. You're fighting physics here. Don't think that obscuring 
the source code will help.

On-line game servers are engaged in a never-ending arms race against 
"punks" who hack the clients. The servers find a way to detect one hack 
and block it, and the punks find another hack that goes unnoticed for a 
while. It's like anti-virus and virus, or immune systems and germs.

The question you should be asking is not "how do I make this secure 
against cheats?", but "how much cheating can I afford to ignore?".

If your answer is "No cheating is acceptable", then you have to do all 
the computation on the server, nothing on the client, and to hell with 
performance. All your client does is the user interface part.

If the answer is, "Its a MUD, who's going to cheat???" then you don't 
have to do anything. Trust your users. If the benefit from "cheating" is 
small enough, and the number of cheaters low, who cares? You're not 
running an on-line casino for real money.

See also here:

http://web.archiveorange.com/archive/v/bqumydkHsi2ytdsX7ewa


Another approach might be to use psychology on your users. Run one server 
for vanilla clients to connect to, and another server where anything 
goes. Let the punks get it out of their system by competing with other 
punks. Run competitions to see who can beat the most souped up, dirty, 
cheating turbo-powered clients, for honour and glory. Name and shame the 
punks who cheat on the vanilla server, praise the best cheaters on the 
anything-goes machine, and  you'll (hopefully!) find that the level of 
cheating on the vanilla server is quite low. Who wants to be the low-life 
loser who wins by cheating when you can challenge your hacker peers 
instead?

(Note: I don't know if this approach ever works, but I know it does *not* 
work when real money or glory is involved. Not even close.)

If Blizzard can't stop private servers, rogue clients and hacked 
accounts, what makes you think you can?




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#5504

On Mon, May 16, 2011 at 6:49 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> If your answer is "No cheating is acceptable", then you have to do all
> the computation on the server, nothing on the client, and to hell with
> performance. All your client does is the user interface part.
>
> If the answer is, "Its a MUD, who's going to cheat???" then you don't
> have to do anything. Trust your users. If the benefit from "cheating" is
> small enough, and the number of cheaters low, who cares? You're not
> running an on-line casino for real money.

The nearest I've seen to the latter is Dungeons and Dragons. People
can cheat in a variety of ways, but since they're not playing
*against* each other, cheating is rare. As to the former, though...
the amount of computation that you can reliably offload to even a
trusted client is low, so you don't lose much by doing it all on the
server. The most computationally-intensive client-side work would be
display graphics and such, and that's offloadable if and ONLY if
there's no game-sensitive information hidden behind things. Otherwise
someone could snoop the traffic-stream and find out what's behind that
big nasty obstacle, or turn the obstacle transparent, or whatever...
not safe.

There's an old OS/2 game called Stellar Frontier that moves sprites
around on the screen using clientside code, but if there's a bit of
lag talking to the server, you see a ship suddenly yoinked to its new
position when the client gets the latest location data. That's a fair
compromise, I think; the client predicts where the ship "ought to be",
and the server corrects it when it can.

Chris Angelico

[toc] | [prev] | [next] | [standalone]

#5532

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

[toc] | [prev] | [next] | [standalone]

#5514

On Sun, 15 May 2011 23:41:23 -0600, Littlefield, Tyler wrote:

> Here's kind of what I want to prevent. I want to write a multi-player 
> online game; everyone will essentually end up connecting to my server to 
> play the game. I don't really like the idea of security through 
> obscurity, but I wanted to prevent a couple of problems.
> 1) First I want to prevent people from hacking at the code, then using 
> my server as a test for their new setups. I do not want someone to gain 
> some extra advantage just by editing the code.
> Is there some other solution to this, short of closed-source?

Closed source will not help in the slightest.

What will help is to remember the fundamental rule of client-server
security: Don't Trust The Client. If you don't remember this rule, you
have no security whatsoever, whether the source is open or closed.

Obfuscating the source won't prevent someone from running it under a
modified Python interpreter, or running an unmodified Python interpreter
under a debugger, or with modified DLLs (or even device drivers).

To give just one example, Blizzard has a whole team of people working on
anti-cheating measures, most of which involve installing various pieces of
privacy-invading, security-endangering malware on their customers'
systems. And it still doesn't work.

[toc] | [prev] | [next] | [standalone]

#5488

On Mon, May 16, 2011 at 3:41 PM, Littlefield, Tyler <tyler@tysdomain.com> wrote:
> Here's kind of what I want to prevent. I want to write a multi-player online
> game; everyone will essentually end up connecting to my server to play the
> game. I don't really like the idea of security through obscurity, but I
> wanted to prevent a couple of problems.
> 1) First I want to prevent people from hacking at the code, then using my
> server as a test for their new setups. I do not want someone to gain some
> extra advantage just by editing the code.
> Is there some other solution to this, short of closed-source?

As I mentioned before (which I don't think you quite got)...

Write your "game" for the "web".
Write is as a SaaS (Software as a Service) - even if it's free and open source.

cheers
James

-- 
-- James Mills
--
-- "Problems are solved by method"

[toc] | [prev] | [next] | [standalone]

#5489

On Mon, May 16, 2011 at 3:41 PM, Littlefield, Tyler <tyler@tysdomain.com> wrote:
> Here's kind of what I want to prevent. I want to write a multi-player online
> game; everyone will essentually end up connecting to my server to play the
> game. I don't really like the idea of security through obscurity, but I
> wanted to prevent a couple of problems.
> 1) First I want to prevent people from hacking at the code, then using my
> server as a test for their new setups. I do not want someone to gain some
> extra advantage just by editing the code.
> Is there some other solution to this, short of closed-source?

1) If you're worried about people getting hold of the code that's
running on your server, that's a server security issue and not a
Python obscurity issue (if they get the code, they can run it no
matter how obscured it is).

2) Was there a problem 2? :)

As James Mills said, just leave it on the server and then you don't
have to give out the source (and by "don't have to", I mean ethically,
legally, and technically).

You may want to give some thought to scaleability of your code; Google
told their staff to avoid Python for things that are going to get
hammered a lot (although it's possible that Google's idea of "a lot"
is five orders of magnitude more than you'll ever get!!). But if your
game world puts a hard limit on its own load (eg if players are on a
50x50 board and you know you can handle 2500 simultaneous players),
you won't have a problem.

Also, Python doesn't really cater to servers that want to have their
code updated on the fly; I'm sure you could work something out using a
dictionary of function objects, but otherwise you're stuck with
bringing the server down to do updates. That's considered normal in
today's world, but I really don't know why... downtime is SO last
century!

Chris Angelico
happily running servers on fully open source stacks

[toc] | [prev] | [next] | [standalone]

#5490

 >Write your "game" for the "web".
 >Write is as a SaaS (Software as a Service) - even if it's free and 
open source.
I understood you loud and clear. And that makes a lot of assumptions on 
my game and the design. I don't really care to host this over the web. I 
want a
centralized server that would perform the logic, where I can offload the 
playing of sounds (through a soundpack that's already installed) to the 
client-side.
Not only that, but a lot of web technologies that would be used for this 
wouldn't really work, as I am doing this for the blind; Flash as well as 
a lot
of the popular setups are not very accessible.

[toc] | [prev] | [next] | [standalone]

#5491

Hello:
I wanted to make the client in python, and the server possibly, though 
I'm not really sure on that. I was not worried about the code for the 
server being stolen, as much as I was worried about people tinkering 
with the client code for added advantages. Most of the logic can be 
handled by the server to prevent a lot of this, but there are still ways 
people could give themselves advantages by altering the client.

[toc] | [prev] | [next] | [standalone]

#5539

"Littlefield, Tyler" <tyler@tysdomain.com> writes:

> I wanted to make the client in python, and the server possibly, though
> I'm not really sure on that. I was not worried about the code for the
> server being stolen, as much as I was worried about people tinkering
> with the client code for added advantages.

Thank you for making your constraints explicit; that's more than most
people do when asked.

As Steven said, you're trying to solve a problem which is very
difficult, and obfuscating the code won't be of much help. If people
have the program running on their own computers, they can hack it. You
can't stop that, so you have to consider other ways of making it
ineffective.

-- 
 \      “The fact that a believer is happier than a skeptic is no more |
  `\   to the point than the fact that a drunken man is happier than a |
_o__)                                 sober one.” —George Bernard Shaw |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#5492

On Mon, May 16, 2011 at 4:16 PM, Littlefield, Tyler <tyler@tysdomain.com> wrote:
> I understood you loud and clear. And that makes a lot of assumptions on my
> game and the design. I don't really care to host this over the web. I want a
> centralized server that would perform the logic, where I can offload the
> playing of sounds (through a soundpack that's already installed) to the
> client-side. Not only that, but a lot of web technologies that would be used
> for this wouldn't really work, as I am doing this for the blind; Flash as
> well as a lot of the popular setups are not very accessible.

Funny you should mention this "now" :)
I happen to be blind myself.

Yes I agree Flash is not very accessible (never has been).

Web Standards web apps and such however are quite
accessible!

cheers
James

-- 
-- James Mills
--
-- "Problems are solved by method"

[toc] | [prev] | [next] | [standalone]

#5495

On Sun, May 15, 2011 at 10:41 PM, Littlefield, Tyler
<tyler@tysdomain.com> wrote:
> Hello:
> Thanks all for your information and ideas. I like the idea of open source; I
> have a fairly large (or large, by my standards anyway) project that I am
> working on that is open source.
>
> Here's kind of what I want to prevent. I want to write a multi-player online
> game; everyone will essentually end up connecting to my server to play the
> game. I don't really like the idea of security through obscurity, but I
> wanted to prevent a couple of problems.
> 1) First I want to prevent people from hacking at the code, then using my
> server as a test for their new setups. I do not want someone to gain some
> extra advantage just by editing the code.
> Is there some other solution to this, short of closed-source?
> Thanks,

I don't know that closing the source does you much more good than
obfuscating it. The obvious attack surface here is pretty much totally
exposed via network traffic, which any legitimate client can gain
access to. A better approach would be to simply write more secure code
in the first place.

Geremy Condra

[toc] | [prev] | [next] | [standalone]

#5506

Littlefield, Tyler wrote:
> Hello:
> Thanks all for your information and ideas. I like the idea of open 
> source; I have a fairly large (or large, by my standards anyway) 
> project that I am working on that is open source.
>
> Here's kind of what I want to prevent. I want to write a multi-player 
> online game; everyone will essentually end up connecting to my server 
> to play the game. I don't really like the idea of security through 
> obscurity, but I wanted to prevent a couple of problems.
> 1) First I want to prevent people from hacking at the code, then using 
> my server as a test for their new setups. I do not want someone to 
> gain some extra advantage just by editing the code.
> Is there some other solution to this, short of closed-source?
> Thanks,
>
If your App meet some success, you'll need some help. You'll be able to 
get some only if the community grows and has access to your code. If you 
want to battle versus hackers, you have already lost (if your app hos no 
success, there will be no hacker anyway :o) )
Otherwise I guess that most online games execute all decisions and state 
machine transitions at server side, which is the only code you can 
trust. The client only forwards user inputs to the server, and display 
the resulting effect .

JM

[toc] | [prev] | [next] | [standalone]

#5521

 >Funny you should mention this "now"
I don't go around parading the info, until I have to.
 >Yes I agree Flash is not very accessible (never has been).
 >Web Standards web apps and such however are quite
 >accessible!
If I was making a browser-based game, yes. As I'm not though...

Anyway, thanks to everyone else who answered this thread. I've not done 
much like this besides muds, and all the logic is on the server there, I 
think I will build the client in python, open source it for people to 
fix/add to if they want and make sure to keep the server as secure as it 
can be.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web