>>>>>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.

I don't care about protect database. It's not my business. I just care about protect .EXE files and add .OCX, .DLL files into .EXE, not need setup.

>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?

I don't like an exe easly convert to source code with Refox. Our partners did this.


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

An average protect enough for me. I want to just silly Google hackers should not hack my application. You say your application sold 20.000, than sure someone opened it if it isn't protected... :)