|
Home
Up
Explanations
Posting to ArcView-L
Respondents 1-10
Respondents 11-19
Respondents 20-27
Respondents 28-33
Avenue Uglification
| |
Updates
To serve the ArcView community, we maintain a long-standing offer to decrypt
encrypted scripts quickly and at no cost, to the extent we are able. We
have done this for researchers, major universities, and even developers of
ArcView add-on products (what do you do when your lead programmer quits and
takes all the source code with him...?). So far we have successfully
decrypted thousands of scripts in many ArcView 3.x projects and extension files.
Here's how it works:
- If you need the reassurance, we will sign a nondisclosure agreement.
You can fax us one to
and we will fax a signed copy back.
- E-mail zipped copies of the files containing the encrypted scripts to
.
Usually these are apr, avx, or odb files. They must be in ODB format.
- We will import all the scripts we can find and collect them into one or
more ArcView project (apr) files.
- We will check the headers of scripts to verify your rights to their
source. If the scripts do not contain information about their
author or ownership, you must provide convincing documentation of your right
to the unencrypted source.
- If the checks are successful, we will e-mail you the imported scripts.
Typically the process takes between an hour and a day.
On July 12, 2000, "Cliff" posted a lucid introduction to these
pages at Slashdot
and provided some excellent up-to-date references to decryption issues.
Check it out. If you arrived here from there, then glance over the
material in the Overview section below: it's a
hyperlinked guide to an online debate carried out in summer 1999--the world in
an ArcView microcosm, as it were.
On March 22, 2000, Mark Edwards (editor of the e-mail newletter Win2000Mag
Security Update) published an editorial on an attempt by the motion picture
industry to suppress web publication of software ("DeCSS") to decrypt "secure"
DVD content. He writes,
I think Hollywood has the right to sue the developers of DeCSS and
people who distribute the program, but I also think the developers of
DeCSS have the right to tell the world what they discovered. After all,
the developers of DeCSS weren't the people who said the CSS technology
was secure--they only proved that it wasn't.
That statement leads me to an interesting thought: What about the
people who developed and promoted CSS as a secure technology in the
first place? Aren't they to blame, too? If a company claims its
technology is secure, but it turns out that the product is not, could
the company be sued for fraud?
Let's substitute "ESRI" for "Hollywood" and
"Avenue encryption" for "CSS." In place of "DeCSS"
we can easily imagine a hypothetical ArcView extension "Decrypt.avx"
that reads encrypted Avenue scripts and extension files. (If you can't
imagine such an extension, read the rest of this page!) Here's what the
edited material now says:
I think ESRI has the right to sue the developers of Decrypt.avx and
people who distribute the program, but I also think the developers of
Decrypt.avx have the right to tell the world what they discovered. After all,
the developers of Decrypt.avx weren't the people who said the Avenue
encryption technology was secure--they only proved that it wasn't.
That statement leads me to an interesting thought: What about the
people [i.e., ESRI] who developed and promoted Avenue encryption as a secure technology in the
first place? Aren't they to blame, too? If a company claims its
technology is secure, but it turns out that the product is not, could
the company be sued for fraud?
Edwards did not have an answer at the time of his editorial, so he simply had
to ask people to keep an eye on the case. Nevertheless, his questions are
right on the mark. We will be watching the DeCSS case with considerable
interest.
Overview
This page outlines statements made by over 30 people during an exchange of about 80
messages during the summer of 1999. The statements are linked directly into their
original contexts for further exploration of the many points of view that were expressed.
(Some of the messages have been modified or deleted to protect requests for
confidentiality.)
The links at the left provide entry points into a (roughly) chronological transcript of
this thread.
If you are one of the respondents and would like to be identified by name, please e-mail me with your respondent number(s) and how you
wish to be identified. I will also provide mail-to links or a web link to your site
if you wish.
What's the bottom line?
- You won't find an Avenue decryption script posted here.
- You will find a method to improve encryption.
- Do not rely on encryption of Avenue scripts (for ArcView) or of AMLs (for ArcInfo) to
protect your source code.
Issues regarding posting an Avenue script decryption program.
Motivation for the posting.
Some history.
Is it really that easy to decrypt "encrypted" Avenue scripts?
Perhaps you could send me something explaining why
this code is so easy to crack?
Perhaps you are an encryption expert?
Response: It's a joke.
Now that you have pointed this out, doesn't it mean everybody will be reading
encrypted scripts? -- You shouldn't have published this information!
"Please don't play God"
I would have preferred that you keep your findings to
yourself.
Now that you have "raised the bar", then
others will undoubtedly try to write a program.
I wince to see anything which might increase motivation
of customers to decrypt scripts.
We (or ESRI, or someone) will sue you if you post decryption code.
You will eventually find your self and company in
court one day.
A developer alleges that ESRI said they would basically
sue.
Response: It still costs money to defend even frivolous
lawsuits.
Publishing a decryption program will destroy the value of existing (third-party
ArcView) software solutions.
Numerous developers would "be asking for your
removal."
If [my customers] even have a script which removes the
encryption they very likely will 'steel' my code and my ideas.
Why would anyone even want to write a decryption program?
To verify that the vendor's claims are true.
Knowing the cause of a software failure ... can improve
future development.
Why post a cracking script?
What would make you happier: being ignorant that the
encryption is useless or knowing that it is useless?
Not posting it gives a distinct and unfair advantage to
the people who know the secret.
The honest folks can only gain by seeing how the system
works.
It's a serious program defect in ArcView with greater
potential to harm those who don't know about it.
When someone releases the details of a security risk,
everyone benefits much more than if the details are kept secret. (Third-party article,
reproduced with permission.)
You should post the decryption program.
It would force ESRI's hand to resolve the issue.
ESRI needs to be made responsible for its lack of
robust production code.
Rejoinder: Above all, do no harm.
Do you even have a decryption program?
I don't find the code on your site.
Rejoinders:
Description of the code.
I'll give you one more hint.
I would be happy to decrypt all the scripts in any avx,
apr, or odb file you care to send me.
Example of output.
Encryption and decryption in general.
Hardly anyone would be able to understand the source code of a complex application,
anyway.
There always will be somebody able to crack any
software.
The Avenue language is so simple that nothing written in it is worth encrypting.
The simplicity of the Avenue language makes me wonder
what is worth encrypting.
Simplicity has nothing to do with the value of
encryption.
I dont think avenue is high-powered enough to contain
any serious secrets.
Rejoinder: There's a flaw in this thought.
Labor--debugging, design, and interface development--needs protection, too.
There is no encryption that cannot be cracked, so the issue is an ethical one, not a
technical one.
The issue is not a technical one, but an ethical one.
The issue regards the difficulty of cracking the
encryption.
Posting, after all, is irrevocable.
It is possible to reverse engineer any software.
You want to create an economic barrier against
decryption.
ESRI makes explicit representations about the quality
of their encryption.
Rejoinder: Ignorance is bliss.
What can be done.
Does ESRI even know about this? What are they doing to improve the encryption?
ESRI posted my message with no delay or objection.
They won't respond to me.
I find it hard to believe that ESRI ... would knowingly
make dishonest claims.
Rejoinder: This is definitely what the policy is.
ESRI should try to protect their users better.
Developers now have to waste time trying to protect
their code.
I would love to ESRI say "yes, this is
important."
I think that this is serious enough to bring to ESRI's
attention immediately.
What can developers do to protect their scripts?
People ultimately rely for protection on a
combination of things.
You should be writing to ESRI, not me.
How do you encrypt scripts?
ESRI supplies several scripts to do just that. Look in your installation drive at
/ESRI/AV_GIS30/ArcView/Samples/Scripts for encscrpt.ave and encprj.ave. Here's another solution.
Where is the decryption code?
Where can I get the decryption code right now? I am desperately in need of it.
I would like nothing more than to be able to satisfy
your request right now.
I lost the original of one of my scripts months ago and
have been unable to update it .
I just saw it as a shortcut to reinventing the wheel.
Miscellaneous.
What about AML (Arc/Info) scripts?
The same algorithm for decrypting Avenue scripts also
works on encrypted Arc/Info amls.
Here's how to verify it.
|
