Note: Issues with Runtime distribution and demos

[Chet Sapino]

Most of you veterans know this, but some new users may not.

If you distribute an application as say a 30 day demo (you need to code for this) with the runtime to a particular customer, a person who has the A5 developer will be able to grab the runtime and use it for himself. The SN is displayed on the Help about, and also found in the registry, and perhaps in an unencrypted text file called license.key that you may have furnished with the demo to allow it to run without entering the license number. All the runtime files are also included when you install a runtime derived database using the A5 Installer.

So all a user has to do is launch alpha5.exe out of your install directory and get the SN from the Help |About. Then he gets the registry information, duplicates the registry stuff, and away he goes with your runtime.

I don't like this scheme of having the license number plastered all over the place in the runtime Help|About, or in a readily available license.key file that can be read with notepad. With some additional programming, Alpha could get rid of all this stuff and still require a license key from the developer that is hidden from the end user, even in the registry.

In addition, one has to code some trick stuff to prevent the user from reinstalling your demo say beyond a 30 day time out. I found this quite a challenge, but it was fun coming up with a strategy to outwit the hackers.

In addition, a developer must include security in the form of a Master Password on his database so another developer doesn't grab his entire database from a demo. The end user could also buy A5 and grab it unless it has a Master password assigned.

This means that every time a user opens up your product, he has to enter a password (= the Master password if you want to protect your source code). So we have to put security on every table, enter in some various users with different security levels, and provide a full security system to the end user whether he needs it or not. No problem, but it may be a hassle for end users who have no need for security.

Correct me if I am wrong on this.

[DaveM]

Re: Note: Issues with Runtime distribution and demos

chet,

You are right.

You can put all your scripts and functions into an .aex file and it will no longer show on your codes tab.

I tie the application to the computer where it is first installed.

The end user has to have a code to open the application for the first time with my own registration system.

The runtime installer is not sent as an install. If it is sent as an install for some reason, my app destroys the file on first run.

I do plant hidden files and other stuff on the first run or the install.

Most tables are encrypted.

All references to Alpha are done away with as best I can. Alpha.exe is renamed. I use another .exe file to start the application.

I built my own security and log in system(for the ones needed) before Alpha supplied one.

There is more.

.

There is more.

[CALocklin]

Re: Note: Issues with Runtime distribution and demos

In addition, a developer must include security in the form of a Master Password on his database so another developer doesn't grab his entire database from a demo. The end user could also buy A5 and grab it unless it has a Master password assigned.

This means that every time a user opens up your product, he has to enter a password (= the Master password if you want to protect your source code). So we have to put security on every table, enter in some various users with different security levels, and provide a full security system to the end user whether he needs it or not. No problem, but it may be a hassle for end users who have no need for security.

Just another viewpoint:

I guess it depends on your outlook. Personally, I found the Master password to be so annoying that I never use it anymore.

Putting a master password on your database primarily protects the data. I seldom worry about protecting my user's data unless they want it protected. For the data that does need to be protected - typically credit card info and user login info - I simply encrypt/decrypt the data as I read/write it. (Credit card info is actually required to be encrypted in case someone gets an unauthorized copy of the data file. I'm not sure if it's a federal law but, based on the info I've read, I'd hate to have someone get a copy of any data from an app I wrote that had unencrypted credit card info.)

I see no benefit in protecting my layouts with passwords.
(A) The user can see what they look like anyway so if they want to copy the appearance, it's pretty hard to stop them.
(B) Using a password on my layouts means I have to keep entering the password during development. This is a waste of my time to protect what someone can see every time they use the form anyway. (Especially when using my AIMS App Analyzer that automatically opens each layout to look for scripts and expressions. There is no way to 'save' the layout password so it has to re-typed every couple seconds as each layout is opened.)
(C) Layout passwords aren't very secure.
(D) There are better ways to protect the code for button and event actions anyway. (read on to see what I do about the code on layouts)

I feel that the one really important thing about any app is the code. THAT I PROTECT. Of course, simple code on a button that just does something like "parentform.close()" isn't worth protecting but any button action that requires significant code is simply changed to a function call or script_play() that calls code I've saved in the Code tab. Any straight Xbasic code in the code tab can be protected by adding a single password line as the first line in the code - like this:
'password mypassword

Since I've gotten to where I never use Action Scripting anymore (always ended up having to tweak it anyway), it's a simple thing for me to just add the line to my code. Unfortunately, password protection isn't so easy to do with Action Scripting using standard A5 methods. For those who use Action Scripting and have my AIMS Grab Bag (just a "grab bag" of various developer routines) listed on my addons page, there is a "Script Passwords" action that will add or remove passwords on ANY code saved in the Code tab including A/S code.(Of course, you can only remove passwords if you already know the password you want to remove!) The only drawback in the case of A/S is that you need to rerun the routine every time you edit an A/S. However, using my routine it takes about 8 seconds to set the password on 600 scripts and functions so, other than remembering to do it, it's not really a big deal.

I also have an AIMS Registration addon (also listed on the addons page) that has the following options:

• Limit the number of users.
• Create a registration number that expires on a certain date. (or unlimited)
• Create a registration number that is keyed to a specific computer name.
• Time limited trial version. (30 days is the default if used)
• Record limited trial version.

And, when the trial period is over, the user can be allowed to still open the app if they want to see what it does. Sometimes potential users may not decide to use your app right away then want to take another look months later when the need arises again. However, even though they can open it, anything else can be restricted. Typically I simply prohibit adding records to key tables but any action can be restricted.

Since you've already done some work with creating a registration routine, you can imagine that a generic routine like this means that it is not one of my $19 addons. It took many, many hours to create. I'm charging $150 for this one and will probably start adding an "assistance fee" for those who need the assistance. Some people have been able to use it with very little help but a couple others have used well over $150 worth of my time asking for help. (Potential buyers must contact me before purchasing. I don't want people ordering it who don't understand what it does and the basics involved in setting it up.)

REALLY IMPORTANT NOTES:
1. This is THE most important thing to remember about passwords: The password on code stored in the Code tab is the ONLY really secure password. Any other password on any button or event is easily cracked by an experienced developer! Therefore, if you want it to remain secure, DO NOT use the "code" password anywhere except in the Code tab. [Edit: Since I don't use it, I'm not sure about the Master password. I think that one is pretty secure also.]
2. If you do protect other things with passwords, never put a password on a field rule event. It doesn't do any good - which means that anyone who gets into the field rule editor can simply open a field rule event and read your password.

[CALocklin]

Re: Note: Issues with Runtime distribution and demos

You can put all your scripts and functions into an .aex file and it will no longer show on your codes tab.

Just remember that if someone does get into your Code tab, they can enter their own scripts - such as Autoexec - that will override any scripts by the same name in your aex file. So, it's important to make sure that any registration information is also checked in other places besides the autoexec - or to set something in the autoexec that will cause the app to crash if it isn't set properly. [Edit: maybe 'crash' was a bad selection of words]

Yes, the aex file is probably harder to hack but nothing is 100% secure. I feel that password protecting the scripts/functions in the Code tab is adequate - and less work for me. It also keeps people from "overwriting" what's in my aex file. Of course, there may be things that need more security like secret government projects but I don't plan on writing any of those. The only time I use aex files anymore is for distributing my addons.

Opinions on this vary and I know of at least one person who likes to use the aex file because he feels it makes many updates easier. Personally, the way my updates are created, building a new update file is just a matter of opening Astrum, selecting the already built installer definition, and clicking the Create Install button. Can't get much simpler than that.

[DaveM]

Re: Note: Issues with Runtime distribution and demos

Personally, the way my updates are created, building a new update file is just a matter of opening Astrum, selecting the already built installer definition, and clicking the Create Install button. Can't get much simpler than that

I agree 100% with this.


.

[Chet Sapino]

Re: Note: Issues with Runtime distribution and demos

What installers are everyone using?The a5 installer is a toy!

[DaveM]

Re: Note: Issues with Runtime distribution and demos

I personally use astrum

[csda1]

Re: Note: Issues with Runtime distribution and demos

Hi Chet,

What installers are everyone using?The a5 installer is a toy!

I use NSIS (Nullsoft Scriptable Install System) which is open source software.

...it's important to make sure that any registration information is also checked in other places besides the autoexec - or to set something in the autoexec that will cause the app to crash if it isn't set properly.

I'd actually say it's important to check licensing at a variety of points, when speed is not an issue. It is relatively easy to find the initial jump point around a license check and to hack it without knowing what you are doing, but it is real difficult to do if in many points and many times throughout operation.

[Chet Sapino]

Re: Note: Issues with Runtime distribution and demos

I personally use astrum

I looked at Astrum. Do you have the Pro version?

Does it have the ability to create a desktop shortcut to load the runtime and the database like the A5 installer does?

Some of the installers I have evaluated, cannot create the desktop shortcut properly.

[Chet Sapino]

Re: Note: Issues with Runtime distribution and demos

[QUOTE=csda1;514563]Hi Chet,



I use NSIS (Nullsoft Scriptable Install System) which is open source software.


Does it have the ability to create a desktop shortcut to load the runtime and the database like the A5 installer does?

[csda1]

Re: Note: Issues with Runtime distribution and demos

Hi Chet,

Does it have the ability to create a desktop shortcut to load the runtime and the database like the A5 installer does?

Honestly, did you bother to go to the link page I supplied and even bother to look at it's feature list?

As for myself, I actually run a special Alpha 5 database which has it's own A5 autoexec. That autoexec reads all A5 specific directory path functions it needs, and does a 2nd part of the install process. I don't have to depend on knowing registry locations for the installer, and am insured the process will work with A5, no matter what the version. Within A5, it creates it's own shortcuts as well as doing other initializations I need that are A5 specific. You don't even need to see A5 even visually display.

[Chet Sapino]

Re: Note: Issues with Runtime distribution and demos

Hi Chet,

Honestly, did you bother to go to the link page I supplied and even bother to look at it's feature list?

FYI, I downloaded it and looked at it right after you recommended it so no need to get sarcastic.

Compared to Wise Install Master v8.1 that I have,it is way too much work to create an install. However, there is a problem with Wise and A5. That's why I'm looking for another install system.

[CALocklin]

Re: Note: Issues with Runtime distribution and demos

I looked at Astrum. Do you have the Pro version?

Does it have the ability to create a desktop shortcut to load the runtime and the database like the A5 installer does?

I also have Astrum. I was probably the first to recommend it here - on a message board for one of the previous versions.

It can create shortcuts on your desktop, or in a new or existing shortcut folder, or probably anywhere you want to put one. It can even do it conditionally if you can figure out what conditions you want to have.

Speaking of conditions, you can also set up variables and conditionally show messages, halt the install process (I use that to halt the install of 'updates' if the user doesn't already have a registered version installed), determine which files are to be installed (I use that to install addons to whatever version(s) of A5 the user happens to have on their system), and many other things.

Of course, it can also read and write to the registry, check for existing files, show a read-me file, require certain computer criteria before installing (memory, OS, etc.), show license text and require the user to check a box before continuing, and a ton of other stuff.

http://www.thraexsoftware.com/

[Windstarsoftware]

Re: Note: Issues with Runtime distribution and demos

For those of you who don't know about Cals registration program it is the best. We distribute an application that we sell on the web and Cals tool lets me send a CD od download and requires the user to register the app or it will not let them use it. We have sold a lot of apps written in Alpha5 and without Cal's tool we would have been a the mercy of the user. They could install it on as many computers as they wanted and give it to anyone. When you use this tool (It Seemless) you don't have t worry about people ripping you off. IT happened to me for years and now every use has to register it to get a registration key. The Reg Key is unique to one machine and if the try to install it on another machine they must re register it or it won't work.

It's the best investment I have made so far in selling software.

[GaryRockley]

Re: Note: Issues with Runtime distribution and demos

Hi Cal,

I'm curious, and don't want you to give away any secrets, but how does VM-Ware in this regard factor in?

Years ago, the issues were cloned or copied drives. We inspect for various hardware S/Ns & IDs at initial registration but started seeing more & more VM platforms as the O/S when users would register.

With VM, a dozen users will all report the same IDs (passing the start-up inspections) but could still be running multiple instances on separate workstations.

We came up with a couple of solutions to the VM issue, which seem to work. But I'm always interested in talking to others who face the problem and have solutions too.

Your thoughts on VM platforms would be appreciated.

Regards,

Gary