|
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.
MeowChow
s aamecha.s a..a\u$&owag.print | [reply] |
(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. | [reply] |
|
|
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.
cheers
tachyon
s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print
| [reply] |
|
|
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
MeowChow
s aamecha.s a..a\u$&owag.print | [reply] |
|
|
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" :)
| [reply] |
|
|
|
|
|
|
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. | [reply] |
|
|
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.
Cheers,
Ovid
Vote for paco!
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.
| [reply] |
|
|
Script Encryption
Protect your intellectual property with the ability to hide your source code.
In that case, one wonders whether perlmonks.com 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 :-)
MeowChow
s aamecha.s a..a\u$&owag.print | [reply] |
|
|
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.
| [reply] |
|
|
|
|
|
|
|
|
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 - perlmonks@poorheart.com (www.poorheart.com)
| [reply] |
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 | [reply] |
|
|
| [reply]
[d/l]
[select] |
|
|
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. | [reply]
[d/l] |
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,
Zaxo
| [reply] |
| A reply falls below the community's threshold of quality. You may see it by logging in. |