>>- it seems like Refox might protect from most hacks, correct? i.e. it hides at least my VFP source code?

Refox protects your exe from decompilation by Refox or similar.

But the way VFP works actually carries the main risk. When a VFP exe runs it unpacks itself into memory, ending up with what looks exactly like a compiled VFP .app in memory. So if a hacker can get their own code to run in your exe's process, it doesn't matter what you wrap around your exe if it eventually expresses itself as an unprotected .app that can be saved and decompiled. The size and complexity of your walls provides no protection from the attacker inside the walls. Refox does add some extra protections- e.g. it optionally prevents use of strtofile() unless compiled inside your exe, to thwart somebody getting their own code to shell memory to disk.

>> For the ultimate call to the external .dll, (wwDotNetBridge.dll) which is passed the key, maybe by that point since the key will be unique, it makes it hard for the hacker since they still have to figure out how the key is created ("munged" in your words)

If your key is unique, then intercepting one key is a very limited hack. It's much worse if you're encrypting a SQLStringConnect() or similar that gets intercepted by the hacker, and now they can query or interfere with the database.

>>- my key is only unique for the last 5 characters - and those come from the primary key of each record; given what has been said, I should probably change that because if they could see a series of keys, they would see that only the last few characters change; maybe I should hash the entire key after composing it or run CRC32 against the last chars

Assuming the hacker isn't able to grab your sourcecode: you need to decide on a "too hard" level at which point it's just not worth a hacker's effort to crack your system by brute force. Even to deduce the key algorithm from the last few characters, they have to figure out how/when you call wwDotNetBridge.dll and then make your exe run to their breakpoint, repeatedly, so they can see the pattern. Many so-called script bunnies will struggle even to reach this point, generally moving onto some easier target more vulnerable to their downloaded scripts. General advice would be to obfuscate a little harder so that the determined capable hacker who can reach this point, still faces an enormous cliff rather than a gap in the wall.

But of course this is all for nothing if they can grab your app and browse your code.

>>- Tamar suggested creating an expression out of the call and evaluating that - as I suppose that hides the code that creates the key and/or hides the code that calls the encryption routine

If the external function can read the key in memory, so can the hacker. FWIW, one of the ways around this is to alter the external AES or Blowfish or whatever algorithm, to munge the key further inside the call. This means the hacker can't just take the visible key and use it independently of your app.

Check out VFP C++ compiler that moves most of your VFP code into an obfuscated overloaded C++ companion dll. A journeyman hacker who can crack a VFP exe in minutes, ends up with a shell containing little of importance, with all your good stuff in the C++ dll. Picking apart the C++ dll is orders of magnitude more difficult, especially if you avoid external function call breakpoint opportunities.