[Cascavel-pm] Byte code compile parte 2

[Alceu R. de Freitas Jr.]

Eu nunca compilei o Perl através dos fontes, mas isso
daria algum howto.

Alguém poderia escrever algo? Eu posso ajudar com a
formatação do trabalho (ao menos isso) e quem sabe
realizar alguns testes.

[]´s
Alceu

 --- Christian Reichel <chrisreichel em bol.com.br>
escreveu: > Ola amigos de novo!
> 
> Olha o que eu achei, pode ser de agrado de alguns.
> 
> Here is a repost of a message from John Macdonald on
> how
> to encrypt a perl script.  I found it useful and
> thought
> you might too.  
> Happy coding
> Marc
> edgarm em rpi.edu
> 
> Re-Printed with permission of the authors.
>
______________________________________________________________
> Marc Edgar wrote :
> || 
> || Greetings,
> || 
> || I read your replies about protecting commercial
> Perl code
> || with great interest.  Could you tell me where I
> can learn how
> || to do this?
> || 
> || Many thanks.
> || Marc Edgar
> || edgarm em rpi.edu
> 
> There are two parts involved in doing this.
> 
> Building Perl with the ability to decrypt scripts as
> it
> executes them is pretty simple.  Take a look at the
> Perl
> source files: perl.h toke.c and usersub.c
> and look for the use of the manifests CRYPTSCRIPT
> and CRYPTLOCAL.
> The first two files, perl.h and toke.c, need no
> change on your
> part - you just have to make sure that toke.c gets
> compiled with
> the option -DCRYPTSCRIPT.  The significant part is
> in usersub.c.
> If you compile it with -DCRYPTSCRIPT, then it will
> compile in a
> very simple decryption routine - every byte has the
> top bit
> flipped, which for normal ascii text means that it
> is turned on.
> This encryption scheme is not very hard to crack,
> obviously,
> which brings us to the more difficult part of the
> job.
> 
> The hard part is choosing an encryption algorithm
> that is strong
> enough for your needs.  Then you would write a piece
> of C code
> and put it into a file called cryptlocal.h and
> encure that you
> compile usersub.c with the options -DCRYPTSCRIPT
> -DCRYPTLOCAL.
> Your cryptlocal.h file must do two things - it must
> define the
> manifest constants CRYPT_MAGIC1 and CRYPT_MAGIC2 and
> it must
> provide a subroutine cryptfilter which takes FILE *
> argument,
> reads in the remainder of that file, and decrypts
> it.  (If you
> look in usersub.c at what happens if CRYPTLOCAL is
> not defined,
> it gives you a template for what your code in
> cryptlocal.h must
> look like to usersub.c when it gets included.  You
> would also
> have to write a separate program that takes a
> script, copies
> some portion of it without encrypting (like the
> leading #! line
> for instance) and then write out the two CRYPT_MAGIC
> characters
> and then write out the rest of the script in
> encrypted form.
> The code in usersub.c already provides the
> cryptswitch function
> called from toke.c - its job is to check for the
> CRYPT_MAGIC
> characters and if they are found, fork off a process
> to run
> your cryptfilter subroutine to decrypt the rest of
> the input
> file.  It prevents an obvious security breaking
> trick by just
> quiting if debugging it turned on.  I won't
> guarantee there
> aren't any other holes that would allow somebody to
> break the
> security without applying crypto-analysis to the
> encrypted
> scripts - in fact, I am certain that it can be done.
>  So, if your
> scripts are going to be worth millions of dollars to
> someone who
> breaks the encryption, then you probably should
> consider going
> a different route.  However, given a good choice of
> encryption
> algorithm, this mechanism provides a fairly good
> barrier to
> reading your scripts.
> 
> The reason I chose such a trivial encryption routine
> to be the
> standard one included in the Perl distribution is
> that the routine
> in the distribution is publicly readable code and
> vulnerable to
> analysis by many people.  If there was a "pretty
> good" routine
> provided, then many people might choose to use it. 
> It is a lot
> more tempting for a cracker to spend some time
> trying to break
> a code for which he has the source and which he
> knows is going to
> be used by many people, than it is for him to try
> and break a code
> that he doesn't have source to and which is
> different from the
> code used by any other organization.
> 
> By the way, Larry has some neat tools to support the
> make procedure
> that lend themselves really well to supporting this
> sort of addition.
> 
> If you have a script that looks like:
> 
>     #!/bin/sh
>     # cryptbuild
>     toke_cflags='ccflags="$ccflags -DCRYPTSCRIPT"'
>     ttoke_cflags='ccflags="$ccflags -DCRYPTSCRIPT"'
>     usersub_cflags='ccflags="$ccflags -DCRYPTSCRIPT
> -DCRYPTLOCAL"'
>     export toke_cflags ttoke_cflags usersub_cflags
>     ./cflags
>     make $*
> 
> then to have your own ready to go Perl source, you
> just take the
> standard Perl source, and add this script (call it
> cryptbuild) and
> the file cryptlocal.h that you made before.  When
> you are ready to
> build Perl on your customer's site, copy on that
> source tree and
> then whenever your would have typed "make something"
> you just use
> "cryptbuild something" instead.  For example,
> 
>     cryptbuild depend all test
> 
> When you have finished compiling Perl, you just
> remove the cryptlocal.h
> file and the usersub.o module and you can leave the
> rest of the source
> behind for your customers to use as they wish.
> > _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em mail.pm.org
> http://cascavel.pm.org/mailman/listinfo/cascavel-pm
>  

_______________________________________________________________________
Conheça o novo Cadê? - Rápido, fácil e preciso.
42 milhões de páginas brasileiras, busca por imagens e muito mais!
http://www.cade.com.br