Bill Volk wrote:
> > [ Decompiling java ]
> I think there are two main steps you can take to prevent this.
> =
> 1. Use code obsufcators and compressors to make the code harder to
> de-compile.
IMHO: obfuscation isn't worth much - real reverse engineers are used to
having NO variable/function names at all. There are tricks to fool some
tools like Mocha, but I'm pretty sure someone who REALLY wants to
succeed will manage anyway. I'm not quite sure what you mean by a
compressor in this sense. The main problem is that the code HAS to run
in a typical java engine (which in many ways is simpler than a classic
CPU and by definition easy to emulate), which means that a somewhat
tweaked java engine can produce a nice little trail to follow.
> 2. Have the software access assets from a server via. HTTP and use some=
> sort of authentication scheme to verify that the software is a
> legitimate purchase.
May work, but remember that the java code has already been cracked, so
the server will have to figure out which is the REAL call an what is
fake somehow. Perhaps you can use some kind of registration key, but
most likely the cracker already has ONE proper key (from the instance
s/he cracked)... Never ending problem.
BTW: Here is an old article on the subject:
http://www-106.ibm.com/developerworks/java/library/j-obfus/
/ Jonas
-- =
Jonas Petersson | XMS Penvision | mailto:Jonas.Petersson@xms.se
Box 3294, V=E4stg=F6tegatan 13, S-600 03 Norrk=F6ping | http://www.xms.se=
/
Tel: +46 11 400 13 00 | Dir: +46 11 400 13 05 | Fax: +46 11 10 30 50
Received on Mon Sep 1 22:45:49 2003