Under the age-old layers of computer knowledge accumulated by mankind, many fossil programming languages and forgotten technologies are buried. Some of them have sunk into oblivion forever, others are still used in narrow areas of human activity. One of these technologies is FoxPro, a popular database management system in the nineties, which was used at one time in almost half of Russian accounting departments. We will talk about the principles of hacking FoxPro in today’s article.
The FoxPro programming language was used to develop and manage file-server relational databases, although the capabilities of the language made it possible to find many more practical uses for it. The technology, which appeared in 1989, was based on the dBase language, which was used, in particular, in the database management systems of the same name, which even led to litigation between the copyright holder, Ashton-Tate, and Fox Software. FoxPro quickly gained popularity in the DBMS market and became a kind of standard for developing such applications. Versions of FoxPro have been released for UNIX, MS-DOS, and Macintosh.
In 1992, after long and painful negotiations that lasted three years, Fox Software was acquired by Microsoft, and then FoxPro technology was developed under the wing of Redmond merchants. Over time, the visual programming environment Visual FoxPro was released, but the technology gradually lost ground in favor of more modern software products. The latest version of FoxPro for Windows was released in 1994, even before the official release of Windows 95. However, with the widespread transition from 16- to 32-bit architecture, FoxPro-based DBMSs were completely outdated and gradually became history.
Microsoft itself ended support for this technology more than five years ago. Nevertheless, according to rumors, somewhere in the depths of the Siberian taiga there are still applications written in FoxPro that no one is going to rewrite from scratch. Moreover, the sources of such programs are usually lost, and the last programmer who remembered the FoxPro syntax died a long time ago of old age. Therefore, purely theoretically, it may be necessary to reverse such a program in order to understand how it works in general. And delving into such antiquity is an interesting task in itself.
It would seem that there is nothing complicated in this: the environment is a pseudocode interpreter, quite simple and primitive, a great many decompilers were written for it back in the nineties of the last century (the author of one of them is your humble servant;)). With the advent of VPF and ReFox, the question has completely lost its relevance – any compiled module can be reversed to the state of a compiled project literally with one click of a button. If not for one but.
The creators of ReFox are not selfless fans of free software: they have created a good commercial product, rightly believing that for any intellectual property there will certainly be those who want to steal it. And they released their own protection for compiled applications, where you can choose as many as five types of protection of varying degrees of complexity. Of course, a program protected in this way cannot be decompiled by ReFox in one click. But that’s why we are hackers, in order to overcome such restrictions.
We will not dwell on simple cases when an application is a classic set of APP, FXP, FRM, FRX and others (although there are also nuances, but we will talk about them later). Let’s go straight to the worst option.
So, we get a certain EXE file with good compression. By indirect indications, we assume that it is similar to a secure VFP application. The well-known protectors do not help us much, the only clue is the presence of an overlay with the FEF2 signature (
Overlay : ). Actually, this is the signature of any FoxPro file. Developing this idea, we cut off the overlay and try to feed it to specially trained utilities.
As a small lyrical digression, I’ll tell you a few words about what you can use for VFP vivisection. With all the variety of software written on this topic, only a few tools worthy of mention survived the competition. First of all, it is, of course, mentioned ReFox, which for the most part this article is devoted to. In spite of everything, the project is supported (at least so stated on the developers’ website). The current version at the moment is XII 12.99 / 16 from November 2019. There is also a French project DVFP, but it has not developed for a long time, and I did not manage to achieve any significant results using this tool.
The network praised the Chinese Unfoxall, but due to the specifics of the Chinese community, I personally could not find at least a working DeMouy for comparison. True, I didn’t really try. The Corso project deserves a separate mention: although it is not a decompiler in the full sense of the word (in fact, the very decompilation of pseudocode into program text is done by accessing an external server and in fact does not work), it contains many useful features for disassembling the project, which will be discussed stated below.
In general, we pulled out the overlay with the signature outside, fed it in turn to all possible utilities and … nothing! The tools say: yes, there is a signature, yes, an unknown encoder and compression are used, but nothing more. But we are persistent and we are not going to give up at the very beginning.
We load the application into the debugger. Well, let’s say we have OllyDbg at hand. To begin with, we simply launch the program and when the main window loads, we interrupt at an arbitrary moment, rejoicing in the lack of protection from the debugger and floating. Another pleasant moment is the successful search in memory of the process for text strings (which we previously tried in vain to find in the encoded EXE module). Moreover, around the found lines there is explicitly decoded FoxPro pseudocode (lines with a counter, procedure names, and so on).
However, it is impossible to dump it, as we would like, in one piece – the code fragments are literally cut into blocks “live”: the beginning of a text line is in one block, the end in another. In general, collecting all this is difficult and sad, especially since the volume is very large. Let’s try to go from the other side: since the code is clearly compressed, it was probably at some point unpacked and only then chopped into noodles. In the Memory Map window, we order the blocks by size – and indeed, at the very beginning of the list there is a huge block that was not there at the time the program was started. True, it contains, at first glance, a complete mess with huge entropy, but we are trying to get to its sources.
We restart the program and put a breakpoint on some Kernel32 function (say,
WriteFile). At each stop, we check the memory card – oops! – flight, once again the block is already present, and again filled with porridge. Without further ado, just put Hardware Breakpoint on the first byte of this block and restart the program. We were lucky again – this dishonest trick turned out to be effective: a hardware breakpoint is triggered exactly when writing to a fresh, zero-filled block of FoxPro signature
FEF2. Run execution until the end of the procedure (
Execute ) and get a block on a silver platter, completely filled with decrypted and unpacked code that can be dumped. Which is what we are doing.
It would seem that this is the end of the fairy tale, and who dumped – well done. Judging by the signature and content, we received a clean APP module with unprotected protection, which you can safely explore. But it was not there. ReFox already admits that this is a VFP application, it even sees the version, but refuses to decompile and show the structure. The APP itself, when launched, knocks down the interpreter with some mind-blowing error, other decompilers also swear at it, and only Corso sees the list of files from which this APP is built. We have little choice, so let’s try to fix the file using Corso.