Refox is helpful but not perfect. It's possible to bypass the need for password by hacking the refox.exe itself with a hex-editor and making a few quick changes to it. The VFP 64 bit with the C++ compiler seems like a better option.
http://www.baiyujia.com/vfpcompiler/en/default.asp


>Hi John,
>
>Lots to digest. I need to understand this in fairly short order to take to the client if I am suggesting action steps so if you can indulge me, I will ask a few more questions for confirmation:
>
>- it seems like Refox might protect from most hacks, correct? i.e. it hides at least my VFP source code? 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)
>
>- 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
>
>- 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
>
>Feedback anyhone?
>Thanks,
>Albert
>
>
>>Hi Albert,
>>
>>>>My question is: what would a person need for tools to be able to get the key for the encryption? My key is made up of a long "base" and then for each record in a table, it is unique. Of course, this key gets assembled right before each call into one string.
>>
>>>>Is there a way to capture this key even if it is in memory as a var just long enough to call the encryption/decryption routine?
>>
>>Windows debuggers can set breakpoints, at which point the app's variables or other memory use can be read directly.
>>
>>While choosing a breakpoint in the middle of C++ or ASM can be tricky, external function calls are obvious and easy targets for a breakpoint. Check out apps like olydbg or x32dbg that most likely will allow you to set your own breakpoint on the external encrypt/decrypt function in fairly short order, at which point you can see your key in memory.
>>
>>This is not a VFP weakness, it's true of any Windows call to a dll, to the point where popular debugger apps began automatically tricking Windows IsDebuggerPresent API and similar mechanisms used by developers to detect these hacks. Microsoft increases security with each new OS but if a hacker has physical access to your app, even if MS eliminated debugger use completely in Windows 11- which they won't- the hacker could just use an earlier OS VM or legacy OS PC.
>>
>>In your case with a varying unique key, pulling one instance from memory isn't a complete hack; they'd still need to figure out the munging to create the unique key.
>>
>>If yours is a plain VFP exe, Refox can restore your whole project in seconds with all scx, vcx, prg etc, even if so-called encryption was used. So the hacker wouldn't even need olydbg to figure out how your encryption works.
>>
>>Even if the app has some more advanced encryption or commercial protection scheme: if a hacker can get a piece of their own VFP code to run in your app's thread, it's very likely that they can restore your entire project. Common ways to achieve this include hijacking of standalone config.fpw, frx, app, prg or fxp, free dbf added to a hacker dbc with a DBC_OpenData() event... any way you can use to get external code to run in your app becomes a hack point. It's worth noting that Refox, Defox and VFP Compiler all have defenses against this sort of hack, with varying degrees of success.
>>
>>If they'll have me, at the upcoming FoxFest I'll give an advanced talk on use of VFP C++ Compiler to move most of this stuff into the "too hard" basket.