Source code security and decompilers

Decompilers have been around as long as compilers. This is the case with FoxPro and Visual FoxPro. Decompilers literally take apart a compiled executable file (APP, EXE, or DLL) and reproduce the source code of the application. Is this a problem? Not if you develop custom applications for clients who buy the source code or have the rights to the source code to make derivative works (see Chapter 12, ‚“Legalese ‚½ for more details on the derivative work topic). If you are deploying a vertical or horizontal market application and another developer decompiles your application, they could steal your intellectual property. On the up side, if you have a catastrophic hardware failure or the developer ‚ s computer is stolen and all the backups of the source code are bad (or not current), but you have a recent copy of the executable, you can use one of these products to partially restore the source code.

Developers have long considered this a problem. Microsoft has provided the ability to encrypt the application when the executables are built. Decompiler vendors have broken this encryption so it is a useless setting in our opinion. It would be nice if the Fox Team would add a key to this algorithm so we as developers can determine how the encryption is set, but this feature is not a priority and could be difficult to implement.

This problem is not unique to Visual FoxPro developers. The problem exists in developer tools and languages more recently created like Java and .NET Assemblies. Microsoft Visual Studio .NET comes with a decompiler called the Microsoft Intermediate Language Disassembler (ILDASM) for just this purpose. There are ways to frustrate decompilers such as an obfuscator. Microsoft ships the lite version of PreEmptive Solution ‚ s ( http://www.preemptive.com ) Dotfuscator in every copy of Microsoft ‚ s Visual Studio .NET. Some decompilers allow developers to protect their source code from being decompiled by the same decompiler by protecting the executable with a key it respects if another developer tries to decompile the executable with the same product. However, it may or may not be able to protect decompilation by other products.

As mentioned earlier, the decompilers can save your source code in the case when a catastrophic failure of the hard drive blows away source code and there is no good backup. In this case you can use the last executable deployed at a customer site to re-establish much of the source code (although there are cases where you can never get back 100% of what you compiled, like #INCLUDE files, constant definitions, and compiler directives). This is the reason these programs exist. Developers have leveraged this technology for both ethical and unethical reasons.

Visual FoxPro ‚ s only attempt at protection is encrypting the executable, but you will see in the following sections as we investigate the capabilities of the decompilers available to you exactly how it does not fully protect your code from prying eyes. The author of this chapter does not endorse the use of any of these products and is only providing information to the readers so they know the risks involved with their source code and how it can be exposed to developers who might not have the same level of ethics you adhere to each day.

One additional concept with respect to protecting your source code we have heard other developers implement is the removal of source code from forms and visual class libraries. We want to be very clear that this is not something we have used because of the danger involved in accidentally erasing the source code in these files, but it is an option to those braver than us. First, the reason for this is the SCX and VCX files are directly copied into the executable. These files have identical formats. One of the columns has the source code ( Methods ) and another has the compile FXP code (ObjCode). Because the source code is stored in these metadata files and are consequently built into the executable, it is simpler for the decompilers to reveal the source code in these files. Some developers take an extra measure of copying entire project and related source code to a separate directory and remove the code in the Methods column of all forms and visual class libraries, and then building the executable in this second folder. The danger of course is forgetting to copy the files and accidentally removing the source code. As noted earlier, this makes us a little uncomfortable so we have not used the technique. We also hope you understand the potential problem before attempting this, if you think it is a good idea.

How we tested the decompilers

We used the sample application used throughout this book with some minor enhancements to ensure we included all the different types of Visual FoxPro source code files (see Figure 1 ). This application was compiled in four different configurations: Debug Info only, Encrypted only, both Debug Info and Encrypted, and neither setting. Each executable was decompiled with the tools and the results are discussed in each decompiler section that follows .

Figure 1. The project file used to test decompilation has at least one file of each type of source code file used by Visual FoxPro.

We are not doing a full review of the different products, as this is not the purpose of this chapter. Rather we are going to demonstrate some of the functionality and discuss the results of our experiences decompiling the sample application.

The source code we added to the sample application is used to exploit a potential problem decompilers encounter when they are run. For example, we added some #DEFINE s and #INCLUDE files to the build. A decompiler has trouble decompiling #DEFINE constants because the compiler substitutes the constant in the source code as it is compiled.

We used Visual FoxPro 8 Service Pack 1 for all the tests. We recompiled all the source code each time the build was done to make sure code was compiled with the proper settings (see Table 2 ). We made sure no errors were compiled into the executable and all files were available to the project and the build. We did not test APPs or DLLs for the comparison.

Table 2. The base details about the build and executable sizes used for decompilation.
EXE name	Debug Info	Encrypyted	Size (bytes)	Reference
DEPLOYFOXSAMPLEPLAIN.EXE	‚	‚	322,778	Plain
DEPLOYFOXSAMPLEENCRYPTED.EXE	‚	X	323,290	Encrypted
yLPLOYFOXSAMPLEDEBUGINFO.EXE	X	‚	471,590	Debug Info
DEPLOYFOXSAMPLEBOTH.EXE	X	X	471,078	Both

There are source code items that no decompiler can reproduce:

Comments are not stored in compiled code and are not restored.
#INCLUDE statements are not restored because the Visual FoxPro compiler substitutes the constants at compile time. These files are not necessary because the constants are substituted directly in the code. The disadvantage is you lose the ability to make global settings to your code using the restored source. This may be very important.
A decompiler cannot restore #DEFINE statements for the same reason as #INCLUDE .
DECLARE DLL commands have unrecoverable parameter information.
White space in the code is removed. Therefore, all empty lines you might have in your original code for readability will be gone.
Code with numeric literals that looks something like lnSum = 123.12 + 4323.788 will decompile to lnSum = 4446.908 . It does not affect the program functionality.

ReFox MMII

http://www.xitech-europe.co.uk ‚ Xitech (Europe)

ReFox MMII (see Figure 2 ) has long been considered the solution to decompile a FoxPro and Visual FoxPro application. It is the best-known decompiler in the Fox Community and is the most recommended solution when someone needs to recover their source code. It splits the executable into the original source components and decompiles the executable modules into the source. While this sounds great for those that have lost the source code or are helping a new customer recover source code the original developer lost years ago, it is definitely not perfect.

Figure 2. The ReFox user interface immediately exposes the main program, even with an encrypted executable.

The ReFox documentation steps you through the process. It is very simple. Navigate to the folder with the executable; select the file and right-click to expose the menu. Select the Split option to create a new project (also available on the main toolbar), and split out the source code to each of the original source code files. The process takes a very short time.

Issues found in the sample application decompile in addition to the known issues stated with all decompilers:

One folder name was not retained (Prgs decompiled as Progs).
Code lines were split into multiple lines based on function parameters (each on its own line ‚ see Figure 3 ).

Figure 3. The differences in a simple program when compared side-by-side are obvious. The original program is on the left side, the decompiled version on the right.
Files from the Fox Foundation Classes (FFC) that resided on a different drive than the project were thrown in the ‚“other ‚½ folder. The forms that used a class in these libraries still found them (even with SET PATH set to nothing).
Loss of camel case or Hungarian notation for all memory variables , properties, and method calls. You can set this to all lowercase, all uppercase, or Hungarian the second or third character, but it does not recover as it would look if you write code using this standard.
In our experience, you must follow the process to recompile forms and visual class libraries or you could lock up Visual FoxPro the first time you edit a method.

The bottom line, despite the minor problems, the project compiled and the new executable ran no matter what type of settings were made on the build. Also, your executables do not protect your source code from you or other developers. We compared the four different folders (Plain, Debug Info, Encrypted, and Both) and all the files compared except for the creation date and time. In our small unscientific sample, it did not matter how we built the executable, the decompile worked identically.

ReFox does have a ‚“branding ‚½ feature that stops it from decompiling branded executables unless you supply the exact key provided during the original branding. Basically, it allows you to stop other developers from decompiling your executables. You still can decompile your own executable because you have the key. It only stops ReFox from decompiling its own branded executables; other decompilers can still decompile a ReFox branded app.

yRecover

http://www. foxite .com ‚ Yuri Rubinov yRecover is a free developer tool (see Figure 4 ) that does a specific job of extracting forms, visual class libraries, and reports from EXEs. yRecover cannot decompile an application with the encrypted option set when the build is done or an executable branded with ReFox (see Figure 5 ). Yuri originally wrote the utility to recover forms from an executable when the ‚“ILOVEYOU ‚½ virus started destroying SCT files and Windows 2000 occasionally corrupted form files.

Figure 4. yRecover is a free developer tool that extracts the forms, classes, and reports from a Visual FoxPro executable.

Figure 5. yRecover does not extract files from encrypted executables.

You need to select the files you want extracted. You can do this two ways. The first way is to select the files in the three list boxes. These are multi-select list boxes so you can pick individual files or all the files. You can also select all the files in each list box by selecting the label above each list box. A report is available if you want to print out the file names you selected for extraction.

We had some interesting results on the extracted files (See Table 3 ). In all fairness, we compiled the sample application in Visual FoxPro 8.0 and the version of yRecover floating around on the Internet was written when VFP 6.0 was the current version.

Table 3. Comparison between the original source and decompiled files using WinDiff from Visual Studio 6.0.
Build	Results
Plain	TESTFORM.SCX/SCT ‚ identical CUSTOMERLISTING.FRX/FRT ‚ not identical FORMS.VCX/VCT ‚ not identical _BASE.VCX/VCT ‚ not identical _HYPERLINK.VCX/VCT ‚ not identical
Debug Info	TESTFORM.SCX/SCT ‚ identical CUSTOMERLISTING.FRX/FRT ‚ not identical FORMS.VCX/VCT ‚ not identical _BASE.VCX/VCT ‚ difference in blanks only _HYPERLINK.VCX/VCT ‚ not identical (close, extra text at end)
Encrypted	No files extracted because yRecover does not work with encrypted files.
Both	No files extracted because yRecover does not work with encrypted files.

Just like ReFox, you need to be sure the forms and visual class libraries are recompiled with the COMPILE command or the source code will not be included in the methods. All of the extracted files opened in the designers. We did notice the files from the EXE without the Debug Info did not compare nor was the code available in the designers. The TESTFORM.SCX

did compare identical in both extracted files, but there was no method code in the file. The rest of the files had various differences. It is difficult to compare binary files. Visually comparing the differences with WinDiff, the files with Debug Info were much closer to being equal than the code compiled without the Debug Info.

Others

Other tools on the market decompile FoxPro and Visual FoxPro code or protect the source code by compressing the executable with a proprietary scheme. These are tools we have not used, but are frequently recommended to developers on the various online support forums with respect to recovering or protecting the source code in the executables.

AntiPro is a FoxPro 1.x/2.x decompiler created by Pavel Celba of FROG Systems ( http://www.frog.cz/prod02.htm ‚ site is non-English). UnFoxAll is available on the Web at a Chinese Web site that we cannot read. This tool is big in the Chinese market from the reading we did on the various forums and searching on Google.com produced a number of Web sites where you can download the product.

KONxiSE is another tool from the creators of ReFox, Xitech (Europe). KONxiSE is a compression utility for Visual FoxPro applications. It is available at http://www.xitecheurope.co.uk . The marketing material from Xitech notes you might see compression as high as 70%. Because there is no decompression routine, it secures your source code inside the executable. The runtime decompression is direct to memory so the application does not have a disk presence in decompressed mode. You do need to be aware of drawbacks developers have noted with this tool. You cannot call a KONxiSEed application from another Visual FoxPro EXE because it is no longer a Visual FoxPro executable. You would need to RUN the other executable. We have read developers ‚ postings noting that you cannot call regular FXP programs or APPs. This prevents modular apps and leads to monolithic, single file application deployments. Visual FoxPro COM servers cannot be KONxiSEized. The good news is that the source code in the application is far more secure. If you do not have any of the drawbacks and need the added protection, this might be the solution for you.

HTML Help files

HTML Help files can be decompiled just like Visual FoxPro applications. The base compiler to generate HTML Help files is Microsoft ‚ s HTML Help Workshop. It ships with Visual FoxPro, is available on the Microsoft Web site, and provides the decompile capability two ways. The first is from the HTML Workshop menu (File Decompile ‚ see Figure 6 ); the other is a parameter passed to the HTML Help executable (hh.exe -decompile <destination folder> <compiled chm>).

Figure 6. The decompiler parses apart any CHM file into the original files and stores them in a specified folder.

We created an HTML Help file and decompiled it in a separate directory. We then used a tool called WinDiff from Visual Studio v6.0 to compare the original and decompiled directory. The comparison report showed that all decompiled files were identical. It also reported two files in the original folder not in the decompiled folder. The two files are the mapping file (H extension) and the project file (HHP extension). This is good news in some ways because it means the person ‚“hacking ‚½ your Help file does not get the all-important mapping file to determine the Context IDs. Without this, the Help file cannot be altered and reconstructed.

What if you want to enable the complete recreation of the source code including the mapping and project files? Can this be done? Not with HTML Help Workshop. There is a free tool available on the Internet called KeyTools ( http://www.keyworks.net/ ). This product ( Figure 7 ) has one feature that decompiles the CHM into the original source and attempt to recreate the project file as close to the original as possible. It also reassembles the Alias section, which provides the constants for the Context IDs. The other feature we like is you can look inside the CHM file and inspect the contents without needing to decompile them. It provides you a perspective of how the CHM file is assembled from your source code.

Figure 7. KeyTools does a better job at decompiling a HTML Help file than HTML Help Workshop, plus it has a number of other features that assist HTML Help authors.