Lisp encrypt tool with ver 11...security
The "vlx-like" encryption tool you can download for ver 11 (at least) seems to be close to the old lisp encryption tools I remember.
The thing I remember the most was finding a decompile tool easily. Those were not vlx files like the VLIDE of acad makes.
Can anyone comment on the security of the compiled lisps the Bricscad tool makes.
Note to the developers - vlx format of autocad has not been cracked. It would be a sore mistake to lead people into thinking the Bricscad one was secure, if its similar to the old one by adesk.
So I guess I am asking if the Bricscad one is based on same stuff the vlx compiler is, if that is possible to answer. thx
Comments
-
Dear James,
as I developed both the DEScoder.exe and the Lisp engine,
I guess I'm the partner here :-)
First of all, the Acad VLX/FAS container+encryption has nothing
to do with very early Lisp encryption - there were indeed several
decryption tools to decode the PROTECTED files.
But VLX/FAS encoding is quite different from that - and as you mentioned,
it is not "cracked" (but there are indicators that there are existing tools
for that - but not in our reach).
The DEScoder.exe provides encryption using the BlowFish algorithm -
for sure, very safe :-)
Additionally, the "VLX-like" container feature is not about "encryption",
but packaging many Lisp, DCL and Text files into a single (encrypted)
Lisp file.
I hope this answers your questions ?
Many greetings, Torsten0 -
Hi Torsten,
Thanks a bunch for the reply. I think this encrypter you wrote is more important than Bricsys may realize.
I know several third party lisp programmers that are waiting for an equivalent of the VLIDE, with the critical feature being compile to vlx.
Its a bit confusing that the format we compile to with your tool, is not fixed. It looks like we can type in any extension.
So it leaves us wondering how "official" it is. What you have done is actually superior to the VLIDE, as we can "batch compile" programs using your console prog.
Only sticky issue is we generally do not put all lisps for a program, in one folder. We have a folder for lisps containing functions used in all programs - a library if you will, and the program specific ones in that program's code folder. It would sure be nice if we could specify a text file with lisp (and other type) file names to include.
Are there any plans to make an editor that allows debugging? That would be the other critical feature of the acad vlide.
thx
0 -
Dear James,
thanks for the flowers :-)
In fact, DEScoder.exe is "official" - as it is distributed with Bricscad.
Nevetherless, it is more "privately" maintained ...
The latest build is always at www.LT.Extender.com - but I hope, that Bricscad App Catalogue
will soon get a "Developer Tools" branch, so I can pusblish my DEScoder package there -
including documentation etc. ... I will care for very soon.
Indeed, the file extension for DEScoder.exe "compiled" file is free :-)
This is by intention - so you can name the file as you want.
Bricscad, and also the Lisp engine, always "looks-into" the file to be loaded / apploaded etc.
Then it is decided how to load the file ...
Just the idea behind :
using Acad, you can "compile" a *.fas or *.vlx file, DEScoder.exe by default creates a *.des
file ... then, instead of using
(load "name.vlx") and (load "name.des"), the Lisp code can specify
(load "name")
without extension ...
thus, Acad will search and find the fas/vlx named files, Bricscad will find *.des with priority.
In result, developers can make a single installation package, and have platform-specifically
encrypted files side-by-side in same installation folder ...
Console compilation :
for clarification - the DEScoder.exe is also commandline enabled ...
but the "encryptgui.exe" and "encryptconsole.exe" are the encryption tools provided by Bricscad
since many years, but does not allow VLX-like containers - my DEScoder.exe provides the VLX
container feature, and also commandline support.
Of course, Lisp engine loads files from both encrypters :-)
(Under Linux, only the files encrypted by DEScoder.exe can be loaded !)
"Include" feature :
indeed, that might be helpful ... most important, the DEScoder project file needs to remain
Acad compatible; meaning, DEScoder.exe could interprete the "include list", but the project
definition will store the names of all files then, not the "include list" filename.
Is this your intention and/or acceptable ?
Also, please note that DEScoder completely supports Drag + Drop - so you can easily drop all
the files into the program windows.
Debugging :
yes, I have an idea to develop a Debugger PlugIn for UltraEdit editor ...
I have no ambition to develop an editor - UltraEdit is hard to beat :-)
Currently, I have complete AutoLISP language definition file prepared for UltraEdit - incl. VLA/VLAX/VLR
functions (only the COM constants are not yet added)
Based on that great editor (also available for Liux !) I think it is the best approach to develop a
debugger plugin, because that is what most people will need ... hard to say when, but I will start that project.
Many greetings, Torsten0 -
Correct link ;-)
0 -
I see, .des is default, but files are read before loading. I have adopted the convention of progname.R17.vlx for my versioned progs, but also use OpenDCL for dialogs so keep my routines for each acad version separate.
I had not realized your descoder.exe was different than the encryptconsole.exe, you saved a ton of confusion by clarifying that, thx.
For the include list, I simply want to specify files to compile, not folders. Its dangerous to assume all files in a folder should be compiled, as any temp files I make might get included.
I am not sure what you mean by a "project definition" though. Maybe you are referring to how the VLIDE has projects (prj files that provide a list of files in a side window), then separate vlx make files (prv). The two are actually not related, but its handy to set up a project for each program. The project file idea is only relavent when talking about the VLIDE, of course, but you are suggesting use of Uedit (which I love too). Is there a way to have UltraEdit give a "project" window, showing the list of files for a project? Some people do not use projects in the VLIDE, so may not realize the handy feature it is.
We need to write up a tutorial, I know several CAD Managers in Southern California that are interested in this.
0 -
Dear James,
here is more for clarification :-)Originally, there were lots of requests to re-use the AutoCAD VLX projects (prv + prj)
to be used for our (DEScoder.exe) VLX-like container support - this is perfectly what I prefer :
to allow minimum efforts ....
Thus, DEScoder.exe uses AutoCAD VLX/FAS project definitions - those define the files to
be used for "compilation".
Many developers already have such project definitions for their AutoCD target - these projects
define all the files to be included; a one-time job.
DEScoder.exe allows to use them . and also projects created by DEScoder are saved in that
AutoCAD format.
So what we did is to use those AutoCAD VLX/FAS projects even outside VLIDE.
I assume, such project definition is what you refered to ?
Once created, you can simple rebuild the entire project, even on command line.
You can download the DEScoder package incl. documentation from my website
http://www.LT-Extender.com
Btw, the current UltraEdit has perfect project support, also a "Files" window with
open files, active files, disk explorer etc. ... have a close look into :-)0 -
Wow, you've already done it. If you only knew how long I have wanted the ability to change a lisp in my library, and recompile my 20 or so programs.
Too cool. Ii will be trying it out today...thx again
0 -
I am reading the help file now, that explains everything. Didn't mean to make you repeat it, i had the encryptconsole.exe stuff before, which only has a readme.
very exciting stuff!
0 -
Thanks for flowers again :-)
I will probably update next days, some minor GUI fixes.
And I will also review documentation ... and will try to get a "Developer Tools"
branch into Application Catalugue - then, developers will easier find it.
It is probably worth to mention, that (under Linux), only those DEScoder.exe
encrypted files will be loaded - of course, including VLX-like container support.Many greetings, Torsten
0 -
It's very interesting what you are talking about. Thanks for informing about DEScoder, I already downloaded and will look at it. Torsten, I also have a list of questions regarding LISP in Linux to you and .des support was the first one. So, for now one question is less
0 -
Quote Torsten: "yes, I have an idea to develop a Debugger PlugIn for UltraEdit editor ..."
Thank you, thank you and thank you. That would be super awesome. Please dont hesitate to do it.
0 -
Hi Torsten, are there any news on the "idea to develop a Debugger PlugIn for UltraEdit editor"?
Regards, Stephan0 -
Dear Stephan,
yes, that wish for debugger arises all the time :-)
Simply, I did not find the time yet to start development on this topic ...
but I hope to start with that subject after V15 has been published.
Many greetings to all !0 -
What does that kind of effort involve? I remember the vitallisp that adesk bought to make vlisp.
Is it setting up events an editor can hook to using arx? If you make something, will it be limited to ultraedit? If yes, can you explain why.
I'm not a C programmer, just lisp, vb, .net and so on. I think Tony Tanzillo once tried to insult me saying "Oh, you only work with managed memory languages...".
Either way, curious what making a debugger involves.
0 -
Dear Stephan,
yes, that wish for debugger arises all the time :-)
Simply, I did not find the time yet to start development on this topic ...
but I hope to start with that subject after V15 has been published.
Many greetings to all !That's really good news Torsten.I assume any work you do for UltraEdit will work equally well in UEStudio ? I agree, it's a very nice package.Regards,0 -
Dear James, Dear Kerry,
about that plan for a debugger module ...
The idea is really to have a plugin for UltraEdit editor, which can communicate with BricsCAD and its Lisp engine (shared memory etc.),
to control the behaviour of the Lisp evaluator ...
and it is indeed similar to VisualLisp - with the difference that VisualLisp (the VLISP command) is both an editor and debugger in one
environment ...
Of course, there is no sense to develop a new editor, there are already plenty on the market ... but what Lisp developers always ask,
is the possibility to debug Lisp code when running - hence, I think having a debugger plugin for UltraEdit would be fine.
Why UltraEdit ?
It is (one of) most powerful programming editors, and it has a kind of API ...
even more, as the UltraStudio package (also from IDM) shows, it offers any necessary possibility (debug, output windows, and related stuff).
It is a commercial product, but I think, the editor is worth every little penny of its few 60...80 Euro/USD as it costs.
I already added some extensions for UltraEdit (see "Lisp Developer Support Package"), which include full syntax highlighting, support for
function list window, and few more.
Regarding UEStudio . yes, I would also expect that this debugger plugin will work here as well :-)
Finally, about programming languages : imho, the only point that matters is simply, how it fits the context ... and Lisp is the perfect example
to have one code to work in all environments, without recompilation ... the efficiency and compatibility is unbeaten.
Many greetings !0
