Amiga.org
Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: AMIGA-FAN on August 18, 2004, 12:14:10 PM
-
Hi everybody, in a project I have under development, there are, as part of it, several (rather complex) AmigaDOS scripts that I need to execute.
These are mainly compilation tools for different comnpilers in order to build up a full SW program. Once completed, this project might well become a commercial product. Considering that these scripts are rather complicated, to avoid the possibility of them being modified mistakenly, was wondering if a compiler exists for AmigaDOS scripts (particularly for AmigaOS 3.9). I can't translate all those scripts into AREXX scripts (for which different compilers exist) also because of the different characteristics between the two languages. But I would really like to be able to translate them into executable and unmodifiable files instead.
Thanks in advance for any feedback.
-
Sorry, I've only heard of UNIX shell scripts having compilers. I don't think AmigaDOS supports compiling shell-scripts. :-(
-
AmigaDOS scripts always execute commands (either resident or external).
Shell reads the script file line by line, and executes lines linear. The only change of flow happens by IF and SKIP commands, IF skips to matching ENDIF if condition is false, and SKIP either skips forward or backwards.
Generating binary from the script doesn't make any sense.
-
Sorry but in my opinion it does make sense: even normal programs do
contain if condition and conditional branches for instance and DO GET
compiled. The purpose of compiling shell scripts is to make them quick
at running and unmodifiable by unexpert users that only need to work
with those programs, without necessarily knwoing what's going on
behind. There are also copyright issues involved: a good reason for
making compiled programs is TO HIDE source code to the user and the
alike.
Also, with shell-scripts that use internal (or external) AMigaDOS commands it is possible to achieve things that would be a lot more complicated to achieve with a dedicated (custom) program written,
for example, in "C". This is because at shell-level we use already-made (AmigaDOS) programs, therefore leaving behind all complexities that would have to be dealt with when writing a custom program that does the same things a shell script does. I have written several shell-scripts, some of which counting several hundreds lines. What these scripts achieve in a few hundreds lines would require thousands of lines of "C" code, not to mention the time required to develop such programs. So, if an AmigaDOS compiler existed, that, in my opinion, would be a great help for the Amiga SW development for particular applications, like mine.
-
Why not use BlitzBasic, Amiga-E, C++ or other development applications? They use compilers to finish your work. I find BlitzBasic easier to use not to mention expandable. :-)
-
I've never seen a batch-file compiler for AmigaOS, unfortunately. Isn't there a small basic-like language with the possibility to execute CLI-commands?
-
@AMIGA-FAN
Sorry but in my opinion it does make sense: even normal programs do contain if condition and conditional branches for instance and DO GET compiled.
Yeah, but AmigaDOS scripts are no way normal programs. Shell has no DO GET or other direct loops anyway, you need to use LAB, IF and SKIP BACK.
The purpose of compiling shell scripts is to make them quick at running
Minimal time is spent on flow control. 99% of CPU time is spent on actually executing the commands.
Also, if you want 'execute' command to work the script MUST be executed from a script file as usual.
To get this thing going without a script file you'd need to implement 100% shell emulator, with emulated resident commands (if, else, endif, skip, lab, echo etc etc) and execute. And it would still be only marginally faster, as most of the time is actually spent on the external commands. It's not worth it.
-
Using a BASIC-like language capable of executing ANY DOS command
(which is one of my main issues) would be a possible solutionn, but
that would add more work at development phase. Nevertheless, if the
newly written program using this BASIC-like language allows for
source compilation, then that is what I'm looking for, otherwise I
would be stuck with the same problem, that is to avoid possible
modifications (either voluntary or not) to the source code AND to hide
my source code that I would want to keep undisclosed.
-
My scripts serve to the development of Realtime SW applications and
implement a very compilcated Realtime SW platform. Therefore perform
rather complicated operations, such as uniform SW compilation of
source code (in "C"), application building tasks, source code control
etc. A Realtime Scheduler is also under development and it's all part
of that package. I'm not going to further illustrate this here but I
can assure you that these script-based tasks are VERY complicated and
it would really be wonderful if I could protect this software ("C"
source code WILL be protected ;-) indeed) as well, but the main
purpose here is to avoid unvoluntary modifications (by a user) to
these scripts that would very likely cause malfunctions if one doesn't
know what is doing.
-
AMIGA-FAN wrote:
Using a BASIC-like language capable of executing ANY DOS command
(which is one of my main issues) would be a possible solutionn, but
that would add more work at development phase. Nevertheless, if the
newly written program using this BASIC-like language allows for
source compilation, then that is what I'm looking for, otherwise I
would be stuck with the same problem, that is to avoid possible
modifications (either voluntary or not) to the source code AND to hide
my source code that I would want to keep undisclosed.
Why not just write a new "Execute" command that can decript and execute encripted script files?
-
@Matt
That would seem a more obvious solution. Any kind of compiled AmigaDOS script would ultimately have to call DOS commands etc and someone would be able to pull the thing apart anyway, unless he actually intends to include the DOS commands he uses into the exe that is. However, I would be doubtful of the legality of that.
My advice would be to simpy write ones own simple scripting language that can be compiled into a binary form readable by some simple interpreter. It could create its own process and IO and call system dos commands if that is essential (via C's system() function or whatever).
-
Why not just put the entire script into a C string constant and Execute() it ?
Bye,
Thomas
-
@Thomas
Aye, there is that :-)
One could also encrypt a string with a simple proggy so the included constant is encrypted. It can be decoded at runtime and Execute() an as you describe. That way its virtually immune to basic reverse engineering.
-
>>> However I would be doubtful of the legality of that.
Legality? If you can put together simple DOS commands or whatever and
build a complex shell-script that you can use without copyright
issues, why would you not be able to do the same thing from within an
executable file, i.e. a binary, obtained by just compiling this
script? You are just making use of DOS commands/external programs that
you are eligible to use as a owner of the AmigaOS. At least this is my
opinion.
-
@AMIGA-FAN
Legality?
You can't redistribute AmigaOS parts, such as C commands ("unless he actually intends to include the DOS commands he uses into the exe that is. However, I would be doubtful of the legality of that."). You couldn't for example upload such compiled binaries to Aminet.
-
Why not use AREXX for your scripts, and then compile them with....
"REXECUTE" the comlete Arexx Compiler by Horizon Software ;-)
-
AMIGA-FAN:
If the script is very complicated, post it here..maybe it needs to be re-written. j/k. :-)
-
AMIGA-FAN wrote:
>>> However I would be doubtful of the legality of that.
Legality? If you can put together simple DOS commands or whatever and build a complex shell-script that you can use without copyright issues, why would you not be able to do the same thing from within an executable file, i.e. a binary, obtained by just compiling this script? You are just making use of DOS commands/external programs that you are eligible to use as a owner of the AmigaOS. At least this is my opinion.
Sure, as long as the DOS commands you use are not *physically* included into the binary of your executable.
This would mean your executable contains object code you have no right to redistribute.
Making a compiled script that simply calls dos commands from their usual location (in other words exactly like a normal script) would be fine.
As Thomas suggests, you could simply have the script as a string constant within a C program and execute it. If you want to ensure nobody can reverse engineer (by viewing a hex dump of your exe and seeing the string inside), you could encrypt your scripts with a small program and then use the encrypted data in your executable. It would decrypt the text back to a normal string and then execute it.
-
>>> You can't redistribute AmigaOS parts, such as C commands...
In fact I'm in no way willing to do that sort of things... What I want
to achieve is EXACTLY what a shell-script does, i.e. executing
commands, either internal or external, the same way a shell-script
does but possibly from within an executable (binary) file. AmigaDOS
commands would simply be executed from their location, as well as any
other tool/utility that anyone can use in his own scripts.
Incorporating a binary code for execution in my executables is far
beyond my knowledge anyway and complicating things beyond what is
necessary and, in any case, a practice which is obviously breaking
copyright laws, I'm perfectly aware of this. Anyway, to cut things
short, I might consider switching to AREXX if porting those script is
not gonna take a considerable amount of effort. At least a compiler
for this exists. I will go through all other posts here regarding this
topic and see what is possibly thye best solution, given the problems
highlighted here. Would nevertheless be very much pleased of any other
suggestions that may come about that.
-
>>> Sure, as loong as the DOS commands ... are not "physically"
included into the binary...
In fact they will not be. As mentioned in my other post, the DOS
command will be simply executed, NOT included in my binary. Including
a binary into my executable is something far beyond my knowledge and
even if I DID know how to achieve this, I would NOT do that as this is
a breach of copyright. Encripting commands into a string to avoid
"reverse engineering" is a good suggestion here. ALl I do need now is
to have a compiler in the first place or find a way to compile
scripts, either AmigaDOS, AREXX or whatever. Then will think about how
to encript the commands themselves, mainly to hide all the technical
aspects of my software.
-
Using AREXX is something I thought about. Problem is I need to re-code
all that stuff and this is something I would rather avoid as the code
I wrote is already functioning as it is and it consts of several
hundreds lines of code!. To save time on my work it would have been
great to have an AMIGADOS script compiler. If that doesn't exist, well
will be forced to find other solutions... unfortunately ;-(
-
@Karlos
As Thomas suggests, you could simply have the script as a string constant within a C program and execute it. If you want to ensure nobody can reverse engineer (by viewing a hex dump of your exe and seeing the string inside), you could encrypt your scripts with a small program and then use the encrypted data in your executable. It would decrypt the text back to a normal string and then execute it.
And this could be broken with simple SetFunction to _LVOExecute, or even SnoopDos.
Or by just simple "set echo on", if you're afraid of patching. :-)
-
>>If the script is very complicated, post it here... may be it needs
to be re-written.
No, it's complicated in what it does, not in how it does it, which
would mean my code is badly written.. I don't think it's badly written
but I DO think that it would be a lot complicated to write several
(custom) "C" programs each devoted to a specific task. As I said in my
previous post, a shell-script of a few tens of lines could mean an
equivalent "C" programs of several hundreds lines of code! So the
overall effort is greater.
-
>>> ... SetFunction to _LVOExecute .. or even SnoopDos
Mmmhh, interesting to know. I guess there's no easy way to avoid such
"intrusions" in somebody else's code....
-
@Piru
Well sure, but I did only say "basic" reverse engineering (somewhere) ;-) It would at least eliminate the problem of hex editors and so on.
On the face of it, there is no way to absolutely safeguard code from a determined reverse engineering effort. Even if you wrote your own dos interpreter so you didnt have to call Execute(), people could simply reverse engineer the program itself to find out what it does.
-
The initial concern was to prevent the user from accidentally changing the scripts. Any effort to reengineer the compiled program cannot be called accidentally.
So saving the script as text in an executable, perhaps calcuclating a checksum to inhibit any changes, will surely prevent mistaken changes.
You won't keep anybody from reengineering the program if he really wants to.
Bye,
Thomas
-
>>>REXECUTE, the complete Arexx Compiler by Horizon Software.
Do you know what is their WWW address? I'll have a look at their compiler.
Thankx
-
@Thomas
As I mentioned in my other posts, the scripts have been designed to provide the user with a comprehensive set of tools designed to allow for the development and building of Realtime SW applications, in other words the user of this product will (very likely) mainly concentrate on the development of Realtime SW applications rather than breaking into their code (therefore would not care much about how application building is achieved) by mean of this Realtime SW Development platform, which includes, among other things, all the development tools and the Realtime Executive (core scheduler). A Realtime Debugger is also on the to do list but probably the SAS/C Debugger can be used too, with all the features I need (if it is possible to access data and code in realtime). In fact, what's the point in rewriting a Realtime Debugger?). So, there's no much point in breaking the code of the building tools themselves provided with the product, which only serve, as I said, to build up realtime applications. The development of these applications is left to the user. But would be nevertheless advisable to prevent the user modifying these tools (voluntarily or not) in the first place as they are very "critical" in what they do and are primarily something like standard tasks that need not be modified / changed / rewritten by anyone.
-
@Amiga-Fan
As stated, there is no way to counter a concerted reverse engineering attempt. All you can do is to make it more or less difficult.
Accidental changes to a script are trivial to prevent. Thomas' suggestion of putting the dos script into a C string and executing it from within your compiled binary is a very practical way to accomplish this.
To prevent casual "I wonder how this script works?" attempts, encrypting the string (and decrypting at runtime) would suffice.
This is possibly a better approach than Rexxecute since you don't have to rewrite your dos scripts in Arexx. Also, good as Rexxecute is, it is not truly a compiler - as far as I know, at least - it simply wraps arexx scripts into an executable loader in much the same way as we are describing here. There was something on aminet ages ago (written itself in arexx) that did pretty much the same thing. I can't for the life of me remember what it was called, however.
Lastly, someone with the required expertise and determination to find out how any code works, will. You simply cannot prevent this.
-
@Karlos
>>> ... All you can do is to make it more or less difficult.
Precisely.
>>> Accidental changes to a script are trivial...
Well, those scripts are provided to accomplish tasks that the user needs not modify. They are provided as they are and do not need modificationa whatsoever. The purpose here is precisely to avoid, mainly, accidental modificationa that might cause errors or malfunctions that would ultimately cause problems in the compilation process and, therefore, a complete failure in the application building process (for instance) and/or software configuration control process. It's just a method of protecting the final user, in the first place. I would rather worry about other sort of things, i.e. breaking into the core scheduler code to find out how it works....