New technique to protect Java (NOT obfuscation) ?

[Koleho]

Hello,

This company (http://www.new-era-soft.com) claims they have a new
method to protect Java against de-compilation, and it is NOT
obfuscation.

Has anyone tried their product yet ?

What do you think about it ?

What tests can I do to check if it is really good ?

Thanks.

 

[Bent C Dalager]

What do you think about it ?

Since they obviously dare not suggest what, exactly, they are doing,
my immediate guess is that they're full of crap.

What tests can I do to check if it is really good ?

Create a very simple application (one trivial class file for instance)
that you encrypt with their tool and then start looking into what they
actually do. Most probably, they just encrypt the class file and then
install a custom ClassLoader to decrypt it. If so, then find the
bootstrap ClassLoader they use to decrypt their own library (if they
require you to distribute such a library for your app to work) or find
the one they added to your app to decrypt your own class files.
Decompile that class to start finding out what they do. Chances are
this will eventually lead you to the algorithm they are using, which
should let you decrypt everything else at your leisure.

At best, they have made considerable effort to make it difficult for
you to find out what's actually going on. I seriously doubt they've
found a bullet-proof way of securing the bytecode.

Cheers
Bent D

 

[Chris Smith]

[Snipped non-existent group comp.lang.java.developer]

Hello,

This company (http://www.new-era-soft.com) claims they have a new
method to protect Java against de-compilation, and it is NOT
obfuscation.

Has anyone tried their product yet ?

What do you think about it ?

It's good for a laugh or two. I just love it when someone takes
something that can be absolutely proven to be impossible and plays the
"us versus them" card by saying "they say it can't done, but we did it
anyway!" This generally indicates one of three things:

1. The speaker is trying to trick you.
2. The speaker really doesn't understand the problem they "solved".
3. The speaker is God, so rules of logic don't apply.

Perhaps you should ask them which one is the case?

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Koleho]

Since they obviously dare not suggest what, exactly, they are doing,

my immediate guess is that they're full of crap.

That was my initial thought, and that's why I was surprised when I
failed to break into their encryption.

I already tried the following:
1) I ran the encrypted application with EVENT_CLASS_LOAD_HOOK, in
order to dump the classes there, and failed.
2) I altered the method
java.lang.ClassLoader.defineClass(ProtectionDomain ...) to dump the
classes there, and also failed.

Create a very simple application (one trivial class file for instance)
that you encrypt with their tool and then start looking into what they
actually do. Most probably, they just encrypt the class file and then
install a custom ClassLoader to decrypt it.

I already created an encrypted application (as you suggested).
The encrypted application consists of a dll file, and a jar file
containing entries that are probably my encrypted class files + an
additional class which has practically nothing in it (only a main
method which is calling a native method).

My idea is that they are doing the loading of the classes from the
dll, but even so, they must use some ClassLoader that is not
encrypted, and I couldn't even see that class.

If so, then find the
bootstrap ClassLoader they use to decrypt their own library (if they
require you to distribute such a library for your app to work) or find
the one they added to your app to decrypt your own class files.

I could not find any custom ClassLoader, but still it is impossible
that they are using the default (system) ClassLoader.

Decompile that class to start finding out what they do. Chances are
this will eventually lead you to the algorithm they are using, which
should let you decrypt everything else at your leisure.

I didn't succeed in decompiling anything besides the main class they
added to my encrypted application, which has practically no content.

At best, they have made considerable effort to make it difficult for
you to find out what's actually going on. I seriously doubt they've
found a bullet-proof way of securing the bytecode.

I also had serious doubts about that product, but I am already trying
for some time now to decompile a test application that I encrypted
with this product and till now, failed.

I have already seen some products that suggested java code encryption
in the past, and succeeded in breaking them in no time.
This JEncoder seems to work surprisingly different.

Is this JEncoder really does what it claims to ?

Regards,
Koleho.

 

[Chris Uppal]

I already created an encrypted application (as you suggested).
The encrypted application consists of a dll file, and a jar file
containing entries that are probably my encrypted class files + an
additional class which has practically nothing in it (only a main
method which is calling a native method).

My idea is that they are doing the loading of the classes from the
dll, but even so, they must use some ClassLoader that is not
encrypted, and I couldn't even see that class.

Perhaps they are using the JNI function DefineClass() to inject the decrypted
byecode directly into the JVM.

IIRC, the Sun and IBM JVMs allow a NULL classloader parameter to that function,
so the class is actually loaded (I guess) by the primordial classloader. I
have no idea whether that would bypass the debugging hook (or, indeed, whether
using the default class loader in this way would trigger the hook), but it
sounds possible.

One indication would be that their encrypted classes don't work properly with
with the BEA JRockit JVM which (at least up to V7) seems not to allow a NULL
classloader for the DefineClass() function.

Incidentally, if that *is* what they are doing, then setting up a "fake"
jvm.dll that forwards the API to a real JVM, but also collects the decoded
bytecode, would be an attack on their system. Off the top of my head, I can't
think of a defense against that. (Or they may be using JNI to inject a
decrypting classloader into the JVM instead, or as well, which would make it a
little more awkward.)

-- chris

 

[Harald Hein]

This company (http://www.new-era-soft.com) claims they have a new
method to protect Java against de-compilation, and it is NOT
obfuscation.

You work for them, don't you?

 

[Joona I Palaste]

Hello,

This company (http://www.new-era-soft.com) claims they have a new
method to protect Java against de-compilation, and it is NOT
obfuscation.

Has anyone tried their product yet ?

What do you think about it ?

What tests can I do to check if it is really good ?

Thanks.

Its platform requirements specify it's for Windows only, so I won't be
bothering.

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"A bicycle cannot stand up by itself because it's two-tyred."
- Sky Text

 

[Bent C Dalager]

That was my initial thought, and that's why I was surprised when I
failed to break into their encryption.

I already tried the following:
1) I ran the encrypted application with EVENT_CLASS_LOAD_HOOK, in
order to dump the classes there, and failed.
2) I altered the method
java.lang.ClassLoader.defineClass(ProtectionDomain ...) to dump the
classes there, and also failed.

First, please keep in mind that I have next to no domain knowledge
when it comes to classloading and the native API so will be stabbing
around in the dark for a bit. Always fun, that

I take it you have some experience with breaking into bytecode
encryption schemes. Still, I would ask if the techniques you have
tried are those that they suggest themselves. I would guess that of
all the various ways of breaking in (or trying to), they will have
listed the ones they know they are bullet proof against and omitted
any they could think of that might threaten them.

I already created an encrypted application (as you suggested).
The encrypted application consists of a dll file, and a jar file
containing entries that are probably my encrypted class files + an
additional class which has practically nothing in it (only a main
method which is calling a native method).

In very basic terms then, isn't what they are doing simply to write
their classloader in a more obscure language than Java (i.e.,
deliberately obfuscated C) and trusting this to become an unbreakable
barrier? It would certainly have a higher threshold than Java
bytecode, but still not bullet proof of course.

I don't really know what native code could do to the VM in the way of
class loading, Java thread starting etc.

My idea is that they are doing the loading of the classes from the
dll, but even so, they must use some ClassLoader that is not
encrypted, and I couldn't even see that class.

Would a DLL-based native class loader be easy for you to spot?

Did you try decompiling the DLL, or did you study its assembly?

Cheers
Bent D

 

[Roedy Green]

In very basic terms then, isn't what they are doing simply to write
their classloader in a more obscure language than Java (i.e.,
deliberately obfuscated C) and trusting this to become an unbreakable
barrier? It would certainly have a higher threshold than Java
bytecode, but still not bullet proof of course.

They must decrypt it to Java byte code inside their custom
classloader. The key to cracking their scheme is to replace that
customclassloader with one that makes a side decrypted copy of the
byte code for you to disassemble. Even if they use 128 bit
encryption, they are vulnerable to that sort of attack.

They may have written their custom class loader natively to make it a
harder to crack.

The problem with all these schemes is that the CPU has to capable of
decrypting to run the code. Therefore a patient hacker in principle
can too.

With the internet, I would expect protection schemes that requires an
outside connection periodically during execution. They can be orders
of magnitude more fiendish.

I think people waste far too much time trying to protect "secrets"
from hackers. A clone written from a spec would be easier to write
and maintain than one hacked by disassembling.

To protect from stealing, I think the trick is to customise the
product and preconfigure it before giving it to the customer. He can
make all the copies he wants. That require frequent updates.

If you don't want to go to all that work, require server involvement
to customise.

The proper solution is to rent rather than sell software. Peter
Norton ripped be off "selling" me SystemWorks 2001, not telling me it
would stop working in 2003 and he would do nothing about it. It would
have been more honest to rent me the software for 2 years.


see http://mindprod.com/projprebrandedsoftwarerental.html

 

[Ingo Pakleppa]

That was my initial thought, and that's why I was surprised when I
failed to break into their encryption.

I already tried the following:
1) I ran the encrypted application with EVENT_CLASS_LOAD_HOOK, in order
to dump the classes there, and failed. 2) I altered the method
java.lang.ClassLoader.defineClass(ProtectionDomain ...) to dump the
classes there, and also failed.


I already created an encrypted application (as you suggested). The
encrypted application consists of a dll file, and a jar file containing
entries that are probably my encrypted class files + an additional class
which has practically nothing in it (only a main method which is calling
a native method).

My idea is that they are doing the loading of the classes from the dll,
but even so, they must use some ClassLoader that is not encrypted, and I
couldn't even see that class.

I haven't looked at it, but maybe the classloader is implemented in the
DLL as a native method, and the additional class that has practically
nothing in it is the classloader?

 

[Joseph Millar]

Incidentally, if that *is* what they are doing, then setting up a "fake"
jvm.dll that forwards the API to a real JVM, but also collects the decoded
bytecode, would be an attack on their system. Off the top of my head, I can't
think of a defense against that. (Or they may be using JNI to inject a
decrypting classloader into the JVM instead, or as well, which would make it a
little more awkward.)

They are using an internal classloader. But your suggestion will
work, just front end JVM_DefineClass in jvm.dll. I popped a test
app into the msdev debugger and put a break point into JVM_DefineClass
and voila, the fourth entry into this function is the main class
of my test app. Following the buffer pointer leads me to the
plaintext bytecode of my class. It took me all of an hour or so
to find the plain bytecode.

Another approach that will work is to make some custom mods to the
JVM_DefineClass function using the JVM source code (which is free
to everyone). On entry just dump the bytecodes out to a file and
run through a decompiler. Very simple to do and you have a
custom JVM made for cracking this encryption scheme.

--Joe

 

[Nigel Wade]

Its platform requirements specify it's for Windows only, so I won't be
bothering.

Quite.

If you want your code to only be run on Windows why were you writing in Java
in the first place?

 

[Bent C Dalager]

If you want your code to only be run on Windows why were you writing in Java
in the first place?

Are you saying that multi-platform capability is Java's only redeeming
feature?

Cheers
Bent D

 

[Brandon Blackmoor]

I seriously doubt they've found a bullet-proof way
of securing the bytecode.

Which is a specious goal to begin with.

 

[Bent C Dalager]

Which is a specious goal to begin with.

Well, someone with more confidence than I would have pointed out that
it's fundamentally impossible, sans some custom hardware within your
computer working the deencryption magic very close to the CPU.

And even then, it would only be unbreakable so long as electron
microscopes are beyond the budget of the average cracker

Cheers
Bent D

 

[Roedy Green]

It never has to be bulletproof, just more costly to break than
reproducing the code from scratch.

The ultimate way to keep out hackers is to keep some of the code on
the server, never inspectable by the hacker. This requires a reliable
high speed link for all your customers. We are almost there.

For some sorts of calculation, you might even be able to do it faster
that way.

I have written about techniques to drive hackers mad trying to defang
your protection. See http://mindprod.com/jgloss/obfuscator.html

 

[Mark Thornton]

It never has to be bulletproof, just more costly to break than
reproducing the code from scratch.

The ultimate way to keep out hackers is to keep some of the code on
the server, never inspectable by the hacker. This requires a reliable
high speed link for all your customers. We are almost there.

Ah an optimist. Most of my colleagues can only dream of high speed
access (at home).

Mark Thornton

 

[Roedy Green]

Incidentally, if that *is* what they are doing, then setting up a "fake"
jvm.dll that forwards the API to a real JVM, but also collects the decoded
bytecode, would be an attack on their system.

These poor locksmiths. They build magnificent locks and fail to
consider all the ways around the lock.

I remember the look of dreadful embarrassment when a team came to
demonstrate their uncrackable encryption of user files to our PC user
group. I cracked it in a few minutes by guessing they had failed to
wipe the original user file after encryption.

 

[Eric Sosman]

It never has to be bulletproof, just more costly to break than
reproducing the code from scratch.

No, it only needs to be more costly than the cost of
paying for the program. (If you're able to charge more for
the program than it cost to write, you've got an enviable
business model ...)

 

[Roedy Green]

Are you saying that multi-platform capability is Java's only redeeming
feature?

it is the source of most Java virtue. Multiplatform helps peel off
silly barnacles.

Java tends to do things is a straightforward way.