«

In article <>,
Eric Sosman <> wrote:
>
> 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
--
Bent Dalager - - http://www.pvv.org/~bcd
powered by emacs

Eric Sosman wrote:

> Roedy Green wrote:
>
>>On Fri, 18 Jul 2003 13:54:59 -0400, Brandon Blackmoor
>><> wrote or quoted :
>>
>>
>>>>I seriously doubt they've found a bullet-proof way
>>>>of securing the bytecode.
>>
>>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 ...)
>

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

Roedy Green wrote:

> On Fri, 18 Jul 2003 13:54:59 -0400, Brandon Blackmoor
> <> wrote or quoted :
>
>>> I seriously doubt they've found a bullet-proof way
>>> of securing the bytecode.

No, Bent C Dalager wrote that.

Roedy Green wrote:
> On Fri, 18 Jul 2003 12:17:24 +0100, Nigel Wade <>
> wrote or quoted :
>
>
>>>Its platform requirements specify it's for Windows only, so I won't be
>>>bothering.
>>>
>>
>
> 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

Bent C Dalager <> scribbled the following:
> In article <bf9lug$cmbpi$>,
> Mark Thornton <> wrote:
>>
>>Ah an optimist. Most of my colleagues can only dream of high speed
>>access (at home).

> 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 () ---------------------------\
| 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

Bent C Dalager wrote:

> 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

(Koleho) wrote:

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

Albert wrote:
> 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

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