>>what do you mean by "hook your program" - just so I understand.

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.