Re: Business models

[Richard James <richard@techdrive.com.au>]

Mark Collins wrote:

>> Clever.

>> 

>> Everyone interessted in this kind of protection, should visit:

>> 

>> http://www.instinct.org/fravia/

>> 

>> apart from beeing a cracker site (and quite ugly) it actually contains a

>> couple of articles on how to protect your software. At least

>> 

>> http://www.instinct.org/fravia/protec.htm

>> 

>> should be interessting. Lots of the information is about DOS and Windows,

>> but they do have a Linux section, and in any case, the methods are

>> similar. The case stories are quite interessting.

> 

> 

> If memory serves me correctly, there's also some good Anti-debugging

> articles in several issues of 40hex (to stop people reverse engineering your

> funky new virus).

> 

> Nurgle

> 

> 

> ---------------------------------------------------------------------

> To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.dk

> For additional commands, e-mail: linuxgames-help@sunsite.dk

> 

> .

And if memory serves me correctly these only apply to people trying to 
reverse engineer by using a "trace mode" debugger. Which uses a special 
bit set in the processor to execute a command at a time and then return 
to the debugger with the state of the machine for example from 
programming the 68000 by Steve Williams

PC=00000500 USP=0001A2B0 SSP=00002000 ST=000=>IM=0
D 000000D0 000000D1 000000D2 000000D3 000000D4 000000D5 000000D6 000000D7
A 000000A0 000000A1 000000A2 000000A3 000000A4 000000A5 000000A6 0001A2B0
move $526,D0
-t
PC=00000506 USP=0001A2B0 SSP=00002000 ST=000=>IM=0
D 00000001 000000D1 000000D2 000000D3 000000D4 000000D5 000000D6 000000D7
A 000000A0 000000A1 000000A2 000000A3 000000A4 000000A5 000000A6 0001A2B0
add $528,D0

so to stop people doing this to your code you put in an instruction that 
causes the trace debugger to crash. I actually saw a program do this to 
me but the second time I debugged it I just skipped over the offending 
instruction and the code then executed normally. Of course you could 
make it so that the function that crashes the trace debugger is vital to 
your code but then somebody will just write a software debugger which 
won't crash or they will disassemble your code and work it out by 
reading it line by line. This technique of trace debug crashing only 
works against those who don't understand what is happening those who do 
will get around your little hack.

But in reality you are not going to use assembly or machine code so the 
point is moot.

A method that I think will work is to obfusicate a part of your code and 
make it essential to the game so that they can't see your hack. The more 
lines of code you have the harder it is to find your hack just as it is 
harder to find bugs. To use the example of the different graphics make 
the function that draws the graphic to the screen check its size so that 
a 16x16 tile will draw but a 32x32 tile won't draw but don't put the 
error message there put it somewhere further up the code by using 
exceptions. This way it is harder to see which module caused the error 
and trace it back. In your $Profit version totaly change the render code 
from your free version so that they cannot see the difference. And you 
end up with two "open source" programs one that will draw 32x32 tiles 
and one that bombs out on the more complex graphics for no reason.



---------------------------------------------------------------------
To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.dk
For additional commands, e-mail: linuxgames-help@sunsite.dk