What obfuscat.org is?
It is a program that makes the VBA source code continue to work exactly the same in clear than obfuscated. But read obfuscated code is very difficult: nobody can’t understand now how the code runs. This makes reverse re-engineering very difficult.
The source code statements are kept on exactly the same lines and in exactly the same order after obfuscation. In case of debugging or errors, you can go to the source code in clear and see in which statement the problem has been raised. obfucat.org needs some empty lines at the beginning of the source code to create its own VBA Const definitions. If there are no enough empty lines, the source codes lines will be simply displaced to make rom. Some lines will be added after the source code for the VBA Function required on obfuscation. Constants are stored in a set of encrypted strings here.
There is no need for external files or to hide the source code somewhere in exotic places. The obfuscated code is a perfectly normal VBA module, but it is difficult to realise how it works. You can also mix obfuscated and clear modules in the same program. They interoperate perfectly.
Performance in clear vs. obfuscated
Performance is affected when replacing each constant for an obfuscation Call that returns its value at runtime. Obfuscation Call is therefore optimised for minimising performance impact
Run obfuscate.org.xlsb generating obfuscated code
obfuscat.org.xlsb is an Excel program type .xlsb running in a Windows PC, with one single click. The source code never goes out your PC. Absolutely confidential and safe. No cloud computing risks.
The input is the VBA file in clear with the source code program (file type .vb to obfuscate) and the obfuscation password. If no VBA file path is provided, obfuscat.org will prompt for selecting one.
The output are two files, in the same folder and with the same name than the VBA file in clear (xxxxxxxx.vb), but ending as:
- xxxxxxxx.obfuscated.vb with the obfuscated code. Substitute the source code by the obfuscated code and run again. That´s all.
- xxxxxxxx.obfuscated.txt with the translation table from clear names to obfuscated names. All obfuscated variables and constants are detailed with number of obfuscated occurrences, number of times declared, line of declaration, original name. obfuscated mask.
All the messages that have been produced in the obfuscation process are shown in the sheet Obfuscate.
Keywords arising exceptions to obfuscation
Keywords that must be left in clear. Name of the source code Subroutine that is going to be called from an Excel button. i.e. Sub EntryPoint()
Or String with legal advises as Copyright or Disclaimer.
Anticipated end of source code. Keyword that, when appears, forces ignore from that line and all subsequent lines. It is equivalent to a source code End Of File. Useful to remove debug code or source code at then end of the fille that you do not want to move to production.
Lines to be ignored. Keyword that, when appears, forces ignore the line. Used to remove specific line/s of debug or source code that you do not want to move to production.
Use of obfuscation password
When generating the obfuscated code, you have to set a password that encrypts the text constants. The password is stored hidded among the obfuscated code by default.
Optionally you can select a String variable of the VBA source code where the password is going to be.
If a String variable is selected, but not prompt text is provided, simply the source code will receive the password at runtime as a value in the selected String variable . The obfuscator Function will recover the hide password and return it in the String variable. This can be useful as the source code program doesn’t have to take care about where to hide the password: obfuscat.org will hide the password and will return it at runtime.
If both a String variable is selected and also prompt text is provided, the password will not be stored at all. The prompt text is a last resource to ask for the password directly to the user at runtime. If the password is not provided, the text constants of type String cannot be decrypted, and the source code program cannot run. The password shall be requested the first time the VBA source code requires a String constant. The source code can operate normally in the meantime, but only while using numeric constants. Either the VBA source code program recover the password in the meantime, or the obfuscator will ask the user for the password as last resource. In that case, the user will be prompted with the prompt text asking for the password in a pop-up window, over and over again, until the user provides the password or cancels.
This is a proprietary algorithm. The encryption takes into account the constants that have already been encrypted. All the constants are encrypted together as a single block when creating the obfuscated code. This arrangement prevents attacks analysing constant-to-constant. If the password is lost, there is no way to recover it. The advantage of this algorithm is its limited impact on performance. A certified cryptographic algorithm as AES could have been used, but it would have serious impact on performance.
Sheet Constants for substitution of VBA reserved constants.
Reserved names used as VBA constants are obfuscated. e.g. True, vcCrLf or xlCenter. The sheet Constants has rows, with the VBA constant name (Column 1) and the respective value (Column 2). Additional rows can be added for particular cases. More than 2000 rows with constants have been copied and documented in the sheet “Constants” from the Microsoft VBA website.
Prefix for variables used by the obfuscat.org
Infrequent use. It is required only to avoid name collisions. Let the default Z_Z_ prefix if no special requirements arise.