De Feater

Visual Basic Discompiler (Decompiler) Defeater

This page only exists in archive.org for December 1996, which may be the boundary of the archive. In case it disappears, therefore, I'm reproducing it here as a Wiki page; Visual Basic decompilers do seem to be popular. I have no idea how current this is.

---

The discompiler (from DoDi in Germany) and allied tools really work. You may think that the information is worthless because the names are not too meaningful to you. However, get some experience reading someone else's code and tracing how it works. The compiler creates good code, at least typically good enough to make anybody nervous and interested in defeating the decompilation process (you may want to review some of the current and possible new legal issues on trade secrets, decompilation, and methods to defeat encryption). The object names generated by the discompiler actually make a lot of sense. When objects can be extracted from the forms, the decompiler will show the original name. When objects have been tokenized so that the name is not recoverable, the decompiler will assign initials for objects and for uniqueness assign the memory offset in the program. Realize that you can load the sources into the VB development environment and globally change these variable names. For example, a variable name called "I0028" is long integer that should contain system information and the variable "I002A" is a message string generated by the values from that information which you can rename to "mLoopCounter" and "sStatusString."

Furthermore, those demos and shareware sitting on BBS around the world with their high bits slowly decaying to "0" are prime dumpsters for source code. It is like picking through the printouts in the trash for trade secrets. A couple bits here or there, a command triggered by a .INI or the Windows registration file, and the demo is a real application. That executable can be decompiled, studied for about an hour or two, tweaked here and there, and then recompiled into a new fully-functional application. What is copyright protection and trade secret enforcement when the key to VB source is broken?

There are proactive solutions available. First, you can alter the source code so that it is not so easily understood. That is a stupid approach at face value because you cannot read it either and make much sense of the code. This defeats the purpose of reusable code, code libraries, team development, and Attila. However, this does not mean you can't precompile your code and convert it into nonsense before the VB compilation. This works, but you still get serialized variable names out of the discompiler.

Second, you can alter the exectuable so that it is not as easily decompiled. This means overwriting some of the names, addresses, and objects so that the P-code will still run while the compiler will choke. Obviously every change made forces the designers of decompilers to build newer and better tools to retrieve the source code in spite of these modications. It is a never-ending game. There have been decompilers and disassemblers on PCs since CP/M. However, VB's P-code rather than true compilation means that it is easier to get source that is in a higher level form. My solution is the Decompiler Defeater, OVERRIDE.ZIP. I read a few VB applications in hex code and deciphered where the objects and text-based references were stored and overwrote them. That stopped the decompiler (discompiler) for now. You can register the tool through CompuServe SWREG 8135. The demo runs against all VB executable programs (compiled runtime files). Some quirks do show up depending upon the resources referenced in the VB runtime, but generally the full version is innocuous and effective with current decompilers.

Another technique is to upgrade to VB 4.0. This does not defeat the discompiler, but VB 4.0 provides conditional compilation so that demos, shareware, and full versions are actually different executable files. This minimizes your source code exposure... somewhat. However, if you combine all these techniques, you probably can make the application so hard to crack that competitors will not try and you will keep out unmotivated prying eyes. Hardware locks, specialized output devices, and dongles can add to the decompiler's difficulty. However, you may also create a puzzle, which by its very difficulty may attract hackers who merely want to break it. Since hackers can disassemble Windows itself (and there are workalike Win API toolkits and Windows emulations for other platforms), you might just think about updating your applications often enough and with enough new enhancements each time to stay ahead of the power curve.

Download Decompiler Defeater(override.zip 74 kb) now!