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.