Home
Up

[NB: Respondents 28 and 26 are the same person.]

At 08:09 AM 6/25/99 -0400, you wrote: > I guess I suffered from brain gas lately and encrypted a few scripts that I really do not wish to re-write. Could you forward the script you mentioned so I could try to decrypt my blunder?

I will be posting a more detailed sum on ArcView-L soon. Many apologies for being unable to carry out my promise of releasing the software. It hurts to be unable to do that.

At 08:14 AM 6/25/99 -0400, you wrote:

>Has ESRI accepted you script to decrypt scripts? If not, have you placed it on your web page? I am curious as to what happens here. I was talking with a developer from the D.C. area yesterday and he said that this happened before & ESRI said they would basically sue the person if they distributed the script.

No and no. I have corresponded with the person (or one of the persons--this incident may have happened more than once) involved and what you say accords with his story, except he just referred to it as a bit of ESRI arm-twisting, not a threat to sue. He also heard from a European developer who apparently went through the same process with ESRI in Europe.

A threat of a lawsuit would have to be taken seriously but, I believe, is ultimately not legitimate and would not be successful. I have the resources to defend such a suit, so that's not the issue. Rather, many developers have written me alleging that releasing the decryption script (actually an extension) would cause them great harm. As an ethical matter, then, I cannot act unless those allegations can be dispelled. I fully intend to discuss this matter in some depth in a SUM to the ArcView-L list.

I am truly embarrassed not to be able to post the script at this time. I hope a compromise will be possible. Stay tuned. Thanks for the good wishes.

At 11:56 AM 6/23/99 -0700, you wrote:

>View.MCP would be very handy... thanks

Are you saying you would like to see Avenue code that could be used to implement View.MCP? As far as I can tell from having experimented with the extension, this script simply produces the convex hull of a theme of points. If this is true, you can find Convex Hull scripts on the ESRI page--search for "Convex Hull". I can also provide you an extremely simple algorithm (far simpler than the one actually used by View.MCP) implemented in Avenue.

I have an encrypted project that I need to modify, unfortunately the un-encrypted original is on a corrupted 8mm tape. I saw on your website that there have been issues raised about your decryption script. If you can not send me the script, can you decrypt my project for a small fee? (I could provide evidence that this is indeed my own work).

**********************************************************
WINDOWS NT MAGAZINE SECURITY UPDATE
The bi-weekly Windows NT security update newsletter
**********************************************************

Copyright Windows NT Magazine UPDATE,  June 30, 1999, reproduced with permission. 

June 30, 1999 Hello everyone,

Buffer overruns are one of the biggest security problems that exist today. A perfect example is the discovery of a serious buffer overrun in Microsoft's Internet Information Server (IIS). eEYE Digital Security Team recently announced the buffer overrun condition in IIS (reported in this issue), and to demonstrate the problem's severity, the company released working programs that bypass Windows NT security on an IIS server. Using eEye's examples, an intruder can gain complete control over a remote IIS system. With the release of working exploit code came an onslaught of verbal attacks against eEYE. Many companies, including Microsoft, blasted eEYE's release of working exploit code as an irresponsible act--but was it truly irresponsible? I don't think so, and apparently neither do most visitors to the Windows NT Magazine Web site. A survey on our home page last week indicates that 67 percent of 3648 respondents think eEYE was justified in releasing the source code. So what purpose does releasing complete details and working exploit code serve? When someone releases the details of a security risk, everyone benefits much more than if the details are kept secret. By knowing the exact details of a security risk, people can dissect the nature of the problem and learn how to prevent similar concerns in the future. And, by using example code as a starting point, programmers can look for other security problems in a given software package, and perhaps learn some better coding practices. In any case, the end result is faster elimination of security risks and a lower learning curve for security aficionados. Could administrators learn as much about a security risk without receiving full disclosure of details? Absolutely not. Without full disclosure, we'd only learn how to prevent a risk, and we'd have to rely on the vendor to tell us where the risks are. If that scenario worked at all, there'd be no arguments over full disclosure in the first place. I think you'll agree with me that full disclosure is a necessary check and balance for security in the computing industry. We must have full disclosure to ensure our information security and to learn from the multitude of mistakes that developers make. Full disclosure promotes robust learning and stronger security across the board. Sure, it might put a little egg on the face of a given vendor, but I think that's a small price to pay in exchange for stronger security. Insiders tell me Microsoft has placed a keen eye on buffer overrun conditions in its code. I think we can all look forward to Windows 2000 (Win2K) being more secure than NT 4.0. Until next time, have a great week.

Sincerely, Mark Joseph Edwards, News Editor mark@ntsecurity.net

At 09:48 AM 6/30/99 -0600, you wrote:

> I have an encrypted project that I need to modify, unfortunately the un-encrypted original is on a corrupted 8mm tape. I saw on your website that there have been issues raised about your decryption script. If you can not send me the script, can you decrypt my project for a small fee? (I could provide evidence that this is indeed my own work).

Please don't advertise this, but the fee is nothing. I also agree not to reveal anything proprietary that may be contained in the decrypted scripts. My program reads all scripts from a project file, encrypted or not, automatically decrypting the encrypted ones, and adds them to the current project. You would get back, then, a project containing nothing but unencrypted scripts. I would send it back to you zipped with a password. I would probably need to inspect the script headers or whatever else is necessary to confirm that they do belong to you or your organization. If the answer is not clear cut, I will not send back anything--my company cannot afford to get into the business of deciding who has rights to what script.

The best evidence to provide is evidence contained in the encrypted scripts themselves, such as comments containing your name or e-mail address.

The scripts should have headers indicating either myself, or my colleague X as the authors and Y, Inc. as the company--if the company name is included.

-Tremendous Thanks! this was going to cost me many "Volunteer" hours to recreate this project.

Here's the output of my program: Scripts processed, number of characters (* = decrypted): 1 "1.startDet" 3047* 2 "2.SelCarTool" 6765* 3 "9.viewMnuDetImg" 2993* 4 "11.print" 9950* 5 "9.returnView" 1433* 6 "Script1" 1163* 7 "2.selDetClick" 1620* 8 "9.viewMnuLinImg" 2653* 9 "1.startLin" 2310* 10 "12.InfoToolApply" 4322* 11 "9.FToolApply" 4782* 12 "9.viewMnuValImg" 2768* 13 "10.print" 9839* 14 "1.startUp" 12226* 15 "10.mnuAbout" 652* 16 "2.selValTool" 3266* 17 "10.deleteClone" 807* 18 "2.selDetTool" 2392* 19 "9.ImageViewZoom" 1980* 20 "2.SelCarClick" 1831* 21 "2.selValClick" 1700* 22 "1.startCar" 2320* 23 "2.selLinTool" 3747* 24 "12.InfoToolClick" 1139* 25 "1.startVal" 3140* 26 "9.FtoolClick" 960* 27 "2.selLinClick" 1699* 28 "9.ImageViewZoomUndo" 2356*

Just import the attached project into the encrypted version. (That might save having to recreate the interface.) As promised, the attachment is zipped. The password is the word preceding "8mm" in your previous message to me.

At 09:39 AM 6/25/99 -0700, you wrote: > I hereby volunteer to talk with Rich Turner and crew, but your expertise and explanations would be more persuasive. My contribution is that, as representative of a ESRI business partner, I can insist that they do something about this sooner rather than later.

There is a long story here. The gist is that (a) In late '98 I contacted ESRI in general about reporting things like this. I asked twice but got absolutely no response. Therefore I have not attempted directly to contact ESRI about this particular issue.

(b) Your contribution would be worthwhile. The bad-encryption issue was first raised (and got ESRI's attention, I hear) in 1996, but to no avail. Instead their programmers went into a major defensive mode and their marketing arm did not change their approach (the encryption is "irreversible", etc.). There is no way for a third party to fix the problem. (It's just too easy to intercept any attempt using Avenue or DLLs to "roll your own" encryption.) There do exist powerful fixes that could be implemented and thoroughly tested by any competent programmer within hours, provided they had access to the ArcView source code. It is a mystery why ArcView and ArcInfo continue to use this awful approach. Worse, this failure to respond on ESRI's part casts significant doubt on the quality of all their code, in my view. (The RNG posting was just the first manifestation of that new suspicion.)

I would be very interested in hearing from you about the reaction you get from ESRI on this issue.

I have great need for this script on some old encrypted scripts that I have lost the original code for. Please send the decrypted to me now if at all possible, I need one of my ole scripts right now.

At 03:56 PM 7/8/99 -0600, you wrote: >I have great need for this script on some old encrypted scripts that I have lost the original code for. Please send the decrypted to me now if at all possible, I need one of my ole scripts right now.

Many Avenue developers wrote to me complaining that releasing the decryption extension would put them out of business. Whether they are correct or not, professional ethical codes demand that I refrain from posting something that could cause people harm. However, if your scripts contain comments that identify you as their author, I would be happy to decrypt them and mail you back the results. Otherwise, I will be sorry that I am unable to help you.

Thanks for your rapid response, Bill.

The project is a incomplete version of a little thing I developed last summer ... that I plan to present at this year's users conference in San Diego. I do have other versions, but there is about two scripts in the encrypted version that I know I modified (because the encrypted version does things right) whereas other versions don't. I do not think I put my name on the scripts because it was my first full application design, so I was just trying to get it done. You can look me up though on the user's conference list under X to see that I am presenting this topic. I do not even know what to send you, though. It says the encryption is stored in an odb file, but I have never found one. What would I send to you, and is there a charge? I could probably figure it out eventually, because the scripts are pretty basic, but I wrote it a year ago, and I do not have a lot of time left.

THanks!

I was just experimenting as a newbie at the time and I did not know encryption was permanent. I do not plan to use it in the future, because most end users are not going to be able to reconstruct the dialogs, etc. from an extension and put the whole application all back together. Besides I develop for government and educational institutions, so it would all be public access anyway.

At 09:50 AM 7/9/99 -0600, you wrote: > It says the encryption is stored in an odb file, but I have never found one.

ArcView project files are a kind of ODB file. So are avl files, avx files, and odb files (which can be created and read using various scripts and extensions available at the ESRI site).

>What would I send to you,

Thus, you would send a project or extension file containing the encrypted scripts.

>and is there a charge?

No. But it has to be really obvious that you are the author of the encrypted scripts. I cannot get involved in determining who is making fair use of decryption and who is not.

Thanks for more info, I also thank you for explaining why my dialog frames always gets shifted, orphaning the controls. I called two of my professors who I sent my project last summer, one, my advisor and the other the professor for the AVENUE course I was taking. They are both going to check if they can find that particular version of my .apr. If neither can, then I will ask you again for the favor; but I will have to also scrounge up my course project paper with detailed information about the project to prove I am the author, since at the time I did not include proper script headings.

At 04:00 PM 7/9/99 -0500, you wrote:

>Does anyone know anything about encrypting an extension? I want to encrypt all of the scripts in the extension before I submit it to the client.

The appended script does the trick. I name it "EncryptScripts" and call it just before creating an extension, using a line such as

av.Run("EncryptScripts", NIL)

(If you use the ESRI extension maker code, insert this line at the very beginning of the MyExtensionMAKE script.) There are two lines you need to modify to suit your purposes: around the fourth line down, particular scripts are selected for encrypting using an if..then..else statement. About midway through the code, particular scripts are excluded from encrypting (anything containing the string "help"). Use it and modify it or simply read the code to see how the encryption proceeds. Be sure to note the defensive code that prevents you from losing your original scripts, as well as the code that works around Avenue bugs.

--Bill Huber

' Name: EncryptScripts
'
' Headline: Encrypt all key scripts
'
' Self:
'
' Called by: Extension maker
'
' Returns:
'
' Description: Encrypts and embeds scripts.
'
' History: AV 3.1
' William A. Huber @ Quantitative Decisions, Merion, PA. whuber@QuantDec.com
'
' Comments: Changes project name to prevent corrupting source project.
' Does not encrypt help scripts.
' Changes the project name to avoid destroying unencrypted scripts.
'=============================================================================
' strTitle = "EncryptScripts" av.GetProject.SetName(av.GetProject.GetName ++ "(encrypted)") for each theSED in av.GetProject.GetDocs.Clone if (theSED.Is(SED) and ((theSED.GetName = "ListFormulas*".AsPattern) or (theSED.GetName = "NewField*".AsPattern)) ) then

' make sure the script is compiled
if (theSEd.IsCompiled.Not) then theSEd.Compile end if (theSEd.HasError) then msgBox.Info(theSEd.GetName ++ "has errors; not embedding.", "") continue end

' See if there is another script with that name
if (av.GetProject.GetScripts.Get(theSEd.GetName) <> nil) then if (not msgbox.MiniYesNo("Overwrite"++theSEd.GetName,"Exists",TRUE)) then continue end end

' encrypt and embed the script
if (theSED.GetName.Contains("Help")) then theScript = theSEd.GetScript else theScript = theSEd.GetScript.AsEncrypted end if (theScript = NIL) then

' Avenue bug: empty SEds have NIL scripts
theScript = Script.Make("'") end theScript.SetName(theSEd.GetName) av.GetProject.AddScript( theScript )

' remove the script editor
av.GetProject.RemoveDoc( theSEd ) end end
' end of script

Thanks for your very thoughtful short article on encryption methods. By chance will you be attending the ESRI User Conference? I will be, and maybe we could chat?

I read your contribution to the ArcView List some time ago about encryption in ArcView. As many Avenue users it was quite surprising but interesting. I have then started to write my own encrypted script. But after some time i realised that encrypting the ArcView script that i wrote was impossible. Nothing on your web site about that? Did you really manage to do it? Thank you

I've been checking the ESRI list serve and your site regularly in hopes to find the summary of the encryption email, etc. I'm sure the results were quite interesting, as your posting surely created quite a bit of controversy. I was also wondering if I might have missed an additional posting on the list serve. Did you have an opportunity to compile them since your last posting on yourweb page?

At 09:29 AM 8/2/99 -0400, you wrote:

>I've been checking the ESRI list serve and your site regularly in hopes to find the summary of the encryption email, etc. I'm sure the results were quite interesting, as your posting surely created quite a bit of controversy. I was also wondering if I might have missed an additional posting on the list serve. Did you have an opportunity to compile them since your last posting...

Thank you very much for the expression of interest. My silence actually reflects a lot of hard work along with the evolution of my thinking. The first posting was largely an expression of frustration, because it is just not possible to write one's own encryption capability in ArcView--you have, basically, to accept what ESRI offers. However, in mulling over the many responses I received, I realized that there are some things that can be done to make scripts much less readable in an "irreversible" way, short of out-and-out encryption. I spent last weekend implementing one such idea and hope to post it (as a working program), along with a summary of all the other responses, to ArcView-L. If I have enough time and energy the details will go up on the web, but there will nevertheless be an ArcView-L notice and short summary.

I appreciate your patience and hope that you will find the wait eventually rewarding.

By the way, the "Encryption Analysis" and "ArcView Random Numbers" links from my web page are outgrowths of this thread. You might find some relevant material there.

Respondents 1-10    Respondents 11-19    Respondents 20-27    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.