Obviscation is an art-form, the intention of which is to make it so difficult
to reverse engineer your code that either noone will do it, or by the time
someone has, you are on a new version. If I was at my own PC I would paste in
a long list of useful links, but if you do a google search for it you will
find loads of useful resources.

There are obviscation tools out there which provide a starting point, but
because these tools are well-known, the best obviscation is always developed
in-house (and changed with each version).

Basically, the first step is to change a Java class file so that it is
semantically identical, but will not decompile into legal Java Language
source code. (E.g. changing variable names to Java reserved words, having
fields with the same name but of different types, etc)

All methods and fields which are not referenced by anything external to your
application can also be change to meaningless Strings. Some obviscators use a
system like using the letter 'a' for each different combination of
singatures, when you have a method with the same signature (or for a field,
type) you rename it (and all references to it, of course) to 'b'.

I prefer to rename fields and methods to strings made up of similar but
randomly changing 16 characters; I think is makes the code much harder to
trace through. (i.e. take a random 16 character string to start with. For the
first method or field, use this string. Then randomly change the string by
one character, check a list to make sure you haven't used it before, use it.
etc.)

The last step is to put in code that checks for changes in other parts of the
code and modifes the execution of the code. This should be in several places
throughout the application and be as cunning as you desire. For example, say
you have a piece of code which checks the user's license key in class
LicenseChecker (unobviscated name). After you have compiled and obviscated
your application, take a hash (e.g. MD5 or SHA1) of the class file and
hardcode it somewhere in your application. In another piece of code deeper
into your application, you can take the hash again and compare it the
hardcoded value. If they differ, you know the license class has been
modified. You can then perform whatever devious action you like at some
unexpected later time, e.g. post some information to your server (careful of
the legalities here) and popup a message saying that they have been traced as
using illegal software and then close down (without saving).

If you put similar code in at various places throughout your application,
then the cracker will never know that their task is complete. Unless, of
course, they have the time to trawl through and unobviscate your entire
application, by which time they could probably have written it themselves.

Before embarking on this route, you should really ask yourself if it is worth
all the effort. The only way to entirely(?) guarentee that your source will
never be read by someone outside your organization is to provide a
server-based solution - If they never have access to your code, they will
never be able to crack it.

Richard Martin
Netlogic Data Solutions Ltd.
+447876653959

On Monday 29 April 2002 08:17 am, Tinashe Bothwell Chipomho wrote:
> but guys what will stop the users from decompiling the class files and
> still figure out your tricks and the keys staff?
> may be you can explain more on "obfusticate"
>
> -----Original Message-----
> From: SAMINATHAN [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, April 28, 2002 11:02 PM
> To: [EMAIL PROTECTED]
> Subject: Re: prevent cracking my class files
>
>
> This is what exactly we are looking for.Thanks a lot.
>
> Thanks and Regards
> Saminathan.
>
>
> ----- Original Message -----
> From: "Keith Sterling" <[EMAIL PROTECTED]>
> To: "'SAMINATHAN'" <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Sent: Monday, April 29, 2002 11:01 AM
> Subject: RE: prevent cracking my class files
>
> > What you are looking for is full copy protection. We use Rainbow
> > Technologies http://www.rainbow.com/ License Manager
> >
> > This is a server that runs on the network and checks how many copies are
> > running. If each of you applications cannot talk to the server then they
> > won't start up.
> >
> > They key is generated by using taking a snap shot of the hardware the
>
> server
>
> > is running on, customers send this back to us during install, and we send
> > them back a full license key. We normally include a 30 day eval license
> > so that non UK customers are not hit with time zone problems trying to
>
> contact
>
> > us
> >
> > In addition we obfusticate all our code to stop reverse engineering
> >
> > Both work well and stop any form of copying
> >
> > -------------------------------------------------------------------------
> > Keith Sterling
> > Jacobs Rimell
> > VP of Engineering
> >
> > Jacobs Rimell Ltd
> > 24 Chiswell St
> > London EC1Y 4TY
> > Tel : +44 207 786 4000
> > Mob : +44 7771 597 630
> > Fax : +44 207 786 4004
> > http://www.jacobsrimell.com
> > -------------------------------------------------------------------------
> > IMPORTANT NOTICE:
> > This email is confidential, may be legally privileged, and is for the
> > intended recipient only.  If you are not the intended recipient, please
> > inform the sender and delete the email immediately.
> > WARNING:
> > It is impossible to guarantee the content of this message when it is
> > delivered across the internet, therefore the  sender accepts no liability
> > for any claims arising from the information contained.
> >
> >
> > -----Original Message-----
> > From: SAMINATHAN [mailto:[EMAIL PROTECTED]]
> > Sent: 29 April 2002 05:59
> > To: [EMAIL PROTECTED]
> > Subject: Re: prevent cracking my class files
> >
> > We also facing some kind of similar issue but in our case we want to
> > restrict of installation.If client buys for 5 user license we don't want
>
> to
>
> > allow more than 5 people accessing our server.
> >
> > bye
> > Saminathan.
> >
> > ----- Original Message -----
> > From: "Ramesh" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, April 29, 2002 10:17 AM
> > Subject: Re: prevent cracking my class files
> >
> > > hi
> > >         u want just disable re-engineering or to disable unauthorized
> >
> > copying??
> >
> > > Using obfuscators available in market you can make re-engineering
> >
> > difficult.
> >
> > > To disable unauthorized copying a combination of techniques can be
> > > used.
> >
> > One
> >
> > > such technique is to generate a key for each distribution and write a
> > > separate
> > > class loader to load and check this generated key in the main class if
>
> it
>
> > is
> >
> > > tampered exit the program.
> > > thanks
> > > ramesh
> > >
> > > -----Original Message-----
> > > From: A mailing list for Enterprise JavaBeans development
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Kesav, Ramesh
> > > Sent: Monday, April 29, 2002 9:49 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: prevent cracking my class files
> > >
> > >
> > >
> > > Hi all,
> > >
> > >    i have a product being developed for Chartered Accountants. It is a
> >
> > swing
> >
> > > application.Now i want to sell the product to various parties but i do
>
> not
>
> > > want them to crack my class files.
> > > I had 2 ideas
> > > 1) first i will convert these class files into executables but i heard
> >
> > that
> >
> > > javatoexe is not the appropriate one.
> > > 2) secondly i thought of writing this class files into a cd and somehow
>
> i
>
> > > need to put a cd key in it.how to do this.
> > >
> > > any other suggestions are mostly welcome.
> > >
> > > Regards
> > >
> > > Ramesh Kesavanarayanan
> > > [EMAIL PROTECTED]
>
> ===========================================================================
>
> > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> >
> > body
> >
> > > of the message "signoff EJB-INTEREST".  For general help, send email to
> > > [EMAIL PROTECTED] and include in the body of the message "help".
>
> ===========================================================================
>
> > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> >
> > body
> >
> > > of the message "signoff EJB-INTEREST".  For general help, send email to
> > > [EMAIL PROTECTED] and include in the body of the message "help".
>
> ===========================================================================
>
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
>
> body
>
> > of the message "signoff EJB-INTEREST".  For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST".  For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST".  For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".

==============================================================================
This email and any files transmitted with it are confidential and intended solely for 
the use of the individual or entity to whom they are addressed. All information is the 
view of the individual and not necessarily the company. If you are not the intended 
recipient you are hereby notified that any dissemination, distribution, or copying of 
this communication and its attachments is strictly prohibited. If you have received 
this email in error please notify:
[EMAIL PROTECTED]


==============================================================================

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to