Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Encrypting a few fields
Message
From
31/07/2018 14:57:57
 
 
To
12/02/2018 17:37:03
John Ryan
Captain-Cooker Appreciation Society
Taumata Whakatangi ..., New Zealand
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Environment versions
Visual FoxPro:
VFP 9 SP2
OS:
Windows Server 2012 R2
Network:
Windows Server 2012 R2
Database:
Visual FoxPro
Application:
Desktop
Virtual environment:
VMWare
Miscellaneous
Thread ID:
01658009
Message ID:
01661388
Views:
68
I realize this thread is old but cycling back to it after a few months. The client wanted to go after the "low hanging fruit" and assume that if there were a data breach, the bad-actors either would just be interested in data that was easy to get at or perhaps they were 3rd level hackers who would not know the steps to go through to get the keys out of memory.

Some follow up questions:
- how easy is it to set up Refox? Is it sort of just a black box where you point to the project and create a new .exe that has some protections built in?
- can someone relatively easily still get the keys out of memory for Refox? I use record specific keys (combined with a key in a config table and a key in a .vcx object) to create a unique key per record. Would this make it really hard or not worth it even if they could get the key for one record?
- currently using an external routine to encrypt - does this mean the key can be plucked out of memory each time that call is made?
- and if someone has to use a debugger, don't they need to sit and check each line of code to see when an decryption call is made?

Thanks,
Albert

>If a hacker can cause their own VFP code to run in your app- e.g. by adding a dbc Opendata event- then the entire VFP project with all its scx, prg, vcx, images etc etc can be "hooked" out of memory in seconds.

>Refox XII has additional protections that block this hooking/harvesting mechanism. Defox physically alters compiled code so hooking is no longer reliable and doesn't deliver VFP source at all for fully protected code. VFP Compiler moves most of the good parts out of the project into a C++ dll, so it's no use hooking the project: now you have to decompile a dll.

>The other "gotcha" is that if you use an external library for encryption, it doesn't matter which of these you use since a debugger or OLYDBG hook allows interception of the password when you make your call. This is not a VFP weakness, it's true across the board.

>Ironically, the same can be said for a SQL backend that includes security if the hacker can find an entrypoint and hook your connection string.

>The good news is that I've only seen two people, ever, publicly demonstrating peeling protected material out of a Refox XII. VFP Compiled or Defox-protected project. I'm one of them, and I can tell you that the knowledge required to pick out your connection strings or passwords, is well beyond most hackers.

>FWIW, VFP Compiler has its own AES encryption embedded in your app but also allows you to inline C++ or ASM code in your VFP prgs to eliminate any immediately identifiable entrypoint.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform