Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (120)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  JarProtect test, bytecode encrypter  (Read 5169 times)
0 Members and 1 Guest are viewing this topic.
Offline Dx4

Junior Duke


Medals: 5



« Posted 2011-04-25 12:11:37 »

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
Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #1 - Posted 2011-04-25 12:45:22 »

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 have no special talents. I am only passionately curious.--Albert Einstein
Offline Dx4

Junior Duke


Medals: 5



« Reply #2 - Posted 2011-04-25 13:12:24 »

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
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #3 - Posted 2011-04-25 13:13:43 »

I don't have windows. Just linux. So don't bother on my account.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 816
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #4 - Posted 2011-04-25 13:15:17 »

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

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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Dx4

Junior Duke


Medals: 5



« Reply #5 - Posted 2011-04-25 13:18:38 »

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

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
Online kevglass

JGO Kernel


Medals: 188
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #6 - Posted 2011-04-25 14:31:58 »

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

Offline Abuse

JGO Knight


Medals: 13


falling into the abyss of reality


« Reply #7 - Posted 2011-04-25 14:51:07 »

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'  Stare

Provide a 64bit dll and i'll write it for you if you like.

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Dx4

Junior Duke


Medals: 5



« Reply #8 - Posted 2011-04-25 14:55:55 »

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'  Stare

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 Smiley

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

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:

1  
2  
3  
4  
5  
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
Offline Roquen
« Reply #9 - Posted 2011-04-25 17:47:03 »

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Abuse

JGO Knight


Medals: 13


falling into the abyss of reality


« Reply #10 - Posted 2011-04-25 18:41:27 »

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.

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Nate

JGO Kernel


Medals: 149
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #11 - Posted 2011-04-25 20:54:20 »

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:
http://www.codeproject.com/KB/library/ssdsdk.aspx
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. Smiley

Offline SimonH
« Reply #12 - Posted 2011-04-25 23:15:48 »

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.
Grin So true! Imitation is the sincerest form of flattery.

People make games and games make people
Offline Dx4

Junior Duke


Medals: 5



« Reply #13 - Posted 2011-04-26 04:02:54 »

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:
http://www.codeproject.com/KB/library/ssdsdk.aspx
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. Smiley

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.
Offline DzzD
« Reply #14 - Posted 2011-04-26 09:54:06 »

heu... what the interrest of using native code here ?

Offline Dx4

Junior Duke


Medals: 5



« Reply #15 - Posted 2011-04-26 14:05:28 »

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.
Offline DzzD
« Reply #16 - Posted 2011-04-26 20:32:35 »

heu... what the interrest of using native code here ?

Sorry, rephrase the question please?
why do you use a dll (native code) ?! I cant see any interrest in protecting  the source code ?

Offline Dx4

Junior Duke


Medals: 5



« Reply #17 - Posted 2011-04-27 08:23:29 »

heu... what the interrest of using native code here ?

Sorry, rephrase the question please?
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
Offline DzzD
« Reply #18 - Posted 2011-04-27 09:39:27 »

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

Offline Dx4

Junior Duke


Medals: 5



« Reply #19 - Posted 2011-04-27 09:44:18 »

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.
Offline DzzD
« Reply #20 - Posted 2011-04-27 09:54:50 »

ok tk, even if it still seems near useless for me in term of security I found the principe/idea of overriding the JVM is something really interresting

EDIT:
let me explain a little more why it is near usless for security : if one unassemble the DLL and modify it, it could for example modify the method that decrypt the encrypted class file to write them back on the harddisk (it may not work in this case but that's the idea)

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #21 - Posted 2011-04-27 10:23:18 »

he's just trying to make it harder - not bulletproof Smiley
but yeah, in the end, someone will just make a new jarprotect.dll that will spit out the actual decrypted bytes, and people will download that dll and replace yours.

Offline Roquen
« Reply #22 - Posted 2011-04-27 12:23:00 »

The real problem is now you have to build shared libs for every arch that you want to support AND reverse engineer each version of each JVM that you want to support (and bail for any unrecognized hash code as there are way too many potential points of attack).  That's a lot of work for very little gain.  And of course continuosly ongoing since, ya know, new VMs come out every once in a while.  If you really want to prevent cheating...server.
Offline Dx4

Junior Duke


Medals: 5



« Reply #23 - Posted 2011-04-28 03:09:06 »

he's just trying to make it harder - not bulletproof Smiley
but yeah, in the end, someone will just make a new jarprotect.dll that will spit out the actual decrypted bytes, and people will download that dll and replace yours.

the thing is even if they do spit out the 'decrypted' bytes, a typical decompiler will not be able to understand it, as it is in a different format to the official class file format, so people would also need to write a new decompiler specifically for this purpose. in future, I will add random instruction generation so each opcode that is decoded is random, making it even harder to write a decompiler that works for the format.

example:

LDC is usually encoded as 0x12, after random instruction generation, it could be 0x07, a typical Java decompiler only understands 0x12, therefore it would crash or error upon encountering an unexpected opcode. this will work because it is possible to hotpatch ClassFileParser::parseClassFile during runtime.
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #24 - Posted 2011-04-28 04:31:01 »

if you change input opcodes there is a certain possibility for modifying it in an invalid way. But that probably goes for all obfuscators.

it also sounds like you're working a lot with the existing hotspot code - which is GPL, so you are required to follow the license.

lastly, if you *really* want to have some degree of security, you should share the code, instead of relying on obscurity.

Offline Dx4

Junior Duke


Medals: 5



« Reply #25 - Posted 2011-04-28 04:57:02 »

if you change input opcodes there is a certain possibility for modifying it in an invalid way. But that probably goes for all obfuscators.

it also sounds like you're working a lot with the existing hotspot code - which is GPL, so you are required to follow the license.

lastly, if you *really* want to have some degree of security, you should share the code, instead of relying on obscurity.

using hotspot's source as a guide as to what payload code to write doesnt require me to follow the license, as i havent actually used the source itself. im simply using it as a guide to learn what functions to patch. it's similar to antiviruses hooking system routines (ZwOpenProcess, etc), although they use the winapi as a guide to learn what to hook, their software isn't required to abide by microsoft's license, as it doesnt actually use microsoft's code.

later i may opensource the project. right now, it would make it much easier to crack it if I did opensource it however. this isnt meant to be bulletproof - its only meant to give Java apps aorund the same degree of security as C/C++ apps have.
Offline CommanderKeith
« Reply #26 - Posted 2011-04-28 05:36:45 »

Neat ideas.

Do the internal hooks change much from JVM version to version, or even JVM operating system to operating system?

It would be pretty annoying to keep track of the changes if it did.

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #27 - Posted 2011-04-28 05:48:38 »

it also sounds like you're working a lot with the existing hotspot code - which is GPL, so you are required to follow the license.

using hotspot's source as a guide as to what payload code to write doesnt require me to follow the license, as i havent actually used the source itself. im simply using it as a guide to learn what functions to patch. it's similar to antiviruses hooking system routines (ZwOpenProcess, etc), although they use the winapi as a guide to learn what to hook, their software isn't required to abide by microsoft's license, as it doesnt actually use microsoft's code.
fair enough. I was just assuming you were re-writing large parts of parseClassFile, if not, then it would just be a matter of patching jvm.dll to output the bytes after it has been verified.

The general thought is, if you have an obfuscated class then at some point you need to de-obfuscate it and pass it into the VM, at that point we intercept the input and write it out. In your case, you made it harder by creating some native code, so a different skillset is required.

That said, however, its still relatively easy to thwart, if you have a reason for doing so (crackers etc).

Your method could also be very brittle, in that may rely on features not present in all VMs, including non-Oracle VMs.

Offline Dx4

Junior Duke


Medals: 5



« Reply #28 - Posted 2011-04-28 07:15:49 »

it also sounds like you're working a lot with the existing hotspot code - which is GPL, so you are required to follow the license.

using hotspot's source as a guide as to what payload code to write doesnt require me to follow the license, as i havent actually used the source itself. im simply using it as a guide to learn what functions to patch. it's similar to antiviruses hooking system routines (ZwOpenProcess, etc), although they use the winapi as a guide to learn what to hook, their software isn't required to abide by microsoft's license, as it doesnt actually use microsoft's code.
fair enough. I was just assuming you were re-writing large parts of parseClassFile, if not, then it would just be a matter of patching jvm.dll to output the bytes after it has been verified.

The general thought is, if you have an obfuscated class then at some point you need to de-obfuscate it and pass it into the VM, at that point we intercept the input and write it out. In your case, you made it harder by creating some native code, so a different skillset is required.

That said, however, its still relatively easy to thwart, if you have a reason for doing so (crackers etc).

Your method could also be very brittle, in that may rely on features not present in all VMs, including non-Oracle VMs.

1. obfuscated classes need not be de-obfuscated to be executed, in fact it should not be possible to deobfuscate a class. the whole point of obfuscation is to change a class so it is difficult to understand and so that the obfuscated class still works the same way regardless what VM it is loaded in.

2. to crack this type of protection, knowledge of many software concepts is required, including
  • hooking
  • memory patching
  • code injection
  • assembly, particularly low level machine shellcode

the general idea is that it hotpatches ClassFileParser::parseClassFile during runtime in order to be able to make classes out of my own class formats (not the same formats Sun/Oracle uses or has documented), so thereotically, as long as i am able to write a parser for a particular format, i could make class files in whatever format i wanted to. because it also doesnt use the JVM's default classparser, i can also invent new instructions, etc, as long as the injected code could convert these new instructions back into jvm instructions, although i havent tried this yet. my next idea is to make the software generate random opcodes for each instruction, so even if you did get the bytecode you couldnt load it into a decompiler as the decompiler would not recognize the opcodes.

Neat ideas.

Do the internal hooks change much from JVM version to version, or even JVM operating system to operating system?

It would be pretty annoying to keep track of the changes if it did.

Doing a little reverse engineering of previous JVM versions and matching them to hashes during runtime should be all i need to be able to patch previous versions too; however i havent done this yet.

Actually, by including a disassembler in my dll and scanning for the right calls, i should be able to find the required addresses dynamically
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #29 - Posted 2011-04-28 09:29:40 »

2. to crack this type of protection, knowledge of many software concepts is required, including
  • hooking
  • memory patching
  • code injection
  • assembly, particularly low level machine shellcode
No, unless I am misunderstanding what your stuff does, then whatever format you make up, has to end up as PROPER bytecode at some point, else the VM cannot "run" it.
At that point, you intercept - using your modified VM - and dump the bytes.

Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (52 views)
2014-10-17 03:59:02

Norakomi (43 views)
2014-10-16 15:22:06

Norakomi (33 views)
2014-10-16 15:20:20

lcass (37 views)
2014-10-15 16:18:58

TehJavaDev (68 views)
2014-10-14 00:39:48

TehJavaDev (66 views)
2014-10-14 00:35:47

TehJavaDev (59 views)
2014-10-14 00:32:37

BurntPizza (73 views)
2014-10-11 23:24:42

BurntPizza (45 views)
2014-10-11 23:10:45

BurntPizza (85 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!