New technique to protect Java (NOT obfuscation) ?

[Bent C Dalager]

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 ...)

The usual case of this would be when you have only one customer (you
could be a defense contractor perhaps). I'm not so sure this is
enviable

Cheers
Bent D

 

[Mark Thornton]

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 ...)

That would be true if people didn't sell or otherwise pass on the
results of their cracking. In the absence of legal measures, if someone
wants ten copies it could be worth paying 5 times the single copy cost
to crack the software.

There is one bullet proof method of protection: include enough bugs that
any user has to have a support contract for the software to be
effective. Hmmm rather like a central server based system --- you have
to ring the support line to obtain the 'key' to advance to the next step!

Mark Thornton

 

[Brandon Blackmoor]

No, Bent C Dalager wrote that.

 

[David Zimmerman]

That could mean development only on Windows or run only on Windows.

It comes with a Solaris .so and the build process builds a shell script

 

[Joona I Palaste]

It is my (naíve) _hope_ that as the proportion of the population with

^^^^^
Spelling mistake: should be naïve.

"always online" access increases, security awareness will also
increase.

--
/-- 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! ------------/
"Ice cream sales somehow cause drownings: both happen in summer."
- Antti Voipio & Arto Wikla

 

[Koleho]

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.

You are right about that. That's why I posted my question in the
newsgroup in the first place, to get ideas of how to test this
JEncoder.

Regards,
Koleho

 

[Albert]

Is this JEncoder really does what it claims to ?

Why do you bother to test this JEncoder? Why don't you use obfuscation instead?

Just search for Java Obfuscator in Google.

 

[pete kirkham]

Why do you bother to test this JEncoder? Why don't you use obfuscation instead?

Just search for Java Obfuscator in Google.

Which of the obsfucators actually work?

Most seem to mangle symbol names, but since a (thankfully small) part of
my day job is porting from FORTRAN, they're a good deal less mangled
than a lot of the names I've seen in source code.

The better ones seem to add lots of gotos and branches on constant
tests. An optimising compiler will sort out such control flow logic and
remove the spurious tests, so such code should be able to be decompiled
using the same logic- run it through a bytecode optimiser first. If the
code control flow is sufficiently obscure to fox something of the same
complexity as the class loader or the JIT compiler, then either it won't
verify or it will have a performance hit.

Some encrypt string literals. That may cause some inconvenience to
crackers, as they'd have to call the decryption algorithm included in
the obsfucated class, so the process isn't entirely one of static analysis.

I'm toying with a bytecode optimiser as part of a high level language
compiler for the JVM, and as part of the plan for that language's
debugger is to include decompilation so that anything in the JVM can
then be stepped through as though you had the source code written in the
higher level language (not for cracking as the only Java apps I've seen
cute enough to be worth copying have been open source, such as BCEL, and
it's generally patterns that I copy, not code). When I get something
running I'll be curious how it copes with inspecting and optimizing
spagetti-ized code.


Pete

 

[Mark Lambert]

Anyone who went to the Java Performance Myths presentation at JavaOne will
never use an obfuscator again because of the performance hit they will get.
The JVM looks for common bytecode patterns in order to optimize and if the
patterns have been obfuscated....