PGP SIGNED MESSAGE
Hash: SHA1
Moin,
Adam Kennedy wrote:

>People seem to want to "protect" their code.
>
>Absolutely. I have a current client that has actually had their code
>"stolen" in the past and had their product cloned by a competitor in a
>different country, and so now care deeply about protecting their code.
You should be honest and tell them "Security by " doesn't work. :)

>1: Are there any existing products that "protect" Perl code, given that
>B::Deparse, B::Deobfuscate and C level breakpoints on the Perl
>interpreter
>exist?
>
>That depends. There are various strategies available, that work in
>differing areas of protection.
>
>The Perl::Squish module I wrote to demonstrate PPI document
>transformation is a fairly good example for attacking the problem from
>the direction of information removal.
>
>It strips out the comments, PD and compresses the whitespace down to a
>minimum. You can also do some other forms of protection, for example by
>making sure the unit tests after you install the code.
>
>There's some other strategies you could use of this type. After
>stripping docs, the next lowest-hanging fruit would probably be the
>randomization of the lexical variable names.
>
>And of course, you rerun the unit tests after the changes to verify the
>change was ok.
>
>All of these things don't prevent recovery entirely, but they help
>prevent an attacker extracting meaning from the code.
You do seem to assume that doc, comments and original names actually add
"meaning" to the code. :)
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.
The some goes for "optimized away" sections. Gone? Good riddance, I don't
need to analyse them if they aren't used anyway. Etc.
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.
Admittely, storing your code in JAPHs would make it tough to get it's
meaning from it - but not impossible at all - not to speak of the
maintainance nightmares this all creates. :)
Best wishes,
Tels
0: Nothing against young and talented, or otherwise, Russians, with or
without vodka. I wish I was as talented! Go, look up Ilfak Guilfanov.
- - --
Signed on Mon 30 19:43:28 2006 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
", a shiny copper piece to the first person who can tell me why Elan
is running around naked." - "Giant moth attack?" - "Maybe a bad guy
casted 'Dispel clothes'?" - The of the Stick issue #26
PGP SIGNATURE
Version: GnuPG v1.4.2 (GNU/Linux)
=e9rJ
PGP SIGNATURE

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