The Lisp Decompiler Project (LPD) - removed
Anne Brown
the Autodesk Lisp newsgroup. Please do not repost the
information.
--
Anne Brown
Manager, Moderator
Autodesk Product Support Discussion Groups
Discussion Q&A: http://www.autodesk.com/discussion
Tony Tanzillo
belongs, which is solely with Autodesk, for allowing
its customers to believe that .fas/.vlx is "secure",
when in fact, they knew all along that it was not, and
that it was just a matter of time before a decompiler
was available.
"Kevin Nehls" <kevinn at safeworks dot com> wrote in message
news:ABA1644DF25B84A0...@in.WebX.maYIadrTaRb...
> Why do you want to do this? NOBODY here want this.
>
> --
> Kevin Nehls
>
>
> "Dead_loop" <dead...@msn.com> wrote in message
> news:f0f54...@WebX.maYIadrTaRb...
> > Hello World,
> > I'm about to write a fas-decompilier.
>
> <snip>
>
>
James Maeding
maker. I don't think its autodesk's doing though, I wish there was a more secure (than before this thread) compilation
method though.
James Maeding <jmae...@nettaxi.com>
|>Wait a minute, was the decompiler sucessful or not? Are vlx's and fas's safe?
|>I hope Autodesk tells the truth here because they will be embarrased real quick if they don't (not by me though, I would
|>not have asked if I knew).
|>Are we going to see some interesting code pop up now?
|>thanks
|>
|>"Tony Tanzillo" <tony.tanzillo at caddzone dot com>
|>|>I agree, but we need to put the blame where the blame
|>|>belongs, which is solely with Autodesk, for allowing
|>|>its customers to believe that .fas/.vlx is "secure",
|>|>when in fact, they knew all along that it was not, and
|>|>that it was just a matter of time before a decompiler
|>|>was available.
James Maeding
Civil Engineer/Programmer
James Maeding
I hope Autodesk tells the truth here because they will be embarrased real quick if they don't (not by me though, I would
not have asked if I knew).
Are we going to see some interesting code pop up now?
thanks
"Tony Tanzillo" <tony.tanzillo at caddzone dot com>
James Maeding
Civil Engineer/Programmer
Tony Tanzillo
you, because the simple fact is that no bytecode based
programming language is reasonably safe.
It has nothing to do with whether it is Visual LISP,
Java, or MSIL, the simple fact is that bytecodes are
bytecodes, and from now to the end of time, bytecodes
can be decompiled to editable source code.
'Decompiled' does not mean reproducing the exact same
original source code, but it does mean producing source
that has the exact same structure, and which can be
recompiled back into the same bytecodes. The primary
difference between the original and reconstituted source
code produced by a decompiler/disassembler, is that the
latter uses different software-generated symbols for all
variables and function names.
That means, that while the symbols you use for
variables and functions cannot be restored, the
basic source code (using symbols generated by the
decompiler) can be reconstituted, and when compiled
again, runs exactly the same as the original source.
Let's not forget that the whole point to Visual LISP,
was to act as countermeasure to the threat from the
AutoLISP-compatible IntelliCAD. IOW, the purpose of
purchasing Vital LISP and distributing it with AutoCAD
was to "pollute" the existing AutoLISP standard, and
thereby provide you with the means to create LISP based
applications that would not run on IntelliCAD.
It had nothing to do with giving you more API power,
or a more "secure" way to deploy your applications,
especially considering how many Visual LISP programmers
have succeeded in using Visual LISP's highly flawed
reactor implementation to do little more than crash
AutoCAD or corrupt drawing files.
"James Maeding" <jmae...@nettaxi.com> wrote in message
news:379siugtgdlerf4c3...@4ax.com...
Jim Short
was just a backward desert rat afraid to venture into advanced techniques,
that when mastered correctly, would not crash AutoCAD.
Jim
"Tony Tanzillo" <tony.tanzillo at caddzone dot com> wrote in message
news:59114BD5413F7C2C...@in.WebX.maYIadrTaRb...
Tony Tanzillo
>
> There is always the good and the evil it only matters on the point of
view.
> Don't try change the good or the evil just turn your point of view - you
like.
>
While I do not agree that a decompiler is a good thing
for hard working people who have invested their skills
in developing Visual LISP applications, for those few
crustaceans that use the Visual LISP compiler as a means
of concealing their plagiarism of other people's work, I
couldn't think of a better way to reward them.
I also firmly believe that a Visual LISP vlx/fas decompiler
is a lot like death.... an inevitable certainty. It's not
a question of "if", but rather, "when". A working decompiler
will become a reality sooner or later, and what it will do,
is serve to demonstrate that Autodesk was playing a bit too
fast and loose with the facts with its claims that compiled
Visual LISP was secure.
Lastly, I would like nothing better than to discourage the
continued use of Visual LISP in general, mainly because I
think it sucks. If a decompiler will help to give some of
these die-hards a good swift kick in the fanny, and inspire
them to shed their LISP security blankets, and start using
a real programming language, I may sign on.
If you need a few test .vlx files, I can recommend a site
where you can find some <chuckle>.
Well, time to duck and run :-)
Anne Brown
Please do not continue to post into the Lisp/Customization group
concerning a lisp decompiler. I have edited out the messages with
your zip file to date and other references to how it works.
Future messages in such a vein will be fully removed.
Continuing to post is not in the interest of these newsgroups or
of those who write code and post it here for use.
--
Anne Brown
Manager, Moderator
Autodesk Product Support Discussion Groups
Discussion Q&A: http://www.autodesk.com/discussion
"Dead_loop." wrote:
>
> For all emailing me asking me to send me "my decompiler" (snip)
Reini Urban
> I really don't care what anyone from Autodesk tells
> you, because the simple fact is that no bytecode based
> programming language is reasonably safe.
>
> It has nothing to do with whether it is Visual LISP,
> Java, or MSIL, the simple fact is that bytecodes are
> bytecodes, and from now to the end of time, bytecodes
> can be decompiled to editable source code.
Your whole post trying to discredit Visual Lisp security and bashing
autodesk makes no point,
because disassemblers for MSVC++ do exist for years now, whereas FAS
decompilers don't exist so far and it is very unlikely that they
will ever exist. I argued that for years and it still holds true.
VLX is still safer than ARX. Everybody knows the i386 instruction set
and the MSVC run-time libs, nobody knows the vlisp LAP instruction
set.
Everything can be decompiled or disassembled, but one thing is just
a little bit easier than the other, even if LAP is more high-level
than i386 assembler.
see http://groups.google.at/groups?q=lisp+decompiler+rurban&hl=de&lr=&ie=UTF-8&oe=UTF-8&selm=3510335D.D3C9865B%40sbox.tu-graz.ac.at&rnum=4
and http://groups.google.at/groups?q=lisp+decompiler+rurban&hl=de&lr=&ie=UTF-8&oe=UTF-8&selm=351564d3.4346750%40judy&rnum=8
Other things tony said in his post are even technically incorrect,
because if you don't link and drop your symbols (full optimization)
you do get at the symbols (functions and globals), same as in the
visual basic "decompiler". the problem is to understand the lap code,
not creating meaningful symbolnames for the arguments as with other
decompilers.
> Let's not forget that the whole point to Visual LISP,
> was to act as countermeasure to the threat from the
> AutoLISP-compatible IntelliCAD. IOW, the purpose of
> purchasing Vital LISP and distributing it with AutoCAD
> was to "pollute" the existing AutoLISP standard, and
> thereby provide you with the means to create LISP based
> applications that would not run on IntelliCAD.
Nonsense.
Everybody can write inefficient vl- workarounds, like I did.
It was an performance improvement and feature enhancement.
--
PS: my site is still down for some more days. they are relocating the
servers.