The latest development technologies rely on intermediate languages and can be decompiled. PowerBuilder is no exception. In this article, we will address the risks posed by decompilers. We will also discuss what can be done to protect against the possible negative results of decompilation - whether you create in-house applications, commercial applications, or are using these applications for your business.

A PowerBuilder Decompiler?
A decompiler is a program that reads executable code and decompiles it, providing access to source code. It has nothing to do with viruses or other forms of hacking, but - of course - it can be used illegally. Imagine that you've lost your source code (which is certainly possible if you don't use source code control systems); you have the right to use a decompiler on your code. You don't have the right to decompile someone else's code (unless not denied in the license agreement).

Other technologies also have their own decompilers. Microsoft provides, as part of the .NET SDK, a tool called ILDASM that reverse-engineers a (non-protected) .NET assembly. The popular "Reflector" tool (by Lutz Roeder, now acquired by Red Gate Software Ltd) shows your original source code in full detail. To take a look at the source code of Java classes, you can make use of several tools, including the DJ Java Decompiler.

Decompiled machine code is very hard to understand. However, this is not true for intermediate language, which leads to a key question: Do PowerBuilder decompilers exist? Unfortunately the answer is yes, as it is for any other successful development environment. PowerBuilder is widely used for creating mission-critical applications, something that clearly stimulates the creation of decompilers.

The next question is: Do decompilers work with PB? Yes, they do. They can retrieve your full source code as nicely formatted PowerScript with all variable, object, and function names, and ready to work on; all that's missing are the comments.

If you don't deploy source code along with your application, it's because you have good reason not to. Protecting your property, prohibiting unauthorized changes, or protecting your license-checking routines are all valid reasons to keep your code to yourself. But, be informed that upon deploying executables, you are basically exposing your full source code.

Now is the time to start protecting!

How Will This Affect Me?
PB decompilers exist, and one of them is frighteningly accurate. From some statistics found on the producer's web site, it was used about 300,000 times. What happens if your application gets decompiled? Your source code is fully exposed, which may bother you in and of itself. But there are more sensitive items that can affect your business:

• Security is at risk as it's easy to understand how the system works and to find alternate ways to use it or crack it.
• Any user with harmful intent can copy an application, decompile it, change it, compile it again and use the new version, breaking any security barrier. With a little development skill, access to executables in client/server architecture and a little a technical help are all that's needed.
• Competitors can understand your algorithms - they can study your protocols and provide an interface to your system, perhaps to offer a competitive upgrade.
• Competitors can decompile your applications, change the copyright notice, layout, and other minor settings, and produce a new application. If you have deposited your source code, it's possible (although not easy) to demonstrate that the application is your property. Conversely, your original source and the stolen one are equivalent to all points of view.
• Any user with harmful intent can decompile your application, include a back door or Trojan, compile it again, and distribute it.
• Changing license check routines and producing a cracked version of your software has never been easier.
• You have a responsibility to your users to provide the safest application possible. You never know what might happen...

Quality Assurance and IT Audits
If your software is a central asset for your company or customers, you need to protect it from the risk of unauthorized manipulation. This is not a theoretical need - doing this also protects you and your business. Your company most likely spends large amounts of time and money complying with both internal and external legal, security, and risk management audits (Data Protection Act, Sarbanes-Oxley Act, the 95/46/EC UE directive, ISO, etc.). To comply with these policies and keep these certifications, you must be able to prove that you have taken appropriate actions regarding the quality of your IT system. IT audits are there to do just that: find fault in the system and its assets. Applications that are left open to decompilation could be considered a weak link.

How Can I Fight Back?
There are various ways to protect your intellectual property, your code. However there is always a way to steal it; it's a just matter of time and money. The most effective way to protect your code is preventing access to it - for example, by using a terminal server or writing a web application. This is quite safe, but this code could still be stolen through errors in the software or servers, Trojans, or even employees or subcontractors. Many applications - including most of the applications written in PowerBuilder - are not well suited as web applications and only a few projects make use of terminal servers.

When deploying an application to customers, there is an option to encrypt the executable. This is done by adding a small loader to your application. When the application starts, it unpacks the file and executes it. This option cannot be used with a PowerBuilder application including PBDs. Using it for a single EXE works, but by using a debugger, this protection could be broken as well.

Another way to protect your code is to write "spaghetti code" (code that is very hard to read and understand). It's said that certain programmers do that on a daily basis, unintentionally. There's a contest for programs written in C called the "International Obfuscated C Code Contest." The major disadvantage of spaghetti code programs is that maintenance is almost impossible.

More sophisticated solutions use programs to generate something similar to spaghetti code from source code. The advantage with this is that the code can be easily maintained, but the distributed code is very hard to reverse-engineer. This process is called obfuscation. Besides making it very hard to read the code, it also protects the code from being reused. If someone were to steal your code and it went to trial, it would be hard for the person with obfuscated code to claim that he wrote it this way.

What Is Obfuscation?
Obfuscating code is the process of producing code that is difficult to understand, starting from a well-documented and maintained application source. You don't need to go to the effort of producing messy code, as this tool automates that process.

In order to make code difficult to understand, obfuscation techniques address:

1. Comments removal
2. Changing script formatting
3. Variable and class renaming
4. Addition of dead code
5. De-structuring (changing while/loop, if/then/else statements, choosing case structures by using "goto" statements)
6. Merging libraries

If you have never seen the effects of obfuscation, you'll be surprised at how difficult it is to understand obfuscated code.

Obfuscation is an alternate way to deploy source code for libraries or frameworks. For example, deploying a PowerBuilder application to Appeon, WinForms, and WebForms requires full source code; however, you probably don't want to publish the original source code. This means that users can take advantage of the generation to .NET by using an obfuscated version of the library source code.

As a word of warning, if you have your database password in the application or you have simple license check algorithms, rest assured that someone will use decompilers to take advantage of your good intentions.

How Does Obfuscation Work?
Removing comments is easy, even considering all the types of comments available in PowerBuilder (even though PowerBuilder grammar handles "///*" and "//*/" as special cases). Script format change also makes code difficult to follow. But the central goal in obfuscation is to destroy the symbol table in a non-reversible way.

Even without comments, variable and class names ("symbols") help programmers understand the meaning of your code. Thanks to PowerBuilder naming conventions, our source code is often very easy to read. But, imagine that your variable ls_license_code (computed by very complex algorithms) was named x4tg6_jh instead; it would not be easy to understand what the program does. Unfortunately renaming is not so easy, especially if you consider incremental compilation (that every script must be compiled before being saved) and all the possible references that you have in your programs. Finding elements to rename is not easy either, because if you obfuscate "Messagebox" or "Describe", your application will no longer work.

A symbol table is a technical term used by compilers to express the list of symbols used in the source code. Machine code compilers discard the symbol table, because it's not considered a central part of the source code. But intermediate language code compilers don't.

The technique for destroying a symbol table is to find variable, class, and method names defined by programmers and to replace them with alternate symbols. By systematically renaming them all (in every part of the program, including strings, DataWindows, etc.), you can build a new obfuscated program that's ready to be compiled. It will have the same functionalities as the original application, but will be much more difficult to understand (see Figure 1).

The obfuscation process starts from plain code and:

1. Parses it
2. Builds a symbol table and creates renamed items
3. Obfuscates scripts with extra elements and renames elements
4. Compiles the result in a single big (and messy) library

The result of this process is new obfuscated source code and a symbol table that shows the original symbols along with their new names. This new symbol table is like the Rosetta Stone; keep it in a safe place with the original source code.

A PowerBuilder Obfuscator?
I came across PBProtect back in February when I asked a question about Enable Rex to Gian Luca De Bonis, Enable Development CEO/CTO and the creator of PBProtect. He mentioned the existence of an effective PowerBuilder decompiler and the obfuscator he had created in response. He had been using it for a while to protect his own products, but was thinking that maybe other people would be interested in it. At first, I couldn't believe that a PowerBuilder decompiler existed. To find out more, I decided to download the trial version of this decompiler and check it out. It was unbelievable! The decompiler created nicely formatted source code, and even my variables' names were there. I have had experience with decompilers for other languages, as well as previous PB decompilers, but seeing the restored variable names was quite tough for me. This discovery made me very uncomfortable. Our company writes software for various customers who use it in-house or license it to their customers, as well as tools for PB developers.

I applied to be a beta tester for PBProtect 2.0. During the following weeks I tested various alpha and beta releases with different PowerBuilder projects and was more and more pleased with each new version. I passed my findings by email to Gian Luca and we often chatted on IM about details.

PBProtect was easy to use. To obfuscate a whole application you have to select a target, choose the right PowerBuilder version, name the output library for the obfuscated code, put your copyright text, and click obfuscate. The whole obfuscation process could be included into a batch build by passing a project file on the command line to PBProtect.

After clicking obfuscate, PBProtect parses the source of all the objects and presents you with a list of symbols (objects, functions, properties, etc.). There's a default setting of what gets obfuscated. All the PowerBuilder keywords are excluded. By default, all symbols that contain an underscore (_) are included. This can be changed by using filter expressions with syntax similar to the PB Match function or by including or excluding each symbol individually (see Figure 2). After hitting confirm, the sources will be obfuscated, imported, and rebuilt - ready to be deployed.

Listing 1 shows the obfuscated code whereas Listing 2 shows the same code before obfuscation. The listings are a few simple code lines used in a resize event; imagine how it looks when you obfuscate more complex code. (Download Listings 1 and 2 here.)

You might wonder what's happening behind the scenes. In the first step, all the source codes are exported into a temporary directory from where they are parsed. During parsing, all the symbols are collected, PowerBuilder keywords are removed from the symbols found, and the list of symbols is displayed in a window. There you can use various criteria to look at the symbols and create filters to include and exclude symbols (see Figure 3). For each symbol, you can define an exception to choose whether or not it gets obfuscated. In the next step, PBProtect obfuscates all the sources according to your settings. After this step, the PB sources are imported into the target library and migrated. In addition to the basic settings, there's also an advanced tab page that you will rarely use. After the obfuscation, you can deploy your project normally.

PBProtect is not limited to whole projects. It can be used to obfuscate single libraries as well. At the beginning of the year we decided to write a commercial PDF creation engine (CATsoftPDF) for creating PDFs without the need for a PDF printer driver. The availability of a PowerBuilder decompiler made us quite uneasy about deploying a PBL with all the information - also known as PBD. Anybody could get the trial version of the PB decompiler and get a look at our source code, maybe even steal the code and create his own commercial library.

With PBProtect, we can obfuscate the source and distribute the obfuscated PBL instead of the compiled PBD. The advantage of distributing a PBL including the obfuscated source code is that it can be used for .NET projects as well. In the obfuscation process we have to exclude the few functions and objects that need to be accessed from projects using our library.

Summary
It's a fact that software is stolen and used without a license. It's also a fact that efficient PB decompilers exist and can be used by anyone:

• If you develop mission-critical applications, anyone accessing an executable copy can rebuild the source code, alter the application, and perform illegal operations or access/disclose confidential information. What if the application manages financial transactions, health care data or air traffic?
• If you develop commercial applications, you can partially protect your business against illegal copies with software keys, but when someone decompiles your code, your intellectual property is at risk; they have access to key functions and features that you don't want to disclose.

In both cases, this has many more potential repercussions than simply using software without proper authorization. Fortunately, obfuscation makes it very difficult to reverse-engineer your code.

Using an obfuscator like PBProtect made me feel confident that I could deploy my application without worrying that somebody might disclose my work or reuse my code and create a competitive product.

Resource

• PBProtect: http://www.pb-protect.com/EN-source_pbp250art