Discussion:
Finally java class file encryption possible.
(too old to reply)
Java Encryptor
2013-10-25 09:16:01 UTC
Permalink
Distribute java program by encrypting it and keep your source code secure.

Java Encryptor encrypts class files into .vin files.
You will get an Java Executer (.exe) to execute the .vin (encrypted class) files.
Your source code is secure.

Each Java Encryptor is coded with unique key combination.

Try one sample java example encrypted using two diffrent Java Encryptors.

visit http://encryptjava.blogspot.in/
Roedy Green
2013-10-25 11:08:33 UTC
Permalink
On Fri, 25 Oct 2013 02:16:01 -0700 (PDT), Java Encryptor
Post by Java Encryptor
Distribute java program by encrypting it and keep your source code secure.
But does not it work by decrypting then running as a normal class
file? What is to stop the hacker from taking a snapshot of the class
file and running it through a decompiler?
--
Roedy Green Canadian Mind Products http://mindprod.com
Unlike many machines, computers require no water once they are
manufactured.
Jukka Lahtinen
2013-10-25 13:21:57 UTC
Permalink
Post by Roedy Green
On Fri, 25 Oct 2013 02:16:01 -0700 (PDT), Java Encryptor
Post by Java Encryptor
Distribute java program by encrypting it and keep your source code secure.
But does not it work by decrypting then running as a normal class
file? What is to stop the hacker from taking a snapshot of the class
But do you really think that those multiposting spammers read the
newsgroups they spam and answer questions?
--
Jukka Lahtinen
Java Encryptor
2013-10-27 13:40:11 UTC
Permalink
Post by Jukka Lahtinen
Post by Roedy Green
On Fri, 25 Oct 2013 02:16:01 -0700 (PDT), Java Encryptor
Post by Java Encryptor
Distribute java program by encrypting it and keep your source code secure.
But does not it work by decrypting then running as a normal class
file? What is to stop the hacker from taking a snapshot of the class
But do you really think that those multiposting spammers read the
newsgroups they spam and answer questions?
--
Jukka Lahtinen
Hi Jukka,

I have answered the question.
This tool doesn't store the decrypted class files on the disk.
These are on the fly... no one can get the class files.

I think you should check the sample program first.
Java Encryptor
2013-10-27 13:37:01 UTC
Permalink
Post by Roedy Green
On Fri, 25 Oct 2013 02:16:01 -0700 (PDT), Java Encryptor
Post by Java Encryptor
Distribute java program by encrypting it and keep your source code secure.
But does not it work by decrypting then running as a normal class
file? What is to stop the hacker from taking a snapshot of the class
file and running it through a decompiler?
--
Roedy Green Canadian Mind Products http://mindprod.com
Unlike many machines, computers require no water once they are
manufactured.
This program decrypts class file in memory and no one can see it.
You can check the sample program...
Daniel Pitts
2013-10-27 17:25:12 UTC
Permalink
Post by Java Encryptor
Post by Roedy Green
On Fri, 25 Oct 2013 02:16:01 -0700 (PDT), Java Encryptor
Post by Java Encryptor
Distribute java program by encrypting it and keep your source code secure.
But does not it work by decrypting then running as a normal class
file? What is to stop the hacker from taking a snapshot of the class
file and running it through a decompiler?
This program decrypts class file in memory and no one can see it.
You can check the sample program...
For those who really want encrypted, secure class files, that isn't
secure enough. What's to stop someone from modifying your code to write
the result to file? What's to stop someone from modifying the JVM to
allow dumping of classes? Or creating their own class-loader to
intercept the JVM loading of the class.

I think you're trying to solve an impossible problem.
Java Encryptor
2013-10-28 12:52:09 UTC
Permalink
Post by Daniel Pitts
Post by Java Encryptor
Post by Roedy Green
On Fri, 25 Oct 2013 02:16:01 -0700 (PDT), Java Encryptor
Post by Java Encryptor
Distribute java program by encrypting it and keep your source code secure.
But does not it work by decrypting then running as a normal class
file? What is to stop the hacker from taking a snapshot of the class
file and running it through a decompiler?
This program decrypts class file in memory and no one can see it.
You can check the sample program...
For those who really want encrypted, secure class files, that isn't
secure enough. What's to stop someone from modifying your code to write
the result to file? What's to stop someone from modifying the JVM to
allow dumping of classes? Or creating their own class-loader to
intercept the JVM loading of the class.
I think you're trying to solve an impossible problem.
It is not that easy as decompiling class files using decompiler.
Anyone can use decompilers to get code without efforts.

To modify JVM, compiling, installing, dumping classes and then decompiling classes would really need a lot efforts.

And no one would like anyone to see his/her code easily.
Steven Simpson
2013-10-28 15:57:07 UTC
Permalink
Post by Java Encryptor
Try one sample java example encrypted using two diffrent Java Encryptors.
visit http://encryptjava.blogspot.in/
I downloaded Sample1.zip and extracted it. How do I execute it? I've
tried running JavaExecutor.exe with no arguments, and with "One" and
"One.vin", but keep getting "Error executing Java".

java -version reports:

java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
--
ss at comp dot lancs dot ac dot uk
Java Encryptor
2013-10-29 18:30:08 UTC
Permalink
Post by Steven Simpson
Post by Java Encryptor
Try one sample java example encrypted using two diffrent Java Encryptors.
visit http://encryptjava.blogspot.in/
I downloaded Sample1.zip and extracted it. How do I execute it? I've
tried running JavaExecutor.exe with no arguments, and with "One" and
"One.vin", but keep getting "Error executing Java".
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
--
ss at comp dot lancs dot ac dot uk
Hi Steven,

Thanks for your kind consideration.
There is no need of passing parameters. Just need to run exe file.
I think this is due to 64 bit version of jre.
It's working fine with 32 bit version.
If you can share the os details and confirm if it works with 32 bit version, that would help.

However I am working to solve 64 bit version issue and keep you posted.

Thanks and Regards,
Java Encryptor
Steven Simpson
2013-10-29 22:22:22 UTC
Permalink
Post by Java Encryptor
I think this is due to 64 bit version of jre.
It's working fine with 32 bit version.
If you can share the os details
"Windows 7 Enterprise"
--
ss at comp dot lancs dot ac dot uk
Java Encryptor
2013-10-30 12:38:00 UTC
Permalink
Post by Steven Simpson
Post by Java Encryptor
I think this is due to 64 bit version of jre.
It's working fine with 32 bit version.
If you can share the os details
"Windows 7 Enterprise"
--
ss at comp dot lancs dot ac dot uk
Hi Steven,

Thanks for the details and your patience.

The problem was due to 64 bit version of java.

The 32 bit exe could not execute 64 bit version.

I have updated the files with two versions of exe files.
32 bit version and 64 bit version.

This should work fine on XP, Vista and Windows 7.

Let me know if you have any other issue.

Regards,
Java Encryptor
Steven Simpson
2013-10-30 13:54:51 UTC
Permalink
Post by Java Encryptor
I have updated the files with two versions of exe files.
32 bit version and 64 bit version.
Now it works, thanks.

However, I've managed to obtain classfiles for One, Two, Three and even
VinZipCryptClassesLoader, by injecting a dump into one of the
defineClass methods of java.lang.ClassLoader (which Daniel Pitts
suggested). It wasn't a lot of effort. Isn't this what you are trying
to avoid?

Here's a snippet of the output of "javap -verbose One":

Classfile One.class
Last modified 30-Oct-2013; size 601 bytes
MD5 checksum 09d43a1e5d0013dcc26748271dd675b8
Compiled from "One.java"
public class One
SourceFile: "One.java"
minor version: 0
major version: 51
flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
#1 = Class #21 // One
#2 = Methodref #1.#22 // One."<init>":()V
#3 = Methodref #12.#22 // java/lang/Object."<init>":()V
#4 = Class #23 // javax/swing/JFrame
#5 = Methodref #4.#22 // javax/swing/JFrame."<init>":()V
#6 = String #24 // Hello! We are in class One.
#7 = Methodref #25.#26 // javax/swing/JOptionPane.showMessageDialog:(Ljava/awt/Component;Ljava/lang/Object;)V
#8 = Class #27 // Two
#9 = Methodref #8.#22 // Two."<init>":()V
#10 = String #28 // We are back in class One from Class Two-Three.

etc...
--
ss at comp dot lancs dot ac dot uk
Java Encryptor
2013-10-30 17:40:28 UTC
Permalink
Post by Steven Simpson
Post by Java Encryptor
I have updated the files with two versions of exe files.
32 bit version and 64 bit version.
Now it works, thanks.
However, I've managed to obtain classfiles for One, Two, Three and even
VinZipCryptClassesLoader, by injecting a dump into one of the
defineClass methods of java.lang.ClassLoader (which Daniel Pitts
suggested). It wasn't a lot of effort. Isn't this what you are trying
to avoid?
Classfile One.class
Last modified 30-Oct-2013; size 601 bytes
MD5 checksum 09d43a1e5d0013dcc26748271dd675b8
Compiled from "One.java"
public class One
SourceFile: "One.java"
minor version: 0
major version: 51
flags: ACC_PUBLIC, ACC_SUPER
#1 = Class #21 // One
#2 = Methodref #1.#22 // One."<init>":()V
#3 = Methodref #12.#22 // java/lang/Object."<init>":()V
#4 = Class #23 // javax/swing/JFrame
#5 = Methodref #4.#22 // javax/swing/JFrame."<init>":()V
#6 = String #24 // Hello! We are in class One.
#7 = Methodref #25.#26 // javax/swing/JOptionPane.showMessageDialog:(Ljava/awt/Component;Ljava/lang/Object;)V
#8 = Class #27 // Two
#9 = Methodref #8.#22 // Two."<init>":()V
#10 = String #28 // We are back in class One from Class Two-Three.
etc...
--
ss at comp dot lancs dot ac dot uk
Thanks,

So basically there is no way we can prevent our class from de-compiling.
Joerg Meier
2013-10-30 18:17:25 UTC
Permalink
Post by Java Encryptor
So basically there is no way we can prevent our class from de-compiling.
No, of course not - in the end, the computer still has to be able to decode
them to run them, and anything the computer does, a potential thief can do.
It's best to just obfuscate your code and then be done with it and accept
that some people will be looking at your code.

Liebe Gruesse,
Joerg
--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.
markspace
2013-10-30 19:06:22 UTC
Permalink
Post by Joerg Meier
Post by Java Encryptor
So basically there is no way we can prevent our class from de-compiling.
No, of course not - in the end, the computer still has to be able to decode
them to run them, and anything the computer does, a potential thief can do.
It's best to just obfuscate your code and then be done with it and accept
that some people will be looking at your code.
Obfuscation can make stack traces and log output hard to read (they'll
print the obfuscated class and method names).

Better I think to:

1. Provide enough value that it's more work to steal code than it is to
subscribe to your service/product.

2. Keep some of the code on a server where folks can't get at it, and
make API calls over the network to return results.

3. Use the courts for egregious cases of theft.
Joerg Meier
2013-10-30 20:27:39 UTC
Permalink
Post by markspace
Post by Joerg Meier
Post by Java Encryptor
So basically there is no way we can prevent our class from de-compiling.
No, of course not - in the end, the computer still has to be able to decode
them to run them, and anything the computer does, a potential thief can do.
It's best to just obfuscate your code and then be done with it and accept
that some people will be looking at your code.
Obfuscation can make stack traces and log output hard to read (they'll
print the obfuscated class and method names).
ProGuard at least, which is free and the #1 java obfuscator/optimizer,
provides a listing of pre- and post-obfuscation names, so that a stack
trace can (automatically) be unobfuscated.
Post by markspace
1. Provide enough value that it's more work to steal code than it is to
subscribe to your service/product.
I enjoy to code, and I do not enjoy support. I do what I must, but the code
I write is the main 'product' I supply. While in general and for a company
I would agree, that just isn't always feasible.
Post by markspace
2. Keep some of the code on a server where folks can't get at it, and
make API calls over the network to return results.
That of course has the same issue as the 'encrypter' that started this
thread. I prefer to keep some crucial assets on the server - such as the
xml specifying units in a game for example - because as shown it is
relatively easy to google how to get a class from a running Java program,
but while getting whatever resources I get would be just as easy, it's not
as easily googleable. [1]
Post by markspace
3. Use the courts for egregious cases of theft.
Especially due to internationality that only really becomes an option above
a pretty high threshold, that for example the typical Android app just
wouldn't cross.

[1] - I recognize that that is 'security by obscurity', but the difference
here is that I do not aim for 100% security, just to raise the difficulty
to a level where my effort to implement it is still very low while the
amount of people turned back by it is still very high - a level typically
reached once you can't easily google the problem without knowing the
context.

Liebe Gruesse,
Joerg
--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.
e***@gmail.com
2014-02-12 11:21:37 UTC
Permalink
Shield4J (http://shield4j.com) is the perfect solution to obfuscation and encryption of Java class files
Post by Java Encryptor
Distribute java program by encrypting it and keep your source code secure.
Java Encryptor encrypts class files into .vin files.
You will get an Java Executer (.exe) to execute the .vin (encrypted class) files.
Your source code is secure.
Each Java Encryptor is coded with unique key combination.
Try one sample java example encrypted using two diffrent Java Encryptors.
visit http://encryptjava.blogspot.in/
Loading...