Nikki,

There are a number of products you can use to protect and/or obfuscate VFP code.

The most reliable way is to host your work elsewhere so the user doesn't get physical access to the app. If that's not possible, the next best effort is to alter the sourcecode away from VFP standard so it cannot be "hooked" out of memory and recovered.

Don't waste your time with walling systems like Armadillo or Molebox. The way VFP apps are constructed makes it easy once you get inside the wall- I'd expect to have your complete project within minutes despite all the impressive protection labels.

The latest Refox slightly alters your sourcecode. I would not call it obfuscation, but it will deter most casual hackers.

The free Defox product adds encryption to each line of your code so it no longer can be hooked and reassembled. Leonid mounted a number of challenges in VFP forums and hacker forums in China leading to the latest version with deep encryption and generally requiring brute force cracking of every individual line. Possible to break, but requiring advanced understanding and generally not an attractive proposition for the sorts of people who would be capable. Leonid also has/had an optional obfuscation product you can use before Defoxing. Defox also has a demonstration/trial mode with timeout that can be added to your apps so you can offer trial versions and manage licenses.

The one I use is VFP compiler plus Defox if there's a licensing/trial version issue. VFP Compiler does a very nasty obfuscation, then it rips the project apart into a C++ dll and VFP application shell with very little useful content left in VFP. You can still hook the VFP project, but usually there's little of value left there. Since it's going to C++, you can inline assembly or C++ routines inside your VFP procs. Good examples of this include encryption, since it is extremely easy to lift passwords out of calls to external dlls- generally takes a few minutes to set up and then scoop the password when the dll/fll is called. In VFP Compiler you can inline the C++ there in your procedure so somebody needs to pick through obfuscated C++ to figure out what you're doing. Chen (author) has versions that no longer require the VFP runtime, and he has a beta 64-bit version as well. It's cheap and well worth the $ IMHO.

Here's a fairly simple example of VFP Compiler Obfuscation showing "decomposition" that complicates simple tests to create a decompilation nightmare.

IF ((x1 OR x2) and x3) or (x4 and x5)
   ?"A"
 ELSE
   ?"B"
 ENDIF

Obfuscated version:

 IF IIF(.F.,29378,IIF(.F.,30126,IIF(.T.,x1,117915874)))
 IF IIF(.F.,25808,IIF(.F.,26864,IIF(.F.,18384,IIF(.T.,x3,117919216))))
 ?"A"
 ELSE
 IF IIF(.F.,21087,IIF(.F.,19145,IIF(.T.,IIF(.F.,25753,IIF(.T.,x4,117926399)),117930063)))
 IF IIF(.F.,21194,IIF(.F.,18022,IIF(.F.,20842,IIF(.T.,x5,117925574))))
 ?"A"
 ELSE
 ?"B"
 ENDIF
 ELSE
 ?"B"
 ENDIF
 ENDIF
 ELSE
 IF IIF(.F.,26185,IIF(.F.,28879,IIF(.T.,IIF(.F.,23999,IIF(.T.,x2,117919849)),117925593)))
 IF IIF(.F.,25808,IIF(.F.,26864,IIF(.F.,18384,IIF(.T.,x3,117919216))))
 ?"A"
 ELSE
 IF IIF(.F.,21087,IIF(.F.,19145,IIF(.T.,IIF(.F.,25753,IIF(.T.,x4,117926399)),117930063)))
 IF IIF(.F.,21194,IIF(.F.,18022,IIF(.F.,20842,IIF(.T.,x5,117925574))))
 ?"A"
 ELSE
 ?"B"
 ENDIF
 ELSE
 ?"B"
 ENDIF
 ENDIF
 ELSE
 IF IIF(.F.,21087,IIF(.F.,19145,IIF(.T.,IIF(.F.,25753,IIF(.T.,x4,117926399)),117930063)))
 IF IIF(.F.,21194,IIF(.F.,18022,IIF(.F.,20842,IIF(.T.,x5,117925574))))
 ?"A"
 ELSE
 ?"B"
 ENDIF
 ELSE
 ?"B"
 ENDIF
 ENDIF
 ENDIF