How to modify applications without the code

What do you do when you need to modify your application but cannot find the code?

Peter Altman contacted me about a Visual Basic 3.0 puzzle which he wanted to run on his Windows Mobile PDA. All he had was the compiled code, written for him by a friend who had died. VB 3.0 is 16-bit software that is fifteen years old.

The best chance, short of a full rewrite, was to port the application to Visual Basic .Net, which runs on Windows Mobile under the Compact Framework runtime, but for that the source was required. This kind of scenario can be a critical problem when it happens with a business application. It should never happen, but small businesses can be disorganised, and developers can be protective of their code.

16-bit code is an interesting case. The move to 64-bit Windows is in its early stages, but will gather pace over the next few years, and 16-bit applications do not run on 64-bit Windows. Virtual PC or the like is one answer, since it lets you run a different operating system within Windows, but even that does not help you if you need to modify the code or port it to another platform.

Decompilation
If you have an executable for which the source is not available, then you can resort to a technique called decompilation. The aim is to start with the binary file and work backwards to the original code. Decompilation has many challenges. It may be illegal; many licence agreements forbid it. Some code is deliberately obfuscated to make decompilation more difficult.

Another factor is what type of compiled executable you are dealing with. Native code binaries such as those produced by C, C++ or Delphi are more difficult to decompile than the intermediate code in Java, .Net or early versions of Visual Basic. A lot of Java and .Net code is trivial to decompile with a suitable utility, unless the programmers have taken deliberate steps or used a tool to obscure it.

Here’s how we decompiled Peter Altman’s code.Visual Basic 3.0 uses an intermediate language. Many years ago a programmer c alled Hans-Peter Diettrich, also known as ‘Dodi’, created a decompiler, which is still probably the best tool for this. You need to have VB 3.0 installed. Microsoft can no longer supply it, but fortunately I still have a copy.

Windows XP or earlier is recommended, as Vista’s User Account Control introduces complications. Diettrich told me that he uses Windows 98 in a Virtual PC. I found it necessary to check the vb.ini file in the Windows directory, which should have a vbpath entry, in the Visual Basic section, pointing to where VB 3.0 is installed. Once everything is set up, run vbdis3.exe, which is the decompiler.

Choose File ­ Open and select the compiled VB 3.0 executable, which in this case is called counter.exe. Next, you are prompted for a location for the decompiled project. Click OK, and all being well the decompiler invokes VB 3.0 to complete the process. It’s not perfect and may trip up over some VBX controls. You will also find that variables and function names have auto-generated values.

It is a good idea to try renaming these to something meaningful, if you can figure it out. Nevertheless, it is a huge head start (see attached picture). Diettrich kindly provided a working demo version of his decompiler for PCW readers. A professional version is also available, with extra features for handling tricky problems like third-party VBX controls.

Porting to .Net
This is only the beginning of the porting process. How do you port a VB 3.0 application to VB .Net? One idea is to try Microsoft’s automatic project conversion. The first snag is that VB is fussy about what it will import. Visual Basic .Net will not look at a VB 3.0 project, but fortunately VB 6.0 is more tolerant.

Peter Altman’s simple application imported smoothly into VB 6.0, needing only the adjustment of a couple of API calls to 32-bit. It even ran correctly. The next step was to go from VB 6.0 to VB .Net. This is inherently difficult, because it is really a different platform, but Microsoft has put huge effort into it because it is a common scenario. I used Visual Studio 2008, and chose Convert from the Open menu.