attempt to crack my encrypted class loader: http://ux-soft.com/uploads/JarProt2.zip
uses a custom class loader at runtime to dynamically load required classes.
currently protects against:
- decompilers
- JVMTI
- Instrumentation
I further to what I said in the other thread. No one trying does not make this secure.
Wait. It has a DLL so it won’t run on linux, and whats the deal with using rar. Use xz already.
I could easily make it work with Linux, the same way LWJGL has a native library but can run on many platforms. The only thing i’m trying to do here is see how easy it is for members of this board to crack this protection, to have an idea on how good the protection could turn out to be.
Sorry for using rar, i’ll give you a zip in a sec: http://ux-soft.com/uploads/JarProt.zip
I don’t have windows. Just linux. So don’t bother on my account.
In that other thread I already explained how any bytecode encrypter would be useless, if you alter the JVM.
Besides it was already said that any client-side security is guaranteed to be unsafe.
It might be fun for you to try this, learn from it, but please don’t think you’re doing anything more than raising the bar a little and providing a false sense of security.
any bytecode encrypter is useless if I alter the JVM?
all this does is at runtime, place a couple inline hooks on core JVM functions, effectively changing the behaviour of the classloader
Not if you alter the jvm, if someone else does… the jvm has to load the classes as pure byte arrays eventually, unecrypted. If for instance I change the jvm to load classes and wrote them out to disk i’ll have your unecrypted class files.
I think that’s what he meant
Kev
Javassist+20 lines of code=this bytecode encryption broken.
It’d take longer to setup the eclipse project than it would to write the code to bypass this ‘security’ 
Provide a 64bit dll and i’ll write it for you if you like.
i’m unable to compile it for 64 bit at this moment, what would you do to bypass the dll? i’m curious 
The very functions used to load the unencrypted class bytes into the JVM can be detoured by native code. This allows the JVM to accept virtually a file of any format, as long as the detoured function is able to construct a class at runtime out of it.
Example:
byte * yourFunctionBytes = GetProcAddress( .. );
yourFunctionBytes[x] = 0xE9;
yourFunctionBytes[x+1] = (pfunc >> 24);
yourFunctionBytes[x+2] = (pfunc >> 16);
.. etc
by applying a detour, the original code that handles the construction of the class can be replaced with your own class construction code
I think you’ve missed Riven’s point. The “attacker” can create a modified JVM which bypasses anything you can do. In any situation where the user has access to the software or hardware that decrypts information, the war is lost.
I concede that javassist would not help in breaking your encryption, as you are performing the class definition call in native code too.
However, as others have pointed out there are still avenues of attack that cannot be blocked.
Here’s an excellent article practically written to answer this thread.
Summary: Delve into the native code of the VM & perform the interception there, or hook into the VM through the JVMTI & listen for the class load event.
The idea is to encrypt classes and decrypt them in-memory at runtime. If a user has the classes but no key, they cannot use the classes without breaking the encryption. Sure, if someone has the key, they can dump the unencrypted classes: if you can run it, you can crack it. This idea is still useful for crippleware. It is the best you can do to protect your software if you want crippleware.
Here is the same idea, but for native code:
It encrypts a section of your lib and at runtime decrypts and patches the section in-memory. If you bypass the simple “isRegistered” checks, you’ll jump into encrypted code, execute random garbage, and crash. If you have a valid key, you can dump the memory after decryption and then patch the lib on disk.
Of course, your time is probably better spent improving your software so that more people want it, rather than trying to stop people from stealing it. I understand it can be fun to play around with though, just as is creating useless games.
[quote=“Nate,post:12,topic:36600”]
;D So true! Imitation is the sincerest form of flattery.
Any software written in any language can be cracked, I’m just attempting to make it harder to crack it, even make cracking Java as hard as cracking C/C++ applications.
It’s possible to patch the JVMTI exploit. Go here: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/file/13f94cc87253/src/share/vm/classfile/classFileParser.cpp
note how on line 2558 there’s a check for JvmtiExport should load class hook, inline patching this to always force false would fix the JVMTI exploit. Alternatively, inline patch the whole function to use your own class loading code.
heu… what the interrest of using native code here ?
Sorry, rephrase the question please?
Also, i’ve updated it, it now crashes when a JVMTI agent is loaded.
why do you use a dll (native code) ?! I cant see any interrest in protecting the source code ?
using native code, it’s possible to apply detours or memory patches to the jvm itself, during runtime
I still dont get exacly how it work, the DLL modify the JVM memory at runtime to secure the jar that’s it ?
ps: sorry to say that but at very first view, it seems useless to do that except that you will create a lot of bugs/incompatibilty problems, I mean you cant prevent modification of the DLL itself for example
yeah it can be a little difficult to understand. basically, every native application on a computer stores memory. in this memory, there are variables, functions, objects, etc.
by modifying the memory where a function points to, you can force it to jump to a location effectively creating a hook, and by hooking for example JVM_GetManagement(), you can override what the function returns (think of it like an override in Java, except done at runtime by native code). By using these code hooks, you can actually use your own class formats in the JVM, provided you are able to hook the right functions.
protecting against jvmti was a little more difficult, it uses a codescan (kind of like what antiviruses use) to locate any loaded agents in the current module.