Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Security, is it to much to ask?

by tachyon (Chancellor)
on Jul 17, 2001 at 05:50 UTC ( [id://97234]=perlmeditation: print w/replies, xml ) Need Help??

chinman had a problem, he had compiled his source code using PerlApp from Active State then lost the source code. Thus at this node PerlApp decompile? he asked the wisdom of the monks to retrieve his perl code from the .exe source. OK so after establishing his ownership of the code a simple decompile gets you the perl source which as it turns out is encoded. Great AS are looking after security by encoding the embedded code. As it turns out this encoding is a simple XOR against the string 'Copyright © 2000 ActiveState Tool Corp.' as noted by c-era at A real challenge Amazing. It would have been trivial to XOR against a randomly generated (and long) string and then embed this string in some obscure location (or locations) of the exe generated by PerlApp so that each .exe has a unique key making the decompile orders of magnitude harder as you would have to actually disassemble it in detail to find the hidden key.

<BEGIN_RETORICAL_QUESTION>Why even bother if you are not going to make some sort of realistic effort to secure the source code?<END_RETORICAL_QUESTION> Is that to much to ask from a commercial application? It's no wonder merlyn says the security of these apps (usually perl2exe) stinks. It does. If anyone here has contact with AS perhaps you could suggest they might like to fix this security hole.




Replies are listed 'Best First'.
Re: Security, is it to much to ask?
by MeowChow (Vicar) on Jul 17, 2001 at 08:09 UTC
    Any algorithim implemented in the PerlApp executable could be reverse-engineered by a competent cracker with a low-level debugger, probably in a matter of hours, because PerlApp must decrypt the cyphertext into plaintext in order to execute it. ActiveState decided to keep it simple, and obscured things from the view of a casual user. It wouldn't make much difference either way, except that in the former case, chinman would have had a much harder time restoring his original source.
                   s aamecha.s a..a\u$&owag.print
(ichimunki)Re: Security, is it to much to ask?
by ichimunki (Priest) on Jul 17, 2001 at 22:47 UTC
    I feel compelled to chime in.

    First, encrypting the code is not security the way I usually think of security, it is copy protection at best and security through obscurity at worst. Encrypted code will not prevent crackers from cracking holes in your security methods. And apparently this copy protection is a little flimsy.

    That said I would point out MeowChow's comment that this entire discussion probably* violates the DMCA, in that Monks have discussed the method by which copy protection can be removed from software. In spite of the fact that chinman created this software, he/she does not own the encryption technique, nor do Monks (as third parties in this activity) have any right to break the encryption for him/her. Certainly discussing the methods by which copy protection can broken are forbidden under law, and this is why a Russian hacker was arrested recently in Las Vegas, and why Eric Corley of 2600 is involved in his lawsuit with the MPAA.

    Recalling the enormous stink made about DeCSS in Perl (and its summary deletion from the site by editors), one does wonder why this discussion is here. :)

    *added probably, I am not a lawyer.

      Hi. Fist I don't intend to say TOO much :-) If I could have edited the title to fix it I would have. If I hadn't thought it trivial I would have bugged an editor.

      I am not and have never been a cracker although I am familiar with the techniques of decompiling and with x86 assembler. Before posting the original response I considered the issues of whether chinman was the rightful owner of the intellectual propertry (his scripts) embedded within the .exe generated by PerlApp. Having established to my satisfaction that this was indeed the case I simply greped his scripts out of the exe using a standard method. I did this with the full consent of the owner of the aforementioned scripts. I did not 'reverse engineer' anything, nor was this required. The scripts are plainly identified and easily removed.

      The scripts thus reclaimed represented chinman's intellectual property not Active State's. The fact that they were encoded hindered his right to access his own intellectual property. Despite requesting help from Active State they are yet to send so much as an autoresponder message.

      The encoding scheme utilised XOR against a key string to generate a simple symetric key shift cipher. This type of cipher was first described by Blaise De Vigenère (1523-1596) so is probably no longer subject to patent issues :-) This type of cipher is a just a glorified caeser shift cipher and can be broken using a number of techniques. Using XOR in this manner to generate a Vigenère cipher is widespread and has been used since before I was interested in computers (late 70s).

      So nothing belonging to Active State over which they have any exclusive IP rights has been touched. What has been done is to demonstrate that the task is quite do-able. My question was and remains should it be this easy? If it is then those using PerlApp for pseudo security should be aware of this.

      I think this is quite different from breaking the encryption of DVDs - that was naughty and the only foreseeable purpose illegal. It is also difficult to fix given the huge investment in infrastructure. PerlApp in contrast would be easy to fix.




        I read the news today, oh boy.

        The fact that the encryption method is well-known and ineffective is irrelevant. The schemes used by both CSS and the software mentioned in the story I linked are also relatively facile, known and ineffective.

        The fact that you were decrypting content with IP rights not belonging to ActiveState is irrelevant. Digital rights management systems are not designed to protect the IP rights of the system's designers, but the rights of the licensees and users of the system. To that end, the DMCA criminalizes any attempts to circumvent the system, even if you are circumventing to gain access to your own IP.

        That said, I wouldn't fret over it too much, but if you see a band of men wearing suits and earpieces jump out of a black, unmarked Suburban, it couldn't hurt to start walking briskly in the other direction :-p

                       s aamecha.s a..a\u$&owag.print
        First (and noting that tachyon is from Australia where the laws are probably a bit different), now that you've discussed publicly how to reverse engineer a script from the binary produced by the AS product, I don't need to be the owner of the original script. You've just shared with the world how to break an encryption scheme. This is one of the things forbidden by the DMCA and is exactly what is getting various Russians (visiting the USA) and 2600 publishers in trouble. Luckily for Perl Monks, PM is not on ActiveState's sh*tlist (and probably just barely on their radar) and it is doubtful that AS would be so boneheaded to go reporting PM to the authorities over this-- unlike Adobe their reputation could be seriously harmed by such a thing.

        Second, there are plenty of purposes which are foreseeable for breaking the encryption on a DVD which are not illegal. Examples include: archiving, personal use sampling (say I wanted to make a compilation of my favorite scenes from the movies), Fair Use sampling (for academic works on movies or reviews), watching DVDs on computers or players for which there is no existing player software, watching DVDs using Free Software as opposed to $40 per license software. All of these uses are legally allowed, but technically impossible due to the encryption scheme. They would become technically posssible if it were legal to crack the encryption scheme.

        This whole discussion points up why the DMCA is a bad law-- in the USA we can't discuss how to recover our own scripts without cracking someone else's encryption scheme, which is forbidden. Personally, I enjoyed seeing how this was done and filed the whole matter under "Why trying to obscure the source of Perl scripts is a big waste of time" with a cross-reference to "Avoid Active State add-ons to Perl" :)
Re: Security, is it to much to ask?
by joefission (Monk) on Jul 17, 2001 at 19:02 UTC
    I don't believe securirity is the issue, just the ability to execute perl scripts on hosts without perl.

    Actually, Desdinova states it well, as does Jouke in The Perl Compiler discussion.

      I have to agree with tachyon here. One of the benefits of compiling your scripts - according to ActiveState - is:

      Script Encryption
      Protect your intellectual property with the ability to hide your source code.

      Yes, the source code is hidden, but the suggestion that this allows one to protect one's intellectual property is flat out wrong. My personal thought is that it is dishonest for a company to suggest that their products offer more than they do.

      Incidentally, this is not the only time that ActiveState has decided that security is not that big of a deal. From an email correspondence I had with ActiveState (emphasis mine):

      Unfortunately, PerlEx does not currently allow you to use taint checking. However, it is being considered as a feature of the next PerlEx release, which is scheduled to occur in the couple of months.

      That email was sent two months ago, as of this writing. As far as I understand, they still do not incorporate taint checking in PerlEx. Security does not appear to be a significant concern to them.

      Side note: we are in the process of migrating one of our largest projects from Win2K/IIS to Linux/Apache/mod_perl in part because of ActiveState's lackadaisical attitude regarding security.


      Vote for paco!

      Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

        Script Encryption
        Protect your intellectual property with the ability to hide your source code.
        In that case, one wonders whether et. al. are in violation of the DMCA for reverse-engineering a mechanism that "effectively controls access to a copyrighted work". Of course, the word "effective" isn't the first that springs to mind in this particular case :-)
                       s aamecha.s a..a\u$&owag.print
        Where are you getting this? Is there a perldoc PerlApp you are looking at?

        The ActiveState PDK3.0 docs clearly state the purpose of PerlApp. It Turns your Perl scripts into executables, so that you can run Perl scripts on computers without installing Perl.

        Maybe ActiveState stated the security business in previous versions of PerlApp or PDKs. And then again, perhaps they realized the folly of protecting IP. I'm sure they wouldn't want to be liable for someone's IP being compromised using their product.

        Please post the relevant documentation so I can understand what you and tachyon are saying. No offense, but I think you guys are getting worked up over a fallacy.

        my $0.02 = "Isnt it part of the Perl license that things distributed with Perl source, are distributed under the same license as Perl itself?";

        If so, where is the intellectual property?

        _14k4 - (
Re: Security, is it to much to ask?
by toma (Vicar) on Jul 19, 2001 at 12:17 UTC
    The use of the copyright notice as a trivial decryption key is a clever legal hack. Since ActiveState 'owns' this phrase, it would be ill-advised to distribute software that uses it, unless you have their permission.

    This allows them to use normal trademark and copyright law to protect their scheme, without relying on the presumably short-lived DMCA BS.

    I am not a lawyer, yadda yadda yadda...

    It should work perfectly the first time! - toma

      What if I compile a 17 character perl script like print "foobar\n";? The XOR key then becomes Copyright © 2000 which can not be 'owned' by them. I doubt that this would constitute distribution of software under another's copyright notice even if it was long enough to incorporate the whole string as, although it is being 'used', it is not on display.

      "Argument is futile - you will be ignorralated!"

        I don't think that toma's point was that the encrypted software is copyrighted by AS, but that any complete program to decode software encrypted by them would be in violation of their copyright, since it would by definition include the copyright phrase (or something that eventually evaluates structurally to that phrase, no matter how obfu'd).

        By the way, even a program like
        print "foobar\n";

        ends up being a program of about 500kB when it is made into an executable by AS's software, IIRC.
Re: Security, is it to much to ask?
by Zaxo (Archbishop) on Jul 18, 2001 at 16:11 UTC

    It worries me that PerlApp induces authors to stamp 'Copyright © 2000 ActiveState Tool Corp.' on their work. It also worries me that DMCA supposedly prevents their even knowing that they have done so.

    Given the diseased condition of U.S. justice and IP law, I don't believe I'd risk using PerlApp.

    After Compline,

A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://97234]
Approved by root
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others wandering the Monastery: (4)
As of 2024-06-24 15:41 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.