Hide/Lock tables

[jhed]

hello.....

i have already done making my system but i want to hide or lock the tables in installation directory. Is this possible? I've already not included my forms but of course not including my tables when i build my program is not good.. i worried when i install my system on other computer and other user might change the value on my systems table. please i want your advice...

thanks in advance

 

[Olaf Doschke]

You can embed data in your exe, but then you won't be able to change data. If that's no problem, you can do that. If you need to store user specific data, eg licensed users, then sign that data, which enables you to check modifications and in case refuse to work with the manipulated data.

Bye, Olaf.

 

[Mike Lewis]

Another possibility would be to place the data in a hidden folder, that is, one that is hidden at the operating system level (to hide a folder or file, right-click on it in Windows Explorer, choose Properties, and tick the Hidden box).

A knowledgeable user would be able to un-hide it, but it might still discourage cusual tampering.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

That is indeed a very weak option to hide data.

If the data should only be readable by your application, the best thing you can do for DBF protection is encrypt DBFs with a third party product like Cryptor and also Konxise or Refox to protect your EXE.

Bye, Olaf.

 

[JRB-Bldr]

other user might change the value on my systems table.

Olaf's 'system table' data encryption approach is a good one, but encrypted or not, another user could possibly corrupt the data (although not likely knowingly change it)

However another very different approach might be useable depending on how much data was stored in your 'systems table'.

If is was not too much data and if it was not to change very often, you might consider eliminating the 'systems table' all together and writing your systems information to the Windows Registry.

Then, instead of reading information from a 'systems table', your application would read that same information from out of the Windows Registry - where it is significantly more challenging to change.

Good Luck,
JRB-Bldr

 

[JRB-Bldr]

Other alternatives....

1. Add a new field to your 'systems table' with some 'generic' field name

* Algorithmically calculate a Check Sum from the 'standard' data entries and put the value into this new field.
* Then when values are retrieved from the 'systems table' run the Check Sum algorithmic check to validate that the values have not been changed.
* It is unlikely that a user would be able to change any values such that the Check Sum calculates correctly and/or that they could 'crack' your own 'home-grown' Check Sum algorithm to create a new one.​

2. Instead of using a 'systems table', use a MEMVAR file.

* Put your system parameter values into memory variables and then write them to a MEMVAR file (SAVE TO SysMems.MEMVAR)
* Then retrieve your system parameters with a RESTORE FROM SysMems.Memvar
* MEMVAR files are harder to recognize as 'important' and their contents are more difficult to understand​

3. To any of these alternate approaches (including using the Windows Registry) you could encrypt the individual system parameter values.

Good Luck,
JRB-Bldr

 

[Mike Lewis]

Add a new field to your 'systems table' with some 'generic' field name
* Algorithmically calculate a Check Sum from the 'standard' data entries and put the value into this new field.

Good plan. But if it was done at the record level (that is, if each record has its own checksum), it would not defend against malicious users deleting entire records. To deal with that, you would have to store a checksum for the entire table, which would be easy enough, but would possibly be much slower.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Good thoughts,

it all depends on the amount of system data and it's nature, eg for licensing or if it's really application data like a dictionary is for a spell checker and if it's static or you want to allow changes. In that case you may also make the system data static and add a user data table for changes or additional entries, which would add the need to alter all your code to join or union system data with user data, but that's not uncommon, eg even the windows system registry is cut into several files.

So let's hear, what you system data is about and what best practices exist for your scenario.

Bye, Olaf.

 

[JRB-Bldr]

Mike - But if it was done at the record level it would not defend against malicious users deleting entire records

You are correct, but if the record was Deleted, then the application would 'see' its absence and declare the installation INVALID.

And/or if a new record were inserted to replace the deleted one, it too would need to have a Valid Check Sum value. If not then the application would again declare the installation INVALID.

Olaf is correct. We need to better understand what the values this 'system table' is holding before we can give better suggestions.

jhed - Good Luck
JRB-Bldr