Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Update of WWF-VFP, a tool to protect from decompilations
Message
From
16/11/2001 14:10:06
Jorge Grundman
E.U.I.T. Telecom.
Madrid, Spain
 
 
To
15/11/2001 15:29:58
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00574338
Message ID:
00582880
Views:
149
>You'd have to lock the user into the app so that they cannot switch to the start menu, the command prompt, or some running file manager (or any other app, for that matter); the app must not have Explorer-style file dialogs (since you can use those to copy files around), and all outgoing networks shares on the machine must be disabled so that people cannot do their copying over the network (good luck trying to keep users with admin privs away from the shares). And the Vulcan nerve pinch (CTRL-ALT-DEL) must be disabled as well (or hooked), naturally.

The idea is left the work environment as is. So the VFP EXE can run without any modifications. There is no need to disable CTRL+ALT+DEL. The idea is a VFP EXE loader which runs without the original code. Once this VFP EXE is loaded in memory the WWF-VFP protected service patch the process in memory decompiling the original code. So if an user access to the file stored in disk will find a loader but without original code. Even "refoxing" this loader the only code to find is a loader with a lot of heap space. Once the original code is patched in memory the WWF-VFP service is idle until the the EXE file ends, moment in which it will erase the VFP EXE loader.

>Another vulnerability is the compression/decompression code unless you have written it yourself and keep the source code locked up ... If you are using a publicly available algorithm or library then others can decompress the protected app directly.

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. The password mechanism is the file to be protected so, any future release of the file to be protected will use a differente password as the file is different.

Well, more than this: the password (let me no explain here how I use the original file to get the password) is encrypted also, so if anyone spend 25 years in decrypting the original password use to encrypt the protected application, will need to spend another 25 years more to discover the password to decrypt on memory.

I hope this clarify the public protection engine. What I try to do is complicate the work as much as possible for the refox user.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform