Albert, sorry for slow reply- have been a bit busy!

>> 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?

That's exacrly what it does- compresses it, too. To set up, purchase a license, download and install, submit a key file to the author. IME Jan the author responds very quickly- within hours.

>>- 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?

Refox protection prevents a hacker simply decompiling your VFP app back to a complete pjx a hacker can browse and step through. Refox also blocks the strtofile technique that made it possible to peel a VFP project out of memory whether protected or not. If they can;t just reverse engineer a project, now you're down to probably a handful of people capable of hooking or breakpointing to scoop your key.

>> currently using an external routine to encrypt - does this mean the key can be plucked out of memory each time that call is made?

Using OLYDBG or similar you can set a breakpoint and grab the key when the call is used. This requires fairly detailed knowledge of VFP's inner workings- so down to a few people again- especially if the keys aren't readable text.

>> 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?

No, they can set a breakpoint at the start of your encryption/decryption routine. Not wanting to reveal too much- but it's not so difficult to detect if somebody is using a debugger, so again the required expertise goes up another step. Unless your keys are obvious/human readable, your hacker also still needs inner knowledge of VFP memory use.

Truth is that any app is hackable written in whatever language, if the hacker has physical access. The goal is to make it so difficult that it's not worth it- that the benefit of hacking is outweighed by the cost. Your only risk is of trophy hunting where the hacker determines to succeed for reasons of prestige, regardless of cost. All of the VFP protection options push well into the "too difficult" territory, but not the generic commercial systems that encase apps and runtines written in any language, since that leaves VFP exposed to hook and filetostr.

I am very impressed by Refox and use it for some distributed apps,. but also I use Chen's VFP Compiler that fixes most of the known bugs in VFP and converts most of the VFP stuff into horribly obfuscated C++ calls that use program control that cannot be mapped back to VFP. VFP Compiler also allows embedding of assembly or C++ right in your prg, making it possible to(for example) embed AES encryption at the point it is needed so a hacker now does need to step through and disassemble C++. Another option is Leonid's Defox that alters VFP code using variable keys that make it a lot harder- but Leonid has basically gifted his work to VFP users meaning there's no guaranteed vendor support if you strike trouble.

I've only ever seen 2 people able to peel source out of current versions of any of these, though it's a lot easier to lift a key than to reverse engineer the thousands of lines of code in a typical VFP app.