>It's unmanaged C++ but it also uses the VFP runtime to execute heavily decomposed and obfuscated VFP commands. So theoretically you could splice something back together by hooking VFP _execute to track every possible outcome of every If, for, scan, while etc. IME it's simply too difficult.
>
>The remaining hole relates to encryption. I like Craig Boyd's vfpencryption.fll but it's trivially easy to eavesdrop passage of keys to a dll without even bothering to decompile the app. That's my next project: if encryption is put into private calls buried deep in the app dll with parameters munged using randomly altered C++ routines, eavesdropping isn't a threat because the parameters are always encrypted and you can't call the routine from outside the dll so you're forced to disassemble to figure out what's going on.
>
>Performance is equivalent AFAICS- inefficiency from the obfuscation and decomposition is balanced by better C++ variable and method handling.

Do you have any sense for the business, if any, behind this product:

- Licensing/price?
- Product reliability - how well has it been tested? Is it complete, or a version 0.9?
- Availability of support?
- Bug fixes? (upgrading/enhancements may not be an issue if VFP itself is not progressing)

It strikes me that in a perfect world, this would be a fantastic open-source project for the community as a whole. Being open-source would help assuage any fears that (for one thing) there could be a backdoor in the product. Or, that security is being achieved through obscurity rather than good design and strong crypto.

Convincing the developer to go open-source could be challenging. OTOH, maybe s/he is a student and this project is a thesis...