Open Source application GPL legality

[shd]

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 
that later).
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 
environment).
* 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 
'secure' channel
<- <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.

Cheers,
Mariusz Gliwiński