Perl protection and the demise of B::Bytecode

I want B::Bytecode for using Perl 5 as a backend for other languages
without having to generate Perl first, so maybe I'll fix it. Some
day.
-scott

I want B::Bytecode for using Perl 5 as a backend for other languages
without having to generate Perl first, so maybe I'll fix it. Some
day.
-scott

PGP SIGNED MESSAGE
Hash: SHA1

Moin,

Wednesday 01 November 2006 06:13, you wrote:
In some cases, by "stripping" the code you justmake it easier to read.
For the machine:

use constants INCREMENT =2;
$counter += INCREMENT;# increment our counter

and

$aa += 2;

are the same, and for someone trying to understand what the code does,
the second variant is probably even easier. Less junk to wade through.

Here is perhaps a better example.

EVIL
# I'm explaining this earlier than I should so you can understand
# why I'm about to do something that looks very strange. There's
# a problem with the Tokenizer, in that tokens tend to change
# classes as each letter is added, but they don't get allocated
# their definite final class until the "end" of the token, the
# detection of which occurs in about a hundred different places,
# all through various crufty code (that triples the speed).

I am pretty sure that this scheme just adds complexity to your program,
slows it down, and then breaks for the normal customer (like when running
some obscure Perl version). The various DRM schemes are all showing us how
these just hassle the normal running of the programm and don't slow any bad
guy down anyway.

Hell, most unprotected programs are hard to get to run, run properly, or
even do what the author intended them to do.

custom schemes:

There is a fundamental difference between cooking your own scheme, that
might slow down the guys for the nec. time. ( not. Have you more time to
invent protections and tricks as they have to circumvent them? Can you
compete with thousand bored teenages? I know I lost that game long ago)

you use one of the pre-made things (like packing Perl into a binary). If
it is used on more than one app, the scheme might get broken just because
someone cracked a high-profile app, and got yours for free. (see things
like safedisk for games)

Just packing Perl into a binary amounts to the second varity.

[snip]

The some goes for "optimized away" sections. Gone? Good riddance, I
don't need to analyse them if they aren't used anyway. Etc.

But at least now you can't see all the debugging statements that
describe what the code is doing in more detail and have to wade through
5,000 lines of code.

If you have good comments and good debugging statements, they *might* help.
distract. If you program is so hairy that you can't understand it by
watching what the program does when running live, chances are it is so
hairy that the original author didn't understand what what it does,
either :-)

I find generall that the most-proteced code is also the crappiest :)

As from someone who did wade through enough code on pretty low-level
stages (pls don't ask), I can tell you that the only way to secure your
code is to encrypt it *and* then store the decryption key in a _very_
safe place where no-one except the CPU executing the code can get at it
(yes, that means in the hardware).

In all other cases, young and very talented Igor from Russia[0], living
on 100gr Vodka a day, will break whatever clever scheme you devise
shortly after breakfast.

Fortunately, not every single company in the world can hire Igor at the
same time.

The don't hire him, he breaks their programs anyway. If you ever searched
for serialz, or anything related to that you'll see that you can get almost
every program in a "more open"[tm] fashion, except maybe the ones that are
so crappy that no-one wants them. This also applies to high-profile apps
like I-Tunes etc.

There's a very significant difference between making a security
algorithm safe because once Igor has cracked it he can distribute that
crack to people that are interested, and wanting to make it economically
infeasible for one or two specific competitors of a single company to
clone their product.

I'm not suggesting that this protection applies to the former case, but
by applying various protections, you can significantly increase the
economic barriers to having your code copied.

That's what much of this protection talk is about.

That, I think is a very valid point and much of the discussion always neatly
sidesteps, both from the "you cant protect it anyway" crowd and the "I
wanna" authors.

Whats usual missing is a risk analysis, aka:

* how much does the protection cost to add
* to maintain it?
* to support it?
* how much will it save?
* what is the intended goal of it?
* how long does the protection need to hold up to be effective
* and how many customers cant/want no longer use the program due to it

etc.

However, just looking at high-profile things like games, you can see that
their protections are broken anyway, are often harmfull (starforce driver),
or do plain not work at all (like safedisk protected games run readily
under my linux system without ever noticing that something is "not right"
with the S they run on).

What I am saying is that whatever protection you add might not be worth it
in practice both from the cost, and from the benefit side. Especially if
you just package your Perl into a binary blob.

YMMW, of course :)

Best wishes,

Tels

- --
Signed on Wed Nov 1 09:58:11 2006 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.

"The rovers Spirit and were proposed, authorized, announced,
designed, launched and successfully landed upon Mars within the
timeframe of Duke Nukem Forever's development." - Unknown

PGP SIGNATURE
Version: GnuPG v1.4.2 (GNU/Linux)

=lv9j
PGP SIGNATURE