Data Protection in the tables

[ameedoo3000]

Hello
I have a question regarding the protection of streams of penetration or conquest, especially after converting the project to an executable file ... how is that

 

[JRB-Bldr]

Network 'penetration' security from the 'outside' needs to be primarily addressed at the Network level, not the file level.

Having said that VFP Data tables have no security.
And since most VFP Data Tables are external to a compiled VFP Application (the Executable) so that they can be Read & Write tables, that has nothing to do with it.

VFP Data tables can be encrypted using code, although that slows down access to Decrypt for use and Encrypt for saving.
And the Data table filenames and extensions can be 'masked' so as to not appear to the casual observer to be data tables.
Example:

* -- Instead of naming a Customer Data Table: Customer.DBF  name it something like:    ABC.XYZ --
* -- Then in the VFP Application: --
USE ABC.XYZ IN 0 ALIAS Customer
SELECT Customer
<do whatever>

However, if you want data table level security for a VFP application, then you might want to consider using something like MS SQL Server as the data 'backend'.
VFP applications can use SQL Server tables as long as the code is written to do so.
And SQL Server has its own security.

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

Streams of penetration and conquest sounds like you did a word by word google translation.
Are you, as JRB-Bldr assuems concerned about data security or copy protection or source code protection?
The thread title is pointing to data protection only, but let me address the others, too, as you mention creating the executable.

Dataa is not part of the executable, as JRB-Bldr already stated, you can embed DBFs into the executable, but that is then readonly data. If that's sufficient, the encryption option does encrypt the whole executable, but things are decrypted at runtime in memory, both object code and embedded DBFs. So you do a memory dump with task manager and have the decrypted data.

In regard to source code: Almost any of todays compiled programming language uses some type of byte code, Java always did so, .NET languages all compile to MSIL. Because of that you may decompile C#.NET into VB.NET, for example, though you don't need to, as you can use the Assemblies and DLLs anyway, and C/C++ though not compiled to byte code, create so typical assembly code, that there are C/C++ decompilers anyway. Then there are non compiled scripting languages, like PHP, Python, Ruby, etc., which only don't show to end users, as they run on servers. Hacking FTP servers or being employee at hosters you get at such source code anyway. Then very obviously there is open source code software.

Overall you shouldn't be concerned about your source code as intellectual property, like a cook shouldn't be much concerned about his recipes. Even if a recipe or source code is not available, you see the main components of a dish or what a software does. Still people are often enough willing to pay for a dish, though they also could cook it themselves or a software, even if there is a free alternative. You should rather be concerend about copy protection, and that's best left to experts of this and usage of a third party software protection suite. Nothing is 100% secure, but need of certificates to check license keys/files and letting software only run registered is quite a standard in regard to that topic. I don't have to say very much though, as said that's a topic best done by experts on it.

Data protection has cryptor as component for encrypting files "transparently". Which means your code can be unaltered and will get data decrypted automatically while all you write is encrypted. The en/decryption is done on the level of a cryptor componenent hooking into the file system. The readability of a file is then done through a kind of "login" process to a file, which you do at application start. Besides that, you could use Veracrypt file containers only your application has a key to. Veracrypt acts in about the same way, just not on the level of each single file but a container of multiple files, eg your whole database, quite like a virtual hard drive.

I agree with JRB-Bldr, though, MSSQL is the best option for a backend, not only about security of your data, also in concern about stability of it, and accessibility through further software, eg apps you might offer, not written in VFP.

Bye, Olaf.

 

[Olaf Doschke]

Just to demonstrate the ineffectiveness of the EXE encryption VFP offers.

Here's a project with a DBF I include in the EXE:

Notice the project info has checked "Encrypted", no debug info (sources) are included, the includeddata.dbf is included in the built EXE, the excludeddata.dbf has a small icon crossed circle, which is default excluded status for any DBFs you put into PJXes, so includeddata is explicitly included. The data inside the includeddata.dbf is shown on the right.

Here I now inspect the built EXE about it's encryption. I make a simple test, whether the words of the DBF cannot be found and notepad++ here states it cannot find the word "inside", which is one of the words in the data. This is proof the embedded data is not in clear text.

Now I started the EXE and used task manager to make a dump file of memory contents related to this EXE and loaded DLLs.

This shows up as this DMP file and notepad++ can find the word "inside" inside it and the whole data is decrypted in memory and thus in the memory dump file. I even didn't download any hacker tool, making dump files of running processes is part of Windows and the Task Manager, it's simply an option of the context menu of a process.

So while the whole data really is in its encrypted state on HDD in the EXE file itself, VFPs runtime does decrypt the EXE while running and thus embedded data also isn't safe from prying eyes, even not with VFPs internal encryption option used.

The code running was simply this:

On Shutdown Quit
Select * From includeddata INTO CURSOR crsLoadedData
Read Events

Is the query the vulnerability loading the data? Well, no, even if the data only is in the dump file because this cursor is the query result, how else would you make use of embebded data when not querying or using it in any way?

So finally: Embedding data inside an EXEcutable makes it harder to get at it, but it's not safe there. If you ever thought about that for safety of internal knowledge/meta data/license codes/passwords or anything else your code only needs to read: No, it's not safer than data put in source code or unencrypted extra DBF files.

Bye, Olaf.

PS: Just to make sure I also compiled an exe without the SELECT * FROM includeddata and the data still shows up in the dump file, so the main vulnerability is simply the decrypted state of everything in memory.

 

[Dan Freeman]

Streams of penetration and conquest sounds like you did a word by word google translation.

That's a better interpretation than mine. I thought we were talking to a porn bot.

The other thing that crossed my mind was SQL injection, but then it was dinner time so my willingness to climb aboard waned.

 

[ameedoo3000]

Thank you to all, Dear Friends,
Angd that there is another way that can be effective in protecting data after the establishment of the executable file, namely, change the location of tables, and of course that in the absence of a network. Is this possible?

 

[Mike Lewis]

Are we talking about protecting data? Or about protecting program code? Both "tables" and "executable files" have been mentioned.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

What kind of protection are you aiming for? Protection against corruption, against copying (stealing), against modifications. There are many aspects.
The experiment about memory dump should have already shown you there is no protection against reading/copying data.

If you need data protection use SQL Server and only load as much data as necessary to process something into a VFP process/memory.

Bye, Olaf.

 

[ameedoo3000]

Already the best solution is to use " SQL Server SQL Server and only load as much data as necessary to process something into a VFP process/memory."
Thank you so much

 

[JRB-Bldr]

If you are not already familiar with how to get VFP to work with MS SQL Server, you might want to look over:

Client-Server Applications with Visual FoxPro and SQL Server 7.0​

http://www.hentzenwerke.com/catalog/csvfp.htm

And/or do a Google Search for: vfp "sql server"

Good Luck,
JRB-Bldr

 

[ameedoo3000]

I will do
Many thanks to all Dear Members