Home
Up

I did not see your code for "unencrypting" encrypted scripts neither on ESRI site nor on yours (http//members.home.net/whuber), but I believe you have it (if you say so).

Now, do you have any idea how one can protect the code of his scripts.

"A lot of people have written asking (that's the polite word) me not to post this code. I am considering their requests, so no code has been posted"

Please do not play GOD. If you have done it, some other guy can do it as well. Personally I've never tried (don't have time for that), but I'm sure after your announcement quite a few guys will try .

"Nevertheless, whether I publish this or not, you may as well assume anyone can read your encrypted scripts."

There always will be somebody able to crack any software, but how many people do you thing will be able to do that. Even if you post your script, or somebody else does that, how many people do you think will be able to understand the source code of a complex application.

"I am glad you are sceptical (not enough people are). Feel free to send me a project or extension file with encrypted scripts"

As I wrote, I believe you've got it and do not need a proof of that.

The most important result of your discovery is that instead of creating useful applications now we (including you) must spent a lot of time trying to protect our code. I agree that ESRI should try to protect their users better.

The same algorithm for decrypting Avenue scripts also works on encrypted Arc/Info amls (but there's also a simpler way provided by ESRI itself). In fact, there was paper presented at a conference that documented a possible methodology for breaking ESRI's encryption scheme that was available over the web. The crack for ESRI encryption is known and I know of at least two independent sources that have broken the encryption independently of each other.

I don't understand the purpose of posting a cracking script (not that I'm necessarily against it), but the simplicity of the Avenue language makes me wonder what is worth encrypting. I'm sure that for whatever clever piece of code that I produce, someone else has done it before and probably better. I suggest that if you really want to protect your code, then write it in a compiled language - which is of course not also as safe as you think, having seen decompilers such as SoftIce at work. If you really want to buffalo someone from stealing avenue code, write it so that it simulates mouseclicks on dialogs that aren't shown. Jeez, debugging that will drive you mad.

Thank you for taking the time to inform the community on this important problem with ArcView.

Congratulations, though you are probably right, it was no good idea to publish your findings about the encryption of AV-Scripts.

I do commercial AV developments myself and I would like to protect my investment. Though I suspected since the beginning of my work, that it is not so very complicated to hack the encryption of the ESRI scripts, the encryption prevented that my customers recycled my scripts.

Thanks to your 'great invention' every idiot can now use the knowhow invested into the encrypted scripts - really great.... What do you think, who is now still interested to offer commercial extensions to the public???

I would have preferred, that you keep your findings for yourself, maybe hack the one or the other encrypted script - just for your personal pleasure and keep your mouth shut.

I am not sure whether to be glad or unhappy that you wrote this to the list. On the one hand, being protected is a serious matter; on the other, there is no encryption that cannot be cracked. The issue is not a technical one, but an ethical one. Why would anyone (anyone else) want to crack the AV encryption? Im someone did (for the fun of it I presume) would they really use it for commercial theft? Perhaps I am naive, but then again, I have never heard anyone on arcview-l complain about having had their scripts decrypted and stolen. Maybe if you post your "crack" they will. Send it to ESRI so they can fix this problem in AV3.3, but please please please don't post it to any public locations.

At 02:25 PM 6/21/99 -0600, you wrote: > >Are you basically extracting the scripts from the project or extension as they are both in ASCII format?

I wrote an interface so that the encrypted scripts automatically get decrypted during the process, so as far as it appears to the user they aren't encrypted at all. The heart of the code is a little Avenue program that accepts an encrypted string (as read from an apr, avx, or odb file for example) and returns a decrypted version.

At 03:40 PM 6/21/99 -0500, you wrote: > The crack for ESRI encryption is known and I know of at least two independent sources that have broken the encryption independently of each other.

Thank you. Do you have references? If this is known, it's a real shame there's no pointers to it on the ESRI web site.

By the way, it's a joke to call it "encryption." The system is SIMPLER than the twenty-minute ciphers you can find in the daily newspapers. Honestly.

>I don't understand the purpose of posting a cracking script (not that I'm necessarily against it)

So that fewer people will be tempted to trust in the encryption scheme. Not posting it gives a distinct--and, IMHO, unfair--advantage to the people who know about and have access to the decryption code. Posting it might also help force the issue and cause ESRI to invest a few more pennies in writing a decent encryption algorithm.

>but the simplicity of the Avenue language makes me wonder what is worth encrypting.

One of the simplest languages I ever wrote (and sold) code in is MASM, in which you can program anything at all. Simplicity has nothing to do with the value of encryption. What you want to do is erect a sufficiently high barrier to software duplication that people generally find it more worthwhile to obtain an encrypted program from a valid source than to illicitly decrypt it or reverse engineer it.

> I'm sure that for whatever clever piece of code that I produce, someone else has done it before and probably better.

That's not true of everyone, I'm sure. Besides, a lot of coding is simply hard work and diligence, not cleverness. Most people feel that hard work deserves some protection, as well.

>I suggest that if you really want to protect your code, then write it in a compiled language - which is of course not also as safe as you think, having seen decompilers such as SoftIce at work.

I agree it is not safe. I long ago decompiled and reverse-engineered DOS using primitive debuggers, so I have few illusions about the compilation process. Again, the point is to make it not worth someone's while to decrypt your code. It's a balancing of costs and benefits. If it's fantastically easier to decrypt scripts than people think, then software developers will not be playing with a full deck and are more likely to make unhappy decisions. In my case, this discovery will drive me not to compile the code, but simply not to encrypt it at all.

>If you really want to buffalo someone from stealing avenue code, write it so that it simulates mouseclicks on dialogs that aren't shown.

That is a really bright idea. I can imagine some places where it will be worth considering.

I didn't see your script posted on ESRI's site, or on yours -- is it available? If this is the case, then I will share your dismay as well.

Thanks for your great contributions to the ArcView list.

At 02:57 PM 6/21/99 -0700, you wrote: >This is very interesting. Have you posted it on ArcScripts or on your website? I looked and could not find.

No. I am waiting a few days to see what responses I get; perhaps something's already posted and I'll merely need to point people in that direction. Or perhaps somebody will send me a really, really good reason not to post it :-). I intend to write a SUM for the list to update you about this.

At 12:05 AM 6/22/99 +0200, you wrote:

>Congratulations, though you are probably right, it was no good idea to publish your findings about the encryption of AV-Scripts.  I do commercial AV developments myself and I would like to protect my investment. Though I suspected since the beginning of my work, that it is not so very complicated to hack the encryption of the ESRI scripts, the encryption prevented that my customers recycled my scripts. Thanks to your 'great invention' every idiot can now use the knowhow invested into the encrypted scripts - really great.... What do you think, who is now still interested to offer commercial extensions to the public??? I would have preferred, that you keep your findings for yourself, maybe hack the one or the other encrypted script - just for your personal pleasure and keep your mouth shut.

My fear is that lots of people are already doing that. What would make you happier: being ignorant that the encryption is useless or knowing that it is useless? I opt for the knowing; you appear to want to remain ignorant. That's no protection, though.

I haven't posted anything yet and I am open-minded still: I see merit in what you say. If you can temper your vitriol just a little and give me some better support for your point of view you just might win the day.

At 03:14 PM 6/21/99 -0700, you wrote: >there is no encryption that cannot be cracked.

I am not so sure of that, but for the sake of discussion I will accept this as an hypothesis. Therefore the issue regards the difficulty of cracking the encryption. All I can say is it was immediately evident, from the moment I first (inadvertently) glanced at an avx file with encrypted scripts (MY scripts, by the way), that this would be insanely easy to decrypt. There's a disconnect here: I was working hard to encrypt my scripts, naively assuming this would be sufficient protection against all but the most determined hacker (who would be better off just rewriting from scratch anything I've ever written in Avenue). It was a huge let-down to see not only that this was virtually no protection, but that it was of such limited value that probably there are lots of people out there right now with the ability to read encrypted scripts directly.

>The issue is not a technical one, but an ethical one.

Good point. Absolutely. Upon reflection, I decided that it would be unethical to remain quiet about this situation. I am still not completely decided about full disclosure of the method, but provisionally feel that holding this back would be unethical too. Without that kind of full disclosure, there will be two kinds of ArcView users: those who can read encrypted scripts (because they have access to whatever is being circulated "underground") and those who cannot. Those developers in the second camp, unaware of the former, would believe they have protection (through encryption) that does not exist. The fastest and clearest way to make the entire community clearly aware of the real state of affairs is the publication of the decryption technique.

>Why would anyone (anyone else) want to crack the AV encryption?

For the same reason people check the quality of their random number generators and the precision of their statistical software: to verify that the vendor's claims are true. And no, I did not set out to break into people's scripts. I merely wondered how secure MINE were, and it quickly dawned on me they were not secure at all.

>Im someone did (for the fun of it I presume) would they really use it for commercial theft?

Does that need an answer?

>Perhaps I am naive, but then again, I have never heard anyone on arcview-l complain about having had their scripts decrypted and stolen.

Ignorance is bliss.

>Maybe if you post your "crack" they will.

I am concerned about that. What I would love to see is for ESRI to say "yes, this is important, and we will post an ArcView update with a fix in N months." Then it might be possible to hold off N+1 months before posting the method, if N isn't too long. Or even not post it at all.

>Send it to ESRI so they can fix this problem in AV3.3,

Have you ever gotten that kind of response from ESRI? I haven't. If I had, my message would have gone straight to them, not to you.

>but please please please don't post it to any public locations.

I have not (yet), but I fear that the bulk of the damage has been done. If people have the belief the encryption is easy to break, then anyone with the desire will be able (quickly) to do it. At this point I think very little is lost, and everyone else--the honest folks--can only gain by seeing how the system works and by having a tool to recover encrypted scripts whose source may have been lost.

I am interested in any follow-up thoughts you might have and would like to hear from you again before I take any further action.

At 04:43 PM 6/21/99 -0600, you wrote:

>I didn't see your script posted on ESRI's site, or on yours -- is it available? If this is the case, then I will share your dismay as well.

I haven't tried yet. Several pleas have come in asking me not to post the script. It's a very difficult question to decide, posting or not, so I am having a dialog (via e-mail) before I make a decision. Posting, after all, is irrevocable, and I believe that simply letting the world know that decryption is easy (VERY easy) already goes a long way toward addressing the issue. What do you think?

By the way, ESRI posted my message with no delay or objection. That's a good sign I think.

Well, it is a difficult question. I think it would probably would be best not to post it. But now that you have "raised the bar", then others will undoubtably try to write a program to unencrypt it -- like it will probably keep me and others awake in bed tonight thinking how you must have done this...

I guess it raises the question who will want access to the encrypted code. I've written some extensions myself that I intend to sell (through a company I started) that are encrypted, and it would be a bummer if folks could easily gain access to the underlying code. And this could be a formidable challenge to ESRI as well... I think it would be interesting to see if you get offers for the unencrypting script!

On the other hand, this is intriguing, because it might make everything "open source"!

Maybe a way out of this is to simply recount your assertion, and say something like -- "it only worked on one script that had X..." But this is kind of lame, and some other bright Avenuer might figure it out later... Anyway, I probably wouldn't post it.

Hi Bill: I am in full accord with your stance, and am actually a little surprised that the encrypt statement even exists in ArcView as they are in accord with the ???

I look forward to it.....

I think I agree with your position on this issue. I must admit, though, that I am unable to see how I personally could "easily" crack the encryption AV uses. My deepest regard for you as a programmer if you really "saw immediately". Perhaps you are an encryption expert? The way I look at it, not many of my competitors (and definitely none of my clients) have the skill, intelligence or motivation to do it if I don't. Of course I wince to see anything which might increase their motivation (particularly for those that have the skill and intelligence already), such as your email.

As a business partner, I think we have a serious interest in what you are saying though. The posibility is real now, even if slim. I think that this is serious enought to bring to ESRI's attention immediately. I am sure we could take this right to the top and get a good response. We have in the past.

Perhaps you could send me something explaining why this code is so easy to crack? Perhaps an extension (encrypted of course) that will unencrypt the encrypted scripts in my projects?

At 05:43 PM 6/21/99 -0600, you wrote: >Well, it is a difficult question. ...

Thank you for your thoughts. I am still searching for answers. The "open source" comment comes close to the mark.

I'm not saying much yet to anyone about the decrypting (or encrypting) methods because to say anything at all would give it away.

At 04:43 PM 6/21/99 -0700, you wrote:

>I am in full accord with your stance, and am actually a little surprised that the encrypt statement even exists in ArcView as they are in accord with the ???

Thank you for your support, for I am wavering in the face of some challenging responses from other points of view (I haven't published any details of the decryption at this time). Exactly to what do you refer with this "open software concept"? Could you point me to something ESRI has published regarding this? (I haven't paid any attention to those issues since I grew tired of the ESRI-Intergraph debates years back.)

At 05:15 PM 6/21/99 -0700, you wrote:

> Perhaps you are an encryption expert?

Far from it.  I probably learned most about encryption by judging the math exhibits at the International Science and Engineering Fair (high school level, now!) this year.  I posted that message precisely because I am NOT an expert and still the encryption method was obvious.

>The way I look at it, not many of my competitors (and definitely none of my clients) have the skill, intelligence or motivation to do it if I don't.

I would not assume that.


>Of course I wince to see anything which might increase their motivation (particularly for those that have the skill and intelligence already), such as your email.

Yeah, that bothers me too.  But not telling people would be worse.  I view the naively simple encryption method as a serious program defect in ArcView with greater potential to harm those who don't know about it.  The real question is whether publicizing my claim is the right balance between revealing too little and too much.

> I am sure we could take this right to the top and get a good response.  We have in the past.

You are welcome to do so.  I made several pitches within the past half year just to get a line to technical folks at ESRI to report bugs--I was encountering one new one a day during a development project last December.  No need for support, no need for responses beyond acknowledgment--I just wanted to do my share towards helping improve the product.  No dice.  They won't respond to me.  (ESRI is helpful in many other ways, don't get me wrong.  But this particular proposal only goes down a black hole.)


>Perhaps you could send me something explaining why this code is so easy to crack?  Perhaps an extension (encrypted of course) that will unencrypt the encrypted scripts in my projects?

Hah!  And the first thing you could apply the extension to is the extension file itself!  (I just did it: I encrypted the scripts (hadn't bothered before!), remade the extension, read in the avx file nicely.)

The extension you refer to exists.  It could be put to positive use in rescuing encrypted code having no unencrypted backup.  Believe it or not, ArcView even encrypts the comments--you can recover every last byte of your code.

Let me put it this way: the method is less sophisticated than the Cap'n Crunch decoder ring--used as originally intended, not for phone phreaking.

I'll give you one more hint, and you can pass this along to ESRI, too: Prepend "'" + 8.AsChar + NL to the beginning of any script.  (That's a one-line comment containing an ASCII 8.)  You'll probably have to do it with Avenue code, as I did:

strSignature = "'" + 8.AsChar + NL

...

    theSEd = <any way you want to get hold of it>

...

    theScript = theSEd.GetScript
   
    strSource = theScript.AsString
    if (strSource.Left(strSignature.Count) <> strSignature) then
      theScript = Script.Make(strSignature + strSource)
    end
   
    theScript = theScript.AsEncrypted

From what I can tell, ArcView will fail to read your encrypted script beyond this comment.  The encrypted version of the script, accordingly, does nothing.  Nice bug.  Don't like ASCII 8's?  I can produce the bug with ASCII 1, 4, 7, 8, 251, and 254, provided it's done just right (a simple modification of the above code isn't good enough).  The last two are foreign language characters, û and þ.  Maybe our European friends (French and Norwegian, I believe) aren't complaining loudly enough yet?

If what you want is proof, I would be happy to decrypt all the scripts in any avx, apr, or odb file you care to send me, provided you can prove they are your scripts.  Just put your name and e-mail address in the header comments to a script, encrypt it, save it, and send it along.  That way I'll know I'm not doing anything unethical by decrypting the stuff.  And you can have confidence there's something to back you up if you bring this up with ESRI.

Respondents 11-19    Respondents 20-27    Respondents 28-33    ArcView Encryption

ColorRamp, Memorized Calculations, Rotate, Sample, XSect, and Tissot  are  trademarks of Quantitative Decisions.  All other products mentioned are registered trademarks or trademarks of their respective companies.

Questions or problems regarding this web site should be directed to webmaster@quantdec.com.
Copyright © 2000-2002 Quantitative Decisions.  All rights reserved.
Last modified: Monday July 01, 2002.