Comments on: Obfuscate your VBA code

By: Ross

Ross — Wed, 28 Oct 2009 15:22:24 +0000

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!

By: Chandoo

Chandoo — Wed, 28 Oct 2009 12:58:41 +0000

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

By: sam

sam — Fri, 23 Oct 2009 07:44:52 +0000

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

By: JP

JP — Fri, 23 Oct 2009 00:29:26 +0000

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!

By: Jon Peltier

Jon Peltier — Thu, 22 Oct 2009 19:17:19 +0000

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.

By: Jon Peltier

Jon Peltier — Thu, 22 Oct 2009 18:00:02 +0000

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.

By: sam

sam — Thu, 22 Oct 2009 17:56:19 +0000

"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…

By: Mathias

Mathias — Thu, 22 Oct 2009 17:48:42 +0000

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

By: Jon Peltier

Jon Peltier — Thu, 22 Oct 2009 16:16:37 +0000

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.