Open Source application GPL legality
shd at rootnode.net
Thu Oct 15 00:13:50 UTC 2009
On 2009-10-14 17:42, Björn Terelius wrote:
> Your idea about dynamically merging the GPL'd client (whether this is
> allowed or not) with some non-free utility may not work as you indent
> it to. After all, I don't see how you could prevent a malicious user
> from creating a program which emulates a non-modified client when
> interacting with the security utility, but which acts as the cheating
> client when interacting with the user.
On 2009-10-14 21:31, John Cowan wrote:
> At this point, everyone still concerned with this problem, and
> *especially* shd, should go and read Eric Raymond's "The Case of the
> Quake Cheats" at http://catb.org/esr/writings/quake-cheats.html .
> It's all there: the problem, the various solutions, the refutations of
> those solutions, etc. No real need to rehash it here.
Thanks for interesting article. I acknowledge that security by obscurity
has never been real solution but in this region of game worse I can face
is... possibility that someone smart can make cheats programs. My
original assumption about making use of my previous reverse engineering,
and packing skills was just to make really hard to break inside into
application. I'm not sure if you are into this area but there are real
world examples of applications which turned into something like
unbreakable 'legends'. I'm not aspiring so high, but mentioning about
this to show you there is a possibility to staying unbreakable for
reasonable time. My basic assumption was to constantly updating this
packing algorithm after seeing any marks of being broken (I'll refer to
If You are interested in my solution I'll try to describe it.
Personally, I'm interested a little bit in computer security which is
still my main occupation (besides of studying). Here is the general concept:
* I'm making decision to release current (in a stable means :) version
as obligatory. In this step I'm building application (not publicly known
* Then closed tests in which we're additionally building code flow database.
* After backing up original client binary obfuscator is applied. It
should split file into small chunks (smaller better but bigger
performance cost). This splitting process making use of database
generated before to appropriate choose sections and inject decoding code
parts (there are many independent encoding 'procedures'). Chunks didn't
used by some period of time would be encoded back. I'd like to add
encoded code relocation making use of data communicated with server (so
server would know client chunk mapping).
* So, average player is downloading client - nothing interesting. After
installation it looks weird. Well, yes - this game is acting like a
virus! Not a good news for non-educated anti-virus users.
* Finally, he is making a log on attempt, but hey - what about
decryption? Same small procedures chain as everywhere else, but crucial
thing is to load lowest amount of code before connection. We're making
RSA handshake, then checking credentials and continue communicating in
secure channel. First client verification occurs AFTER successful log-in
and repeats after any period of time (I think it's rate should be lower
with new players).
<- gimme security code of section xxx (or part of it - I don't know yet)
- you can use this seed
-> uhm... i have this section encoded... i don't even know
procedure(pessimistic)! But wait, I got clear instructions to decode
this this and this to reach mentioned section. oh - there it is, i'll
hash it with your seed so we can make sure noone has taken control over
<- <comparing with hash from non-encrypted client binary> this time you
made it... (i'll ask him in rand()*modifier secs)
So we reached to strength which most hiding stuff can't, or just don't
use. Described application has no worth without connection with managing
server, so we're not forced to make any decodes in not safe environment.
Every suspicious action might be reported over secure channel and result
with account ban - so it's harder to experiment. Disassembler is hard
because of encrypting... Debugging breaks not allowed... Many memory
snapshots and tough work with custom tools. Only experienced reverse
engineer can do that but hey, do they really spend so much time on
cracking? Just if they like... family... kids... job - but even if
(surely there are) I believe it's long time. Just look at skype!
Obscurity helps if there are not better methods (or you don't know them
but in practice it equals).
There is a possibility I'll acknowledge that my system of protecting
client is good enough to make open but I can't assume that far. That's
why I asked my question - do I have 100% chances to go GPL - way so I
can use bunch of external GPL code (no, I didn't met this requirement
yet but I'm still in planning phase).
Of course there are disadvantages of my solution like problem with
portability, complexity of project and my biggest fear - performance
impact, but nothing for free.
*Of course* I'll make as much as I can to lower trust in client but
there are some things which just can't be done with it. For example,
displaying drunk effect, proper lights and shades etc.
More information about the License-discuss