Homayoun,
Such an approach would only make decompilation only marginally more
difficult. Reverse engineers would just have to first decompile your
class loader and then modify that code to save the decrypted class
files in another JAR.
In general there is no solution to protecting code without support
from hardware. Secure booting and securing software from the hardware
platform are still topics of research.
If you would still prefer to make it a tid bit harder to decompile
the code, your could create a JAR file with a class containing
a main() method, your secure class loader, the private key, and
an encrypted JAR. You could then invoke the secure class loader from
main() to decrypt the encrypted JAR using the JCE, as you would in
other binary content, and use a URLClassLoader to load directly
from the decrypted JAR file.
Again, this will only protect against the most casual reverse engineers.
Use of a good byte-code obfuscator will give you a lot more code security.
Alexander
On Sat, Jul 14, 2001 at 10:47:25PM -0700, Homayoun Yousefi'zadeh wrote:
> I have a specific question regarding the encryption
> of jar files.
>
> The specific issue that I have is to potentially prevent
> decompiling the bytecode available in a jar file supplied
> to an outside source.
>
> Could any one tell me how I can use JCE or any
> other API to prevent potential attacks for
> decompiling the bytecode by utilizing a
> self-contained security method?
>
> Your help is greatly appreciated.
>
> Regards,
> HY
>
>
> ----------------------------------------------------------------------
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
