Question about encryption/creating aex

[Mel Thompson]

Dear People:

I have some generic questions about security options in Alpha applications. Any comments from more experienced members of the user group will be deeply appreciated.

Aex
Creating an aex of all code is quick and simple. Deleting several hundred code snippets manually isn't. Is there a relatively quick way to empty out the Code tab without having to individually delete each item?

Encryption
I need to encrypt our data files (at least the major data files) both for data security and to make life difficult for a mad scientist who has been reverse engineering our product for an "open source" alternative.

It looks as if creating a master password requires using Alpha's built-in login routines. We have our own, which ties into our own permissions system. It appears that we'll have to use the encrypt() functions in code wherever needed. Is this correct? If so, we don't really mind, but more exact knowledge could save us some hours of keyboard pounding.

How big a performance hit does encryption tend to impose on an Alpha solution? Our users PCs range from 500Mhz clunkers to the most modern machines with SATA drives.

Best wishes -
Mel Thompson

[Finian Lennon]

Mel:

Look in the code archive for a posting of mine "Copy and Append" utilities. The utility is pretty easy to install and is one of my own essential daily tools.

In addition to copying, it also deletes i.e. allows you to delete all of the objects referenced in a library, set or table. It works on all A5 objects, not just scripts.

Finian

[JerryBrightbill]

Mel

If you are creating aex files, take a look at Alphabay. I have a real inexpensive little addon that creates an aex, backs ups the scripts and functions and then deletes them.

Jerry

[Brad Chesnut]

Where's the code archives?

I'm with Mel about encrypting the data files and the whole application. I downloaded another persons A5v6 program he had setup as a 30 day trial to see if what I'm about to share could be done. I created a new Application and added the tables & sets from his trial to the new application and could see all of the field rules, set links, etc. I could even go into a design mode on forms, etc. The only thing I didn't see was the Codes. I do NOT want people to be able to do all of that with my application ... how can I lock those things down so somebody couldn't do the same thing to my applications I create for commercial release?

Good thread!

[Kevin G. Timberlake]

Lockout Control Panel

Hmm. Well now you have me thinking. I am with Brad. If there is a way to lockout others from accessing my control panel, I would also like to know how. That could be an issue I never thought of.

[CALocklin]

Security

I'm curious, Brad, was that 30 day trial one of mine? (I don't care if it was.)

I don't take a lot of pains to protect my sets, forms, and field rules.

There are two reasons I don't worry about the forms themselves: (1) people can see the forms anyway so protecting the appearance part of the design isn't really much of an issue, (2) I use my AIMS App Analyzer, which is available on my web page, to test the forms and update script info on a fairly regular basis and I don't want to be entering a password for every layout. Because the routine must open each layout in design mode and the A5 system requires the password to be entered in order to open a password protected layout in design mode, it would be a real pain to enter the password about 160 times every time I wanted to run my analyzer.

I could see more reason for protecting set definitions but I don't see that as a major issue IF a competent person is trying to recreate my application. A competent developer should be able to figure out what sets are needed.

As to the scripts on the forms and field rules, these I protect. Any truly significant script used in the layouts is saved as a global script/function and called from the field rule or layout event.

I'll admit that it would be nice to protect the basic field rules better but I still believe that the basic field rules aren't as important as the special field rule events that I've created and stored in global scripts. I certainly won't get upset if somebody gets in and see my settings for All Caps, or Max/Min values, or even default values - most of those types of rules can be figured out just by using the app. And, if you want to protect a special posting rule or validation rule, you can always write your own and store it in a global script rather than using the built-in solution.

The use of an aex file doesn't really add to the security of your global script IF you use a unique password that is ONLY used in the global scripts. However, as I believe Finian pointed out, the use of an aex file makes it easier to send out minor updates to your application that consist only of code changes. (Some of the best A5 developers have tried to break the password in my global scripts but nobody has done it yet. Other passwords, yes; passwords on global scripts/functions, no.)

FYI: I haven't tried Finian's or Jerry's routines for removing and restoring scripts but I'm curious if they rely on the import/export functions for exporting to a text file. (I'm not sure but I think Jerry once told me his did not.) My own routine doesn't use the built-in import/export routine and a comparison showed that it takes 1 minute 10 seconds to restore my 429 scripts/functions from the text file but only 5 seconds using my routine. The export times are about the same. My routine "exports" the scripts/functions from the data dictionary files and saves them in a dbf table then "imports" them with an append routine.

[CALocklin]

Kevin, remember that locking them out of the control panel doesn't keep them from copying the data files and data dictionaries to another folder and putting them into another application. See my other comments to see my reasons for not worrying a lot about that aspect of the app. While protecting everything would be nice, I'm really most concerned with protecting that part of the app that required the most thought and can't be 'derived' by just using the app - my scripts and functions. Other than the global scripts and functions, most of the experienced A5 developers I know could break into anything else you create.

[Dan Blank]

One sure best way is to do all of your development work, then just before you pack up the app remove access to the control panel when you pack your app with the runtime.

If there is a way to lockout others from accessing my control panel, I would also like to know how. That could be an issue I never thought of.

What I do for one of my apps is it opens straight up to the main menu. The control panel is set to not show. Now on my About Form I have a hidden button that when pushed will open the control panel. That is how I get to the control panel to do development work. It just so happens I have another About Page with out the hidden button. Then just before I create my install, and everything is backed up, I delete the About form with the hidden button. Then using Finian's tool I bring in the other About form. Bingo Access to the control panel is gone.

Now there other things that need to be done, such as removing the F8 functionality, using your own menu bars, and tool bars, etc. That helps keep people out.

And using Alpha's encryption is another security plus!

Dan
Dan Blank Databases, Inc.

[Kevin G. Timberlake]

Thanks Dan and Cal. I believe I have protected it as best as I can with all the advice received in the board. I just worry about my security being disabled by deletion from the control panel/code and the autoexec script being deleted so as to allow for someone to not have to purchase my product. By deleting these scripts, it will make my app FREE, which is not what any of us want. As a truck driver, I see alot of programs out here that have been hacked and being sold for pennies on the dollar. All someone would have to do is get a demo of A5, figure out my access button (hidden) to the control panel and BOOM. It is open. Just a scary thought I would like to put to rest.

[Kevin G. Timberlake]

BTW, after creating an AEX and deleting all the scripts, how do I access the scripts in the aex?

[Finian Lennon]

You can't get at the scripts in an aex file, that's basically the point. So you need to be sure that you keep your development and shipping versions separate,

Someody asked about the code archive .. it's under "Other Forums".

Before creating an install package I copy the development files out into a separate location. I have a routine to empty the tables that should be emptied prior to shipment. I then create the AEX file and delete all the scripts and functions. The utility I use to delete the scripts is available in the code archive. It's the same one that I use to copy forms, reports, scripts, functions etc around my work environment. One use is to delete one, some or all objects of a given type from the data dictionary.

Finian

[Brad Chesnut]

Cal,
No, it wasn't yours. Although if you have a demo on your website I may try to see what I can access in one of your apps.

The class of people I work with (Insurance Agencies) are frugal and would steal a software program in a second. I've worked with them for 20 years. I want to make sure I do everything I can to lock my application down. If your apps, Cal, are tight and I can't access them keeping an agent from hiring a computer person to reverse engineering my application, I'd like to learn your ways of locking it down.

As an added layer of protection, I wouldn't even mind putting a 6 month timer in the application so 6 months after purchase it locks down without a code. (Would have a 30 day timer to let the agency know they need the code)

In the Runtime manual it talks about how to limit the number of records a person could save as a way to create a demo copy. Problem is, a person could just pull that table into a full copy, go into field rules and remove that code. That makes this strategy worthless.

Because I'm not an X-Basic programmer, I do most of my stuff with Action Scripting. It would be easy for someone to pull my stuff into a full copy and create their own application using mine as their foundational piece. Don't want that to happen.

Thankfully I'm early in the development stages of the commercial application I'm writing so I can make the appropriate adjustments to do the best I can to protect my application.

Lots to think about and learn. All of the comments and suggestions have been greatly appreciated.

[Kevin G. Timberlake]

Interesting...
If I have 2 copies.
1) Development
2) Distribution
Make the aex file and delete all in the code section in the distribution copy.
When changes made in the Development copy, make a copy into the distribution folder, go into the panel, create aex, delete all in the code section.
Is this correct? It looks like it would work. But how do I make access to the tables not available.

[Finian Lennon]

Interesting...
If I have 2 copies.
1) Development
2) Distribution
Make the aex file and delete all in the code section in the distribution copy.
When changes made in the Development copy, make a copy into the distribution folder, go into the panel, create aex, delete all in the code section.
Is this correct? It looks like it would work. But how do I make access to the tables not available.

Generally that's what I do. At one point in my last development cycle, I was segmenting my code among 5 external libraries. It became too much of a hassle to maintain and I eventually cut that back to one. I have nothing in the database library except the autoexec and the menus and toolbars. All the other code is stored in a single external alb (-> aex) file.

I'm sure I've said this before, but it doen't hurt to say it again - there shouldn't be any code, apart from script_play commands, anywhere in the user interface. Do this and you can fix just about any post-release issue by giving the user a single aex file. A hurriedly typed "toparent.close()" on a trivial form buried three levels down is not a good reason to have to go through the hassles of transferring a data dictionary and the attendant potential problems that it entails.

I don't follow your comment about available tables .

Finian

[CALocklin]

For what it's worth.... (And this is only another opinion, what's best is what works for you.)

I only keep one copy of my app. I do not have a 'development' and 'release' version. I had too many problems keeping them coordinated. Since my routine quickly removes and restores the global scripts/functions, I don't feel a second copy is necessary. When I'm ready to release a new version, I just build the aex file and remove the scripts, build the new install/update file, then restore the scripts so I'm ready to continue development.

If I really need to test something with the last released version, I can always install a copy using the last install routine I created. This also makes sure that the files installed in my folder are only the ones the customer received. There's no other 'stuff' from my development work that I may have accidentally copied.

Cal Locklin
www.aimsdc.net