Obfuscate your VBA code
October 22, 2009 • JP • No Comments • Rate This Article
• Links to this article
On OzGrid they have a VBA obfuscator for sale. It looks like they're a reseller, but the graphic is interesting:
Supposedly, this makes your code harder to copy. However, it looks like a simple find/replace could un-obfuscate this code. Some of the claims for this product are:
VBASafe converts your VBA code in a matter of seconds, no matter how complicated this is. This makes it extremely hard for someone to understand and follow its logic.
Obviously, you're using this product because you don't want someone to steal your code.
VBASafe cleans your VBA project from the "junk code" that accumulates during the development phase which could lead to unspecified problems.
I wonder how it does this. Sounds like it just removes commented code? Otherwise, I can't tell how it can figure out that some piece of code is "junk."
VBASafe allows you to remove all blank lines and comments from your VBA code, thus making it even harder to interpret for a malicious user.
And making it harder for you to read your own code.
The lesson to be taken from this, I think, is that if code security is a dealbreaker, you shouldn't be developing in the VBA environment. Or else you might have to resort to using Dim nkdldjlkjdlkjdkjd As Excel.Workbook as your code. 
Obligatory disclaimer: I didn't test this software, I don't make money from sales of this product or any competing product.
VBA ·
Rate This Article:
(No Ratings Yet)
Loading ...What now?
Subscribe To The Blog
Email This Article
Follow Me On Twitter
My Facebook Page
Or just keep reading:
I'm just an average guy who writes VBA code for a living. This is my personal blog. Excel and Outlook are my thing, with a sprinkle of Access and Word here and there. Follow this space if you want to learn more about VBA. Keep Reading »
Previous Post: Shorten your tweets with a bit of VBA
Next Post: Do you sign your VBA projects?
Obfuscation is part of a hierarchy of steps you can take to keep your code secure. Each step keeps out a few more hackers than the previous step. In order of increasing security, with arbitrary percentages tacked on, these are:
1. Obfuscate (90% safe)
2. Protect the VB Project (99% safe)
3. Convert to DLL (99.99% safe)
4. Don't deploy (100% safe)
"VBASafe cleans accumulated junk code"
Export and remove all modules and forms, compile and save, and reimport the modules and forms. This is what Code Cleaner does.
"And making it harder for you to read your own code."
Nah, you keep your master code in a safe place. You obfuscate your code as the last step in the pre-deployment process.
1. Open in an early version of Excel, like 2000.
2. Use Code Cleaner (http://appspro.com).
3. Compile and save.
4. Obfuscate.
I use Code Cleaner as well to shrink the overall workbook size, but seeing that bizarre looking code just made me laugh. Maybe I'll try reselling it myself!
What makes obfuscation weak in the case of VBA, though, is that you are operating mostly with existing objects from the Excel object model, which you can't rename. The line "Dim dfhlijebhdskpsdrhd as Workbook" is always going to remain fairly transparent, no matter how weird the renaming name for the variable is, and replacing it would take mostly patience. In other languages, where it is standard to roll out your own classes, you can obfuscate both the variable and the class, which makes the technique much more effective. "Dim sdfghebgb as hennasvfkrnf" is unwelcoming…
On the security steps, one step up the dll, you could access the dll as a web service, so that the user never has physical access to the code itself.
Mathias
"if code security is a dealbreaker, you shouldn't be developing in the VBA environment"
True upto Excel 2003.
From 2007 AFAIK the Backdoor hack or the hex editor hack wont work. Only thing that will i guess is a "Brute" force…
You can unlock the VB Project of a 2007 workbook by unpacking it and doing the hex editor thing with the appropriate unzipped part of the file. Or so I've been told.
Jon…You are right..just tested ..its the same old Hex Hack once you unpack and apply it on the vbaproject.bin
Really sad to see no improvements… in the security level
Matthias -
If you're worried about revealing object types, then you could declare everything as either object or variant, or remove Option Explicit and don't declare anything.
looks like the obfuscator is just renaming the variables defined thru dim. it should be fairly straight forward to develop a small program that would take VBA script as input and change the variable names to arbitrary length random strings (hey, we can even use JP's random data generator
)
But again, I dont need obfuscator for my code, it is unreadable anyways
That's not even obfuscated code, they have just done a find and replace, unbelievable, I'm sure they must have sold 0 copies, because anyone who wanted to obfuscate there code must know better than that right!