Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Table Structure Encryption 1

Status
Not open for further replies.

Ris1

Programmer
Dec 8, 2017
26
IN
I want to encrypt tables on the hard disk so that my clients are unable to open table through browse window. On googling, I found third party tool "Cryptor" best to suite my need, but now I it not available to download/buy , nor any reply to the emails.
Can anyone suggest any other alternative to decrypt tables only through my application or how get copy of cryptor.
 
Xitech, the firm that made Cryptor, went out of business some years ago.

I am not familiar with any similar products, but VFP comes with a sample encryption library called _crypt.vcx which might be worth investigating. Look for it in the FFC directory.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
_crypt.vcx is for encrypting data as I have read. I want to prevent clients from viewing table schema. Uptill now I was giving my software on the cloud, so client could only access data through my app. Now , I want to give desktop edition, so I want to restrict client from viewing structure of tables, so that they may not reverse engineer the product.

Secondly, is there any tool to encrypt my exe. I had licence of molebox but now misplaced and MoleBox also went out of business, so is there any other tool. Also I want to restrict my exe to run on the computer in which it was installed, so that if client copies to another computer it could not run. Is there any API. and on which parameter of system my app should rely.
 
You didn't say anything in your original message about encrypting your table schemas or your EXEs. I don't want to discourage a newcomer to the forum from asking questions, but you will do us all a favour if you state your question clearly and accurately.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Sorry Mike,
Will take care of that.
 
I only have one thought about this. If you're really interested in security you should go for other programming languages and databases.

Bye, Olaf
 
To follow up on Olaf's suggestion above...

You can leave your application in VFP, but changing the 'backend' data source from VFP Data Tables to another, more secure Database (such as M$ SQL Server) would enable you to meet your goals.

Yes that means that how your application would go about acquiring records, inserting/changing them, etc. will need to be done in a different manner, but it is a very do-able approach.

Good Luck,
JRB-Bldr

 
I agree with all that.

Keep in mind too that encrypting the schema is no different from encrypting the actual data. If by schema you mean the names of the fields, their data types and their sizes, that information is clearly visible in the header of the DBF. A knowledgeable user would only have to open the DBF in a text editor in order to read that information.

And, by the way, the fact that you were previously storing your data "in the cloud" (whatever that means) doesn't make any difference. The point is that, at some point, your application had to download the data to the local machine, at which point it would have become visible a (knowledgeable) local user.

I suggest you've got three options:

1. Encrypt the entire DBFs. That would include the schemas and the actual data. You can do that with a commercial encryption utility, or you can write your own encryption program (perhaps using _crypt.vcx). But sooner or later the files have to be decrypted, at which point they become vulnerable (not to mention adding quite a lot of overhead to your running times).

2. As the others have suggested, move to a secure SQL back-end. If you are really worried about users looking at your schema and/or data outside your app, that is definitely the best option. But be aware that migrating to a different back-end will take a great deal of work and might mean you having to make some fundamental changes in the design of your app.

3. Do nothing. Ask yourself what the cost is of someone knowing the structure of your tables? Does it really matter if they discover your field names and data types? Is there some specific threat that you feel you are exposed to?

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Hi Ris1,

I would also like to address the value of any single part of the puzzle. Regarding database and table structures: How valuable is a database design? The two companies I worked had no other hourly rater for database design work than for programming and other tasks, so it is worth the time you put in. I also don't want to argue you can find sample databases and ERMs and database designs for free on many sites, but in itself, I consider it a lower value than queries or other code involved. The most valuable thing in a database, especially to your customers, is the data itself. I worked for a life science/chemical industry, and their most valuable asset was formulas of products and the data about them. You can reverse engineer a product, but that won't give you essential hints on the processing and what ingredients to use from which suppliers.

Conclusion about that: The database schema may be your a valuable protectable knowledge to you, but customers using a software which protects their data sounds very fine, but not if that data is even protected from them trying to get at it aside of using it with your application. A significant success factor of the Sage ERP system has been an open backend you could also extend with third-party extensions for own development. Even the perhaps most expensive enterprise SAP is not protecting their database structure. And even if a customer doesn't need the ability to extend the software and are happy with it as given, he'll be interested to see whether he can get at his most valuable possession at times you quit supporting your software, or you die or develop your software in directions they don't like.

So you're digging your own grave if you're so after your right to protect your intellectual product and prioritize that protection over the concerns of your customers about their business data.

Next big topic is the protection of your source code. You will have to use obfuscators and encryption tools, but no matter what you do, also in a Konxise (from the same vendor XiTech) or Refox protected EXE, at runtime the code in memory is decrypted. Better protected programming languages are those not creating opcode like VFP or Java, nor building IL (intermediate language) like .NET does, but compile into assembler. Those languages are a dying species, and besides that lousy perspective, there are decompilers to refit the assembler they generate into C/C++ code.

Besides that, there has to be tremendous innovation and that magic "unique selling proposition," so a software becomes the goal of decryption/decompilation/cracking. Most hackers will just concentrate on cracking the copy protection and not the source code. If someone is criminal, why should he care about source code, if he can sell illegal licenses to customers not caring why they get some software for half the price or less.

If you target a particular group of customers, it might make sense to put in some effort of copy protection. Online registration and online license checks. The best protections use hardware dongles and even on that topic you have to stay on top of emulated dongles or even simpler patched software with removed or rerouted calls into the dongle authentication/verification process.

Your best bet to succeed in the business is to bundle your software with your personal service.

Bye, Olaf.




 
Hi Ris1,

I wonder whether you thinking about something else, by encrypting your data and structure it would much harder to migrate away from your product.

Customers would need to rely on whatever reports you provide to extract information to populate a new system?

Is this where you are going with this?

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top