Jump to content
Excelsior Forums
matchy

"bind classes" option and reverse-engineering

Recommended Posts

hi all,

for some API packages that employ dynamic class loading such as JCE, one is required to bind the class files to the executable using the "bind classes" option in order to make them work.

however, this means the classes can now be extracted from the exe generated, and this implies people are now free to reverse-engineer any classes that are binded to the executable.

in this case, how can we protect the intellectual property of those classes that are binded in the exe??

one possibility is to obfuscate the classes before they are binded. however, JET will fail to compile the bytecode if the obfuscation process changes anything other than class and method names.

is it possible for JET to provide an option so that those binded classes are executed in virtual machine mode instead of native mode?? in this case we can safely embed fully obfuscated code into the executable.

another possibility is to have those binded classes to be encrypted using a secret key that is hided within the exe code. so that only the exe knows how to decrypt the classes and compile them for execution.

what is your thought on this issue??

--matchy

Share this post


Link to post
Share on other sites

You're right, it is really a problem.

Currently, there is only one addition.

one possibility is to obfuscate the classes before they are binded. however, JET will fail to compile the bytecode if the obfuscation process changes anything other than class and method names
Honestly, there are several obfuscators that produce classes that cause JET to fail. It seems that you have using one of them. But, there are also some good obfuscators that produce class files with NOT only class and method names changed, and with class files are compilable by JET. For instance, you can try to use DashoPro obfuscator.

Share this post


Link to post
Share on other sites

×