I was exploring the Java VM for vulnerabilities, for reasons I won't disclose, I've found that Java 9 (possibly could be done in Java 8) allows me to do memory manipulation completely bypassing the "Java" language itself.
How it works:
When a method is called, it's decrypted using a super fast encryption algorithm on the fly, which means that when the code is dumped, the chances of the code being decrypted are nearly zero, plus, the code itself is forced to be "optimized" by the JVM which makes it even harder to access by normal means (heap dumps).
Decompiled code would look something like:
When the code is run, this is what it would actually look like:
That tag would indicate a special injection to fetch and run an injected method on the fly to run with arguments that are in methods stack (method arguments).
Result?
All the java programs code would be encrypted until it needs to be run. This would make deobfuscation impossible and cracking infeasible, as it would just take too much time and effort, especially for larger projects.
Can't the "Encrypt" class be deobfuscated?
No, as the reference in the heap is destroyed as soon as it's loaded, it is easier to find and dump than protected code, locating the key for encryption is nearly impossible as it's calculated on the fly. Currently any new loaded code causes the JVM to crash, however, this can be fixed by temporary restoring the class reference.
The cost?
Surprisingly the performance loss is minimal as bypassing boilerplate and overhead of the Java language makes the entire process REALLY fast. Faster than most obfuscation methods.
What does this break?
Multithreading WILL cause the JVM to crash, run the wrong method, etc, could be fixed in future versions though, as it stands right now, it just crashes.
Memory manipulation in java?
Unsafe.
Why are you on mc-market?
The same reason for the auctions I made, I can easily reach out to many people, and since there is quite a bit market of development services here, I just want to know if there is actual demand for it, obviously if proven successful, I would obviously deploy this on a much larger scale to compete with bigger entities on the market.
Pricing model?
Most likely a license fee, the said product is sold for 10$ for example, by discussion, anywhere from 1% to 5% would be taken for protecting the said product from piracy/cracking/nulling, licenses would be bought in bulk.
How it works:
When a method is called, it's decrypted using a super fast encryption algorithm on the fly, which means that when the code is dumped, the chances of the code being decrypted are nearly zero, plus, the code itself is forced to be "optimized" by the JVM which makes it even harder to access by normal means (heap dumps).
Decompiled code would look something like:
Code:
Encrypt.create(123L);
When the code is run, this is what it would actually look like:
Code:
Factory.a();//arguments from the method are grabbed from the stack by using an exploit, which isn't fixed in Java 11, and probably never will as it poses no security risks.
Encrypt.destroy(123L);
That tag would indicate a special injection to fetch and run an injected method on the fly to run with arguments that are in methods stack (method arguments).
Result?
All the java programs code would be encrypted until it needs to be run. This would make deobfuscation impossible and cracking infeasible, as it would just take too much time and effort, especially for larger projects.
Can't the "Encrypt" class be deobfuscated?
No, as the reference in the heap is destroyed as soon as it's loaded, it is easier to find and dump than protected code, locating the key for encryption is nearly impossible as it's calculated on the fly. Currently any new loaded code causes the JVM to crash, however, this can be fixed by temporary restoring the class reference.
The cost?
Surprisingly the performance loss is minimal as bypassing boilerplate and overhead of the Java language makes the entire process REALLY fast. Faster than most obfuscation methods.
What does this break?
Multithreading WILL cause the JVM to crash, run the wrong method, etc, could be fixed in future versions though, as it stands right now, it just crashes.
Memory manipulation in java?
Unsafe.
Why are you on mc-market?
The same reason for the auctions I made, I can easily reach out to many people, and since there is quite a bit market of development services here, I just want to know if there is actual demand for it, obviously if proven successful, I would obviously deploy this on a much larger scale to compete with bigger entities on the market.
Pricing model?
Most likely a license fee, the said product is sold for 10$ for example, by discussion, anywhere from 1% to 5% would be taken for protecting the said product from piracy/cracking/nulling, licenses would be bought in bulk.
Last edited: