>>>>Tried as admin with no success, but actually it was working without admin rights before 8.1.
>>
>>OK, it could be a Molebox versioning issue but as per previous, Molebox is ineffectual protection for a VFP app anyway. Have you considered Defox or VFP Compiler? The protected product can be installed by xcopying a handful of files to a folder on the destination machine and they're both far too difficult to hack even for the sorts of C++/VFP guru who can disassemble the ASM or C++ to figure out what is happening.
>
>We have hundreds of customers, so I can't trust VFP C++ compiler at this time.I just wait for others to test... :)
>Maybe Defox + another .EXE, DLL wrapper would be a better solution. What about Refox on Defox protected files?
>
>>No matter what protection you use, watch out for use of external encryption dlls. If you rely on one of those, your encryption keys can be hooked from a VFP app the moment you access the dll, without bothering to decompile the rest of the app.
>
>I add dll files too into Molebox wrapper. Isn't that a good protection?


Metin, I know John is a big promoter of this VFP C compiler thing but I think for the vast majority of cases it is probably overkill. All security is a trade-off between cost and benefit. That is guiding principle in security #1. You really need to think about this in a different way. Start with this: "hackers won't pay and clients don't hack". That is a really basic premise which is true for the vast majority of cases.

Furthermore, any program you put in the hands of a competent hacker is going to be cracked. It might not be a case of getting the original source code back out but maybe a copyable program or access to the data. I would start thinking about your problem like this:

1) What do you want to protect? Is it the source code contained in the exe? Or do you want to stop the copying of the program on unlicensed machines and users? Or do you want to protect the data within the database? What is really being threatened here? These are all different issues and require different solutions.

2) Who are you trying to protect the above from? Is it from your clients? Are they the danger? If your clients, do they even have the motivation and skills to hack anything? How many of them are really the danger? What percentage of your clients are going to hack anything and what would the cost of that realistically be to you? Or are you concerned about random hackers getting your stuff? If hackers, how would they get your stuff, is it available for download anonymously from a website? If not, how would they get a copy? Would they have access to your clients installations? How, why?

3) For how long do you require this protection to be secure? For example, if protecting data then that data might expire in usefulness over time in which case protection only has to last as long as the data is relevant. If source code, ask yourself how much it is really worth. And if you are still developing the application then new code would need to be continuously hacked in order to keep up with your new developments. How likely is that? And is your application really so opaque that the observation of it would not reveal most of what is going on within it anyway? In other words, how valuable is your source code really? How truly unique and secretive is the code that someone could not replicate it anyway without hacking the exe? And if the source code could be extracted, can someone really just take that code and make a new application and then market it effectively against your own sales efforts and your existing clients? Is that a realistic scenario?

In sum; What needs to be protected? From who? For how long?

Give you an example; we have sold probably 20,000+ copies of a certain application, maybe more. Maybe someone hacked the code, I don't know, and don't even care. No new competitors have emerged in over 15+ years, no new competitive products to speak of, and in the meantime we re-wrote everything in a new language for which there are no known/disclosed cracks and, on top of everything else, moved to a terminal services type environment as well. The moral being, things change, times change, security changes. Apply the level of security which is threat-realistic and at a sensible cost-benefit trade-off.