Embedding tables in a dll

[grahamrhind]

I currently have a native VFP 6 application, with full interface etc., which batch-processes data using a large number of very large lookup tables. To protect these tables from theft they are excrypted. They are unencrypted into cursors for each process and the process then runs on a whole file of data.

To allow these processes to be used by programmers in other languages I am considering making a VFP dll. Instead of batch processing, this would process and return a single record at a time. The problem with this is that it requires the tables to be unencrypted for each piece of data instead of once per data batch, which is impossibly slow. Is there a way of embedding tables into a dll, or protecting them is some other way that prevents their access by users? Or another solution? Any brainwaves appreciated!

Finally, would a newer version than VFP 6 be useful for any of this dll work, or is there no difference between those versions?

Thanks in advance!

 

[wgcs]

You can mark your tables as "Included" in your project, at which point they will be kept Inside the .DLL, but can still be accessed with the same (relative) path they had during design time (most simply, just in the same directory as the .PJX files).

The FILE('mytable.dbf') will return .T. (though it doesn't exist as a separate file), and you can just: USE MyTable

A determined hacker may be able to get at your tables though through several means: with a decompiler, or by code-injection into your program, or by suspending your program and using the VFP command prompt after the table is open.

But, simply using a development version of VFP, then
SET PROCEDURE TO yourDll
Will NOT let them: USE MyTable
Only code contained in the dll (or injected into it's context, and executed using macro replacement or EVAL() ) can open the embedded tables.

(I mention these, not as hacker tips, but because you should know the vulnerabilities, since you had thought it important enough to keep the table encrypted before. )

- Bill

Get the best answers to your questions -- See FAQ481-4875.

 

[grahamrhind]

Thanks Bill. That's a great help. Any idea whether VFP 7 or 8 are more suited to this sort of work than VFP 6, or it is much the same?

 

[wgcs]

If you have vfp6 already, it's great. But if you have the choice to move to VFP7 or 8, the TRY..CATCH error handling is Well worth it.

There are numerous other improvements, too, but I wouldn't say that anything particularly makes this (storing tables in the DLL) any different.

One thing that is Not well documented is the availability/scope/whatever of the "internal" tables. What I learned through trial-and-error is what I told you in my last post. I rarely put the source .DBF file anywhere other than in the same directory as the .PJX... I'd like to see documentation on how VFP is supposed to handle file paths of internal files... that is:

If my source directory is:
C:\Source\MyApp
and my project is:
C:\Source\MyApp\MyApp.pjx
and this table is "included":
C:\Source\MyApp\MyTable.DBF

then I know I can do this anywhere in MyApp.EXE:
USE MyTable

BUT, if this table is "included":
C:\Source\MyApp\Data\MyTable.DBF
then I think I can do this anywhere in MyApp.EXE:
USE Data\MyTable

BUT, what if CURDIR()="D:\Data" and MyApp is at C:\Program Files\MyApp\MyApp.EXE? Would:
USE Data\MyTable
still work? or should it be:
USE D:\Data\Data\MyTable

or should it be:
USE C:\Program Files\MyApp\Data\MyTable

Or What?! it's just not documented. I would favor a pathing something like:
USE C:\Program Files\MyApp\MyApp.exe!!Data\MyTable

Particularly to distinguish it from:
USE C:\Program Files\MyApp\SubFeature.app!!Data\MyTable

Instead, VFP seems to use the current context (whether the USE command comes from MyApp.Exe or SubFeature.APP) to decide which table to use.

Oh, well.






- Bill

Get the best answers to your questions -- See FAQ481-4875.

 

[grahamrhind]

Related to my initial question, I received a comment from a (non VFP) programmer, who wrote:

1. Some of your tables are large and Shared Objects (SOs) are loaded into memory in their entirety. So this could eat huge amounts of resource on a user's machine. Also, each process that links to the SO will reload the data – each SO has its own data segment (it’s impossible to share SO data segments under Windows). This is quite a good way to crash machines!

2. Unless you have some clever way of compiling your data inside the SO the data will not be encrypted in any way. This means that anyone with a simple text editor could open the dll with it and be able to read (or copy) all your data.

Is he correct when applying this to VFP?

Thanks

 

[wgcs]

I'm not familiar enough with the particulars of the ActiveX/COM automation servers that VFP creates to give reliable answers.

VFP can create COM automation servers as Out-Of-Process .EXE files, too, which I believe can be instantiated once and shared by all the automation clients (using a "GetObject" function instead of "NewObject").

Regarding the security of the data, why not just create a DLL with your data in it and look-and-see if it is very visible? VFP has an option to "encrypt" the compiled file, but I'm not sure if that encodes "included" files too, and, as I mentioned, decryption/decompiler tools exist....


- Bill

Get the best answers to your questions -- See FAQ481-4875.