[Cascavel-pm] Byte code compile parte 2
Alceu R. de Freitas Jr.
glasswalk3r em yahoo.com.br
Sexta Julho 25 07:21:19 CDT 2003
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.
--- 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
> to encrypt a perl script. I found it useful and
> you might too.
> Happy coding
> 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
> executes them is pretty simple. Take a look at the
> 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,
> which brings us to the more difficult part of the
> 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
> 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 *
> 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
> 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
> 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
> 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
> 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:
> # cryptbuild
> toke_cflags='ccflags="$ccflags -DCRYPTSCRIPT"'
> ttoke_cflags='ccflags="$ccflags -DCRYPTSCRIPT"'
> usersub_cflags='ccflags="$ccflags -DCRYPTSCRIPT
> export toke_cflags ttoke_cflags usersub_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
Conheça o novo Cadê? - Rápido, fácil e preciso.
42 milhões de páginas brasileiras, busca por imagens e muito mais!
Mais detalhes sobre a lista de discussão Cascavel-pm