Suggestions for a custom bootstrap class loader

[George H]

On Tue, Jun 1, 2010 at 2:25 PM, Christian Thalinger
<Christian.Thalinger at sun.com> wrote:
> On Tue, 2010-06-01 at 12:22 +0300, George H wrote:
>> Problem did not arise form sprinkling magical encryption dust on the
>> JVM, it came from trying to find an opensource solution to this. So
>> far the only solution I can see if by using a Java to Native compiler.
>> The likes of which ExcelsiorJet is the only fully working and
>> proprietary solution. There are others like the GNU classpath, but it
>> lacks AWT and Swing support.
>
> I think you mean GCJ here.  It has AWT and Swing support, which is
> probably not 100% complete, but there is support for it.

Sorry yeah GCJ, I couldn't remember the name completely and for some
reason "class path project" was all that was popping up. Yes there is
AWT and Swing support but it is hardly from fully supported. I saw
what was supported and I do need something that supports the whole
thing.

SWT, I thought of it but decided against it because it is a different
way of building your GUI and we already have lots of Java applications
written using Swing and many custom components that are either derived
from or are modified instances of swing components.


On Tue, Jun 1, 2010 at 2:12 PM, Dan Hicks <danhicks at ieee.org> wrote:
> You could somewhat circumvent the debugger type issues if the code were
> always immediately JITCed before use. iSeries, which had a static compiler,
> used the similar technique of including only the JITCed code in the class
> file, omitting the visible bytecodes.  There was a way to find the bytecodes
> hidden in the JITCed code, but that was a "feature of convenience", not a
> necessary one.
>
> A system with a true JITC could decipher each method as it was referenced,
> immediately JITC it, then delete the deciphered bytecodes.  Of course this
> is not efficient JITC-wise (everything has to be JITCed to start with, and
> re-JITC is a pain), and there would be some details to work out on the
> decrypting by parts, but it's doable.
>
> And it's worth noting that most folks interested in this sort of thing
> aren't that anxious to have a "perfect" system -- they just want something
> that makes the job a little tougher.

That very interesting :) I didn't know the iSeries had that. I used to
use IBMs compiler to compile java byte-code to RPG and run them on
OS400s.

You're right on the part that if I can make it somewhat difficult then
why not. At least to the level of difficulty of someone trying to
reverse engineer a compiled binary, spending nights with a
disassembler, hex editor and what not. And if they are that determined
and succeed then they pretty much deserve it :)

I opt for encryption, if it can work without hassle, to prevent the
option of just copying jar files off the system and leaving. I can
minimize this by placing the program files in an encrypted disk
volume. If the disk is stolen or when the program is not running then
nothing can be taken. Should an administrator log in as root and try
to copy the Jar files then that's when having something that can't be
read or reverse engineered so easily would be good.

I have come to terms that I would need a mix of solutions.
1. Linux machine where root password is completely scrambled
2. JVM and application source code exist in an encrypted volume
3. An external program that accepts login credentials to mount the
encrypted volume and run the program
4. Program location is in a place outside of user's authority
5. Machine with no cd-rom drive and disabled USB drives so no one can
chroot to the Disk using a livecd/liveusb
6. Firewalls :)

At least the program will run smoothly and it'll be difficult to
perform un-authorized copying the files.

You all have been great! I learned quite a few things with your help.