encrypted java program
[157 byte] By [simhavcs@gmail.coma] at [2007-11-26 20:02:56] 
how to create a encrypted .java file.. so that after getting .class of encrypted java file ... that .class file should not be decompiled by decompiler
do a search on 'java obfuscation' altho it is not as strong as you probably hope.
dmbdmba at 2007-7-9 23:02:28 >
> how to create a encrypted .java file.. so that after
> getting .class of encrypted java file ... that .class
> file should not be decompiled by decompiler
It is impossible to fully protect a class file using encryption because if the JVM is to load the class and execute methods it must be able to decrypt the class. If the JVM can decrypt the class then so can any Joe Hacker.
sabre150a at 2007-7-9 23:02:29 >
I wouldn't say it was totally impossible. Writing a custom class loader to read encrypted class files wouldn't be particulary difficult - good, solid encryption classes are part of the java libraries.
But the problem is that you aren't secure if the program contains all the info it needs to run.
There are ways you could get key data from an outside source. The simplest would be to require the user to enter a passphrase before the main program runs. Or the program could obtain a certificate from an on-line source or a local certificate store.
Of course one a user has the information required to run the program, they also have the information required to reverse-engineer it.
Java really doesn't lend itself to closed-source ecconomics - a fact in which many of us rejoice.
malcolmmca at 2007-7-9 23:02:29 >
> I wouldn't say it was totally impossible.
I would! You can make it difficult but it is impossible to make it totally secure.
> Writing a custom class loader to read encrypted class
> files wouldn't be particulary difficult - good, solid
> encryption classes are part of the java libraries.
I have written such a class loader. There are encrypted class loaders written in C but once the class is unencrypted in memory then is is easy to turn the content back into a class file.
>
> But the problem is that you aren't secure if the
> program contains all the info it needs to run.
Exactly!
>
> There are ways you could get key data from an outside
> source. The simplest would be to require the user to
> enter a passphrase before the main program runs.
This is still open to Joe Hacker because all one has to do is modify the program so that it writes out the passphrase or just writes out the unencrypted class.
> Or
> the program could obtain a certificate from an
> on-line source or a local certificate store.
Same problem. If I can get into the program I can get hold of the loaded class file and write it out.
>
> Of course one a user has the information required to
> run the program, they also have the information
> required to reverse-engineer it.
Exactly!
>
> Java really doesn't lend itself to closed-source
> ecconomics - a fact in which many of us rejoice.
Even C and C++ programs have the same problem. The main difference is in the difficulty of reverse engineering compiled code to C or C++.
sabre150a at 2007-7-9 23:02:29 >
Try Proguard.. the open source java obfuscator http://proguard.sourceforge.net/see the feature list and comparison chart to find out if it suits tour requirements.Zelix is a good if you are looking for commercial options. http://www.zelix.com/null
PrinceSingha at 2007-7-9 23:02:29 >
>This is still open to Joe Hacker because all one has to do is modify the
>program so that it writes out the passphrase or just writes out the unencrypted
> class.
Obviously the passphrase isn't stored in the program - it's hashed to produce a cryptographic key. So you could make it virtually impossible to reverse-engineer the program without the passphrase, or without access to the certificate store or whatever.
Thus you could restrict the vulnerability to authorised users of the program.
malcolmmca at 2007-7-9 23:02:29 >
> >This is still open to Joe Hacker because all one has
> to do is modify the
> >program so that it writes out the passphrase or just
> writes out the unencrypted
> > class.
>
> Obviously the passphrase isn't stored in the program
> - it's hashed to produce a cryptographic key. So you
> could make it virtually impossible to
> reverse-engineer the program without the
> passphrase, or without access to the certificate
> store or whatever.
1) Decompile the program. Find the code that reads in the passphrase. Modifiy the code to write the passphrase to a file or to a socket.
OR
2) Decompile the program. Find the class loader. Modify the class loader to write the bytes of the class to a file or to a socket.
Option 2) will work even with a 'certificate'.
>
> Thus you could restrict the vulnerability to
> authorised users of the program.
Not really. In Windows, pretty much anyone who can log on to the computer can modify the program.
sabre150a at 2007-7-9 23:02:29 >
>
> 1) Decompile the program. Find the code that reads in
> the passphrase. Modifiy the code to write the
> passphrase to a file or to a socket.
>
> OR
>
> 2) Decompile the program. Find the class loader.
> Modify the class loader to write the bytes of the
> class to a file or to a socket.
>
Both of these require access to the passphrase or certificate, unless you can trick an authorized user into running a "trojan" version.
You can increase the security by signing the jar.
malcolmmca at 2007-7-9 23:02:29 >
> >
> > 1) Decompile the program. Find the code that reads
> in
> > the passphrase. Modifiy the code to write the
> > passphrase to a file or to a socket.
> >
> > OR
> >
> > 2) Decompile the program. Find the class loader.
> > Modify the class loader to write the bytes of the
> > class to a file or to a socket.
> >
>
>
> Both of these require access to the passphrase or
> certificate, unless you can trick an authorized user
> into running a "trojan" version.
No! Just access to the Jar. One just modifies the jar and when the user next runs the program he tell all!
>
> You can increase the security by signing the jar.
If I sign a jar with a self signed certificate then the authorized user can still run the jar and he gets no messages. If the signature is checked within the jar then one just has to modify the check so that it is ignored.
sabre150a at 2007-7-9 23:02:29 >
> >
> > 1) Decompile the program. Find the code that reads
> in
> > the passphrase. Modifiy the code to write the
> > passphrase to a file or to a socket.
> >
> > OR
> >
> > 2) Decompile the program. Find the class loader.
> > Modify the class loader to write the bytes of the
> > class to a file or to a socket.
> >
>
>
> Both of these require access to the passphrase or
> certificate, unless you can trick an authorized user
> into running a "trojan" version.
>
> You can increase the security by signing the jar.
Far easier...
Decompile the classloader.
Tell it to write the decrypted classes out to the filesystem.
jwentinga at 2007-7-9 23:02:29 >
> Far easier...> Decompile the classloader.Well, naturally the classloader would be encrypted to prevent just that situation.;-)
jverda at 2007-7-9 23:02:30 >
>
> Far easier...
> Decompile the classloader.
> Tell it to write the decrypted classes out to the
> filesystem.
If the classloader uses a cryptographic key constructed from the passphrase, plus a digest of the unencrpted parts of the jar then, I repeat, you can't decompile the encrypted classes without knowing the passphrase.
malcolmmca at 2007-7-9 23:02:30 >
So, we're assuming I don't have admin rights on the computer on which I'm running this software?
jverda at 2007-7-9 23:02:30 >
Admin rights have no bearing. Passphrases are never filed.An encrypted class repository is no different from a secret-key encrypted text file. If you don't have the key admin rights won't help you.
malcolmmca at 2007-7-9 23:02:30 >
> >
> > Far easier...
> > Decompile the classloader.
> > Tell it to write the decrypted classes out to the
> > filesystem.
>
> If the classloader uses a cryptographic key
> constructed from the passphrase, plus a digest of the
> unencrpted parts of the jar then, I repeat, you can't
> decompile the encrypted classes without knowing the
> passphrase.
But you can decompile the unencrypted classes that are used to process the passphrase (these must be unencrypted else you have a chicken and egg problem) so you can modify these so as to write the passphase to disk or a socket.
sabre150a at 2007-7-21 17:49:42 >
> Admin rights have no bearing. Passphrases are never
> filed.
If I have admin rights, I can observe and intercept anything that goes on.
> An encrypted class repository is no different from a
> secret-key encrypted text file. If you don't have the
> key admin rights won't help you.
Th encrypted class repository must be unencrypted to be used. Once that happens, I can peek at it.
jverda at 2007-7-21 17:49:42 >
I'm not denying that if you are able to run the program, you are potentially able to decompile it.
And just as with any encrypted document there's a potential for some power user getting a look at the plaintext version in memory (or in some cases, swap space). That's why good crypto programs overwrite plaintext memory versions rather than just release them.
But its not going to be easy. The plaintext classes will never be written to disc, (other than the possibility of swap space writes).
What you could do is to make sure that a copy of the program jar is useless without someone on the system knowing the passphrase.
malcolmmca at 2007-7-21 17:49:42 >
> I'm not denying that if you are able to run the
> program, you are potentially able to decompile it.
>
> And just as with any encrypted document there's a
> potential for some power user getting a look at the
> plaintext version in memory (or in some cases, swap
> space). That's why good crypto programs overwrite
> plaintext memory versions rather than just release
> them.
>
> But its not going to be easy. The plaintext classes
> will never be written to disc, (other than the
> possibility of swap space writes).
>
> What you could do is to make sure that a copy
> of the program jar is useless without someone on the
> system knowing the passphrase.
One of us is missing something! If I run a program (java or otherwise) at least part of it must be unencrypted or I can't run it in the first place. If that program asks for a passphrase to allow it in some way load a part that is encrypted then all the code up to and including the reading of the passphrase MUST be unencrypted (chicken and egg). Therefore, I (Joe Hacker) can modify the program so that once the passphrase has beentyped in by the real user the passphrase is written to a file or a socket.
Once the real user has run my modified program and I have the passphrase I can look at the decryption process and decrypt the encrypted part for myself.
sabre150a at 2007-7-21 17:49:43 >
> Once the real user has run my modified program and I
> have the passphrase I can look at the decryption
> process and decrypt the encrypted part for myself.
This is the Trojan approach, but it involves Joe Hacker being able to substitute his own program for the one the authorized user thinks he's running.
Rather than modifying the program he'd create a program that imitates the original up to the point when the user was fooled into entering the passphrase - a kind of phishing scam. The trojan might then go on to run the original program, entering the passphrase as requested so the authorized user doesn't see anything amiss.
Or, more simply, he could sneak a key logger into the system, or watch the authorized user's fingers.
This is an inherent vulnerability when using passphrases, not in any sense peculiar to java programs. You still need the passphrase, but there are ways of stealing it.
malcolmmca at 2007-7-21 17:49:43 >
> Rather than modifying the program he'd create a
> program that imitates the original up to the point
> when the user was fooled into entering the passphrase
> - a kind of phishing scam. The trojan might then go
> on to run the original program, entering the
> passphrase as requested so the authorized user
> doesn't see anything amiss.
Isn't it easier to just modify one of the bootstrap* classes just as the other have said?
*) Bootstrap isn't the sun bootstrap in this case, it's your "bootstrap" which loads the encrypted classes and decrypts them.
kajbja at 2007-7-21 17:49:43 >
Java Essentials New Topic
Java Essentials Hot Topic
Java Essentials
All Classified
- Archived Forums
- Enterprise & Remote Computing
- Java Essentials
- Desktop
- Core
- Solaris Operating System
- Security
- Database Connectivity
- Java Mobility Forums
- Web & Directory Servers
- Development Tools
- Application & Integration Servers
- Java HotSpot Virtual Machine
- Other Topics
- E-Mail, Calendar, & Collaboration
- Developer Tools
- General
- Administration Tools
- Sun Hardware
- Storage Forums
- Java Enterprise System
- StarOffice
- Open Source Technologies
- BigAdmin
- Real-Time
- Java Coding