> Once this VFP EXE is loaded in memory [...]

Jorge, sorry for my misunderstanding. Judging by the publicly available information on WWF-VFP - i.e. UT messages and the downloadable demo - I was under the impression that the app is decompressed to disk prior to being run and that the protected form of the app is a standard password-protected zip appended to the loader stub.

If the app is decoded to memory then this is as secure as you can get without patching the VFP runtime dlls in some manner (provided that the method has no weaknesses in other areas, of course).

> >Another vulnerability is the compression/decompression [...]
> Well that's true and not true. If I encrypt a file with the complete ASCII
> and 200 bytes, a brute force attack for the file on a Pentium 1 GHz will
> match the password in a 25 years or more.

That might be relevant if a would-be-cracker had to brute-force the password ... Even so, the zip encryption algorithm is vulnerable to known-plaintext attacks and cracking a password-protected zip takes only minutes - regardless of the length of the password. IIRC there must be a program called ZipCrack32 somewhere on the net that is distributed with a text file that gives the theoretical background and an in-depth analysis of the problem.

However, I do not think that a cracker would try to brute-force the password since all they have to do is intercept the function call to AUNZIP32.DLL and pick the password out of the parameter list (or save the uncompressed app to disk when the function returns). Doing this takes less than a minute and requires nothing more exotic than Windows' Quickview, a hex editor for placing an INT 3 opcode into AUNZIP32.DLL and a JIT debugger (like the MS VC++ IDE).

If the decryption/decompression code were contained in the stub itself - there is lots of C/C++ source code for both in the public domain, like Blowfish for encryption and zlib for compression - then a cracker would have to spend a lot of time wading through to machine code of the loader with a debugger, and you could add a little spice with the usual debugger traps (i.e. INT 3 instructions sprinkled throughout the code, stuff like that).