>>Do you not think that such a kind of obfuscation only need some code to resolve it? Looks like security by obscurity.

VFP needs its IL/p-code unpacked into memory to run it; once there, easy search patterns allow quick recreation of the source project with files and code. IME the full VFP source project can be extracted from a commercially protected/walled package in perhaps 5 minutes. I would call that failed security by obscurity; for VFP you need to mess with the IL somehow if you want to protect.

This was why Refox added a block on scripted strtofile(), so you can't easily inject a Trojan Horse .prg that finds and harvests the IL.

Defox altered internal structure of sensitive sections of IL and changed the unpack parameters so even if you harvest it, a hacker now needs to single step bespoke encryption to figure it out. Some years back there was a public challenge on Foxite confirming how much more difficult this makes it, with only one participant able to extract Leonid's simple example.

VFP C++ Compiler leaves very little behind in IL to be harvested, as well as obfuscating and decomposing heavily in the C++ so even a journeyman C++ hacker is going to get frustrated trying to perform math inside a dll to find key sequences as simple as ch(13). You'd be better off hooking the execution to try to build backwards, but that exposes you to absent code sections and randomized antihacks. Add variable obfuscation, loops and decomposed conditionals and it's nightmarish trying to recreate the source.