23 thoughts on “Invisible Basic”

1. 95% of my projects rely just as heavily on the worksheet structure as on the VBA, with the VBA serving mostly to facilitate the worksheet’s tasks. Most of my code in fact has been cobbled together from examples taken from the bottomless well of the internet. I tell people that my two favorite programming tools are the macro recorder and Google.

   I use Excel’s pseudo security to protect projects until a new client has paid. I don’t bother after the first project for a client, because it’s as big a pain for me as for the client. I don’t distribute projects such as PUP over the internet, but if I did, I’d probably mimic John’s model.

2. I agree with Peltier. There is so much information on the web, programming has become a largely cut and paste affair. Other than going through a painful learning process, why would you not use code that has proven to be effective. I would even go so far as to say that with the support of google, anyone can be a “programmer”. I believe “Programming” as shifted paradigms. It no longer constists of creating code to accomplish a task. Those who can take existing code and creatively apply it to various situations are (in my mind) considered good programmers. In fact, code itself seems to matter less than the a programmer who can think outside the box and use code in imaginative ways. Thus we come to protecting code. Seems silly to protect code in Excel. If it’s so important, write you application in VSTO or some other platform. Excel security is better suited for protecting the clients from themselves.

3. Sorry for all the typos. It’s a little early for a Sunday morning.

4. Hi Mike –

   “Those who can take existing code and creatively apply it to various situations are (in my mind) considered good programmers.”

   I’d like to think that this description applies to me. I’ve had no formal programming training (well, except for an introductory class in high school in the mid-70s), but I’ve done a lot of hacking, to get the machine to do what I was too lazy to want to do myself.

5. I usually say to my customers that it exist a lot of good and skilled Excel-developers but not so many who understand and can apply solutions to their business processes. In this context the intellectual property (IP) exclude the code that solutions are based on.

   When it comes to commercial add-ins the IP is the add-in itself and therefore should be proctected to some extend. In general customers who have paid for something are not interested to distribute it for free and therefore standard XLAs with the available level of protection can be applied. The use of COM add-ins (developed with classic VB or VB.NET) is one way to go if we need a stronger security. However, it’s also possible to decompile DLLs.

   As we all (should) know, if we want to keep things secret a good start is to avoid the use of computers ;)

   Kind regards,
   Dennis

6. Great link!

   Intresting to look at the source code.

   I understand the easy of getting code, but still think there might be situations where code protection would be adventagous – Algorithms for example can be very refined for one solution, and you might want to keep then for your eyes only. Thats one of the nice things about .xll’s and .dll in vb6. In VSTO you have to use obfuscation beacuse exe and .dlls are compiled to MSCL right?.

   I wonder what the run time are like (I’ll test it when i get a second!!!)

   cheers

7. The addin removes comments, blank lines and indents. It then renames modules and declared variables to simple names (a,b,c,d…) with no obvious meanings. It doesn’t really “obfuscate” the code or make it unreadable.

   I always give clients sheet & code passwords. The main reason to protect code is to maintain model integrity from accidental or deliberate corruption. I have had users try to game in-house company budget allocation templates by modifying code but such behaviour is covered by company employment policies.

   I can see a desire to protect code & prevent piracy in commercial for-sale xl programs but Excel cannot block determined hackers. Will Excel 12 have better code protection?

8. “I can see a desire to protect code & prevent piracy in commercial for-sale xl programs but Excel cannot block determined hackers. Will Excel 12 have better code protection?”

   Unlikely!

9. I have written a similar tool to “scramble” my own excel VBA projects. I haven’t released it yet because I still consider it to be in experimental stadium and I haven’t got time left to finish and test it thoroughly. My own version includes “heavy” scrambling. By that I mean that the variables are not replaced by simple characters, but by unique long strings (uuuuiuiuivviiiiuiuiuvi), composed of user selected characters (eg: uiv) upto a certain length.

   In one of my last projects, I mistakenly scrambled the code in a workbook without saving the workbook first in an unscrambled version. One thing I can say for sure: heavy duty scrambling makes the code very, very hard to read. I couldn’t even read my own code, although I had written it myself earlier. And oh yes: after that episode, I included an option to make a backup before scrambling. The scramber also generates a report, with a list of the original variable names and the scrambled ones…

   Yes, I truly think scrambling or making your file “invisible” can help protect your code. As I discovered myself.

   Sample of an actual scrambled sub:
   Sub uuvvvuwuvuvwwwuuuuuwwwvuwuuuuv()
   Dim uuuvvwuvwuuuvwwwwvvvuvvwwwwuvu As Integer, uvuvuvvwvuvuwwvwwvwuwwvuwuvwuv As Integer
   Dim wwwuvwwuwvwuvwwvuvvvvuuuwuuuvv As New Collection
   Dim uvwuvuvwwvvuvvwvuuuuuwwuvwwuuu As Range, vvvwvvuuwwuwuwuvwvvuwvuwwuwuvv As Worksheet
   Dim wwuvuwuwwuvuwwwvwvuvuvuvvwvuvu
   wwuvuwuwwuvuwwwvwvuvuvuvvwvuvu = MsgBox(“Press Yes to wwuvuwuwwuvuwwwvwvuvuvuvvwvuvu cover-generation for all docs on sheet RevHistory”, vbYesNo)
   If wwuvuwuwwuvuwwwvwvuvuvuvvwvuvu vbYes Then Exit Sub
   On Error Resume Next
   Application.DisplayAlerts = False
   Application.ScreenUpdating = False
   Set vvvwvvuuwwuwuwuvwvvuwvuwwuwuvv = ActiveSheet
   Set uvwuvuvwwvvuvvwvuuuuuwwuvwwuuu = ThisWorkbook.Sheets(“RevHistory”).Range(“RevHist.DB”).Columns(1)
   For uuuvvwuvwuuuvwwwwvvvuvvwwwwuvu = 1 To Application.WorksheetFunction.CountA(uvwuvuvwwvvuvvwvuuuuuwwuvwwuuu)
   wwwuvwwuwvwuvwwvuvvvvuuuwuuuvv.Add uvwuvuvwwvvuvvwvuuuuuwwuvwwuuu.Cells(uuuvvwuvwuuuvwwwwvvvuvvwwwwuvu, 1), uvwuvuvwwvvuvvwvuuuuuwwuvwwuuu.Cells(uuuvvwuvwuuuvwwwwvvvuvvwwwwuvu, 1)
   Next uuuvvwuvwuuuvwwwwvvvuvvwwwwuvu
   Call uwuwvuuvuvwuuuvwwvvuuvwvuuuuuw
   For uvuvuvvwvuvuwwvwwvwuwwvuwuvwuv = 1 To wwwuvwwuwvwuvwwvuvvvvuuuwuuuvv.Count
   Call vwwwuuwvwvuwwvwwuuwuvvuuvuvuvw(wwwuvwwuwvwuvwwvuvvvvuuuwuuuvv(uvuvuvvwvuvuwwvwwvwuwwvuwuvwuv))
   Next uvuvuvvwvuvuwwvwwvwuwwvuwuvwuv
   Call vvuvwwvwwvwvwuwuvvwvwvwwwwuvww(True)

   Anyone can descramble that?

   Bart Verbeeck

10. Oh yes, one more thing, and maybe a tip for users of other “invisibility” or “scrambling” tools: it’s best to open the workbook to be scrambled with macro’s disabled, because otherwise you can generate some serious excel runtime error(s)…

    Bart

11. One more thing, and then I’ll shut up ;-)

    At first I also had “light” scrambling, but that was still too readable. I implemented “heavy” scrambling because the human mind can simply not remember the difference between uuuiuiuuiuvuiuiuv and uuuiuiuuiuvuiuiiv (noticed the difference?) very long….

    By the way: I always wondered why John didn’t protect his PUP more heavily…

    Bart

12. Bart –

    Sub mySub1
    Dim iOne As Integer, iTwo As Integer
    Dim Collection1 As New Collection
    Dim rOne As Range, wksOne As Worksheet
    Dim vOne
    vOne = MsgBox(“Press Yes to vOne cover-generation for all docs on sheet RevHistory”, vbYesNo)
    If vOne vbYes Then Exit Sub
    On Error Resume Next
    Application.DisplayAlerts = False
    Application.ScreenUpdating = False
    Set wksOne = ActiveSheet
    Set rOne = ThisWorkbook.Sheets(“RevHistory”).Range(“RevHist.DB”).Columns(1)
    For iOne = 1 To Application.WorksheetFunction.CountA(rOne)
    Collection1.Add rOne.Cells(iOne, 1), rOne.Cells(iOne, 1)
    Next iOne
    Call mySub2
    For iTwo = 1 To Collection1.Count
    Call mySub3(Collection1(iTwo))
    Next iTwo
    Call mySub4(True)

    ….

    Looks like a syntax error in the MsgBox ;-)
    …Michael

13. Doug: your description of the obfuscator sounds like the code one of my colleagues writes! The first thing I do when I open it is use IndenterVba from http://www.oaltd.co.uk/Excel/Default.htm on it.

    The next thing I do, is cut and paste it into my text editor, where I replace all of the single letter variables using regular expressions.

    Using a text editor (I like vim) with regular expressions, I could make quick work of cleaning up your “obfuscated” code, Bart.

    MM

14. Yeah, you can just use find and replace on the var decs at the top right?

15. You’re right guys, replacing the “scrambled” variable names isn’t that hard…
    But, the point is that by “scrambling” the code, you loose all meaningfull variable names…
    Sure, you can get to ione, itwo, collection1,…, but these don’t actually say anything about what they’re about… This becomes much more clear when you use public variables used throughout your code…

    Of course, scrambling becomes more interesting the more lines you have… But the more lines you have, the more effort you put into it and the more valable it becomes…

    And: if you really discourage someone to “steal” your code by scrambling it and thus by making it harder to understand, maybe they will pay that 20 euro’s or so you ask for your hard work, instead of trying to decipher what you wrote…

    Scrambling is like physical security: you just make it more difficult in order to discourage people.
    But it is not a 100% guarantee. You put extra locks on your door, no because they turn your house into Fort Knox, but because any thief will go to your neighbour’s easier locks…

    And all this because Microsoft doesn’t implement good protection of any VBA code ;-)
    There are alternatives of course: let’s all go to VSTO.

    Bart

16. “There are alternatives of course: let’s all go to VSTO.”

    .net code is NOT very secure, it’s easier to get at .net code than VB6 code.

17. I worked with a guy years ago who obfuscated his code when he left the company in a huff. He wanted to hold the code ransom to get some remuneration, claiming that technically he had fulfilled his employment obligation since he left working code – it was just unmaintainable. The guy was an a**hole.

    Fortunately, we found his original code. still on his hard drive. Guess what? It was really, really poorly written to start with! We dubbed it “self-obfuscating code”.

    Personally, I don’t password protect my code, unless the client wants me to. Then I give him the password and save the password in a file where I did the development, because the client will almost certainly lose it.

18. Ross,

    You wrote ‘.net code is NOT very secure, it’s easier to get at .net code than VB6 code. ‘.
    Could be. But I was thinking mainly about COM add-ins, compiled into dll’s.
    I imagine those can not be cracked, unless you’re a experienced hex editor…

    Bart

19. A further refinement would be to use : (colon) to combine two or more lines.

    Sub HappyStPatsDay(): Dim OTheMorning As Shape: Dim TwoYou As Double: On Error Resume Next: OTheMorning.Top = TwoYou: MsgBox “Burp”: End Sub

20. Hi Bart;

    I think .net is marshalled via a runtime interface to work with com, the code (viz, com or otherwise) is still .Net, which can in the fisrt instant be accessed is a human readable form with the Ilsam.exe which comes with the SDK.
    The reason this happen is becasue .Net is complied “just in time” from the CLR so all .net code (C# etc) is compled into a MSIL (Microsoft Intermediate Language) in the .dll…..

    or somthing along these line.

    I can tell you this for sure, com with .Net is a bit of a pain in the a*s. ;-)

21. I was delighted to find my product under discussion here, and wanted to weigh in with my (not exactly unbiased) opinions.

    For me, the theft of VBA code was really a problem. My customers had expressed concern that competitors could see our entire code (comments and all) simply by cracking the VBA password. In my case, much of the proprietary knowledge was actually in the comments which really served as the tech documentation for the code, which captured a certain complex, proprietary, mathematical model important to my customer. Reasonable people could (and have!) questioned my sanity for using VBA to implement such proprietary code but basically each language/environment has pros and cons and if a tool is otherwise a great fit for the job (and Excel/VBA was otherwise nearly perfect for my application) why switch to another tool just because the source code security is lacking? Anyway, I didn’t want to be FORCED to switch tools JUST for this reason, and when I realized that a fairly simple program could solve this problem via source code obfuscation, I decided to devote some spare vacation days and weekends to the task, and Invisible Basic (a free and open source product) was born. There have already been over 300 downloads (a marked increase occured after John’s mention of it on this blog, though, so this might not be a fair argument?) so there must be at least a few others with the same problem.

    I want to point out the “VSTO or DLL or COM components” mentioned by others to solve this IP protection problem introduce an extra level of complexity compared to a plain vanilla, Excel 97 compatible, pure Excel + VBA solutions. For example, you can no longer distribute your application as a single workbook that your customers can just open and use, say, from a link on your web site, regardless of the Excel version they are using. Instead, you probably are going to need to write an installation program to, say, register your COM components, copy them into the right places, etc. etc. VBA source code obfuscation provides a solution that lets you remain within the “Excel 97 compatible VBA sandbox” rather than having to go to the “install extra stuff and be sure you can interface to it first and have the right Excel version” route. Your application’s source code can be protected, and yet feel just like a simple workbook with pure Excel 97 compatible VBA to your users; with the other approaches it feels more like a stand-alone application that just happens to use (and in some cases will only work with a newer version of) Excel. Email a workbook to a friend, no problem. Email an EXE that installs your Excel app + Com components, and the attachment may be stripped by corporate anti-virus software. Seems like a small thing, but there are a lot of these small things, and they DO add up, believe me…

    For example, I’ve had a lot of trouble preventing Excel from crashing when I call a FORTRAN DLL from within VBA. Maybe I just couldn’t figure it out, but I could not find anywhere documented how you need to handle numerical errors within a FORTRAN DLL called within Excel in a manner such that you never, ever, cause Excel to GP fault. With a pure VBA solution, little “interfacing related details” like this, that can drive you nuts, simply never come up. In pure Excel+VBA, stuff like this “just works” as you float down the well-travelled river chosen by the vast majority of Excel users…this lets you focus more on what you are trying to do.

    Regarding the effectiveness of source code obfuscation at protecting your code, actual examples of obfucated code provide the strongest arguement. Can you figure out what this simple Invisible Basic obfuscated code module does?:

    Option Explicit
    Public Const d As Double = -9.999999E+30
    Private Sub assert(g As Boolean)
    If (Not g) Then Stop
    End Sub
    Public Function h( _
    i As Variant, j As Boolean) As Double
    Dim k As Double
    Dim l As Double
    assert IsArray(i)
    assert LBound(i) = 0 And UBound(i) = 2
    l = i(1) ^ 2 – 4 * i(0) * i(2)
    If (i(0) = 0) Then
    If (i(1) = 0) Then
    k = d
    Else
    k = -i(2) / i(1)
    End If
    ElseIf (l

22. {Sorry, my post was too long and got clipped…here is the rest of it – John Gunther}

    Option Explicit
    Public Const d As Double = -9.999999E+30
    Private Sub assert(g As Boolean)
    If (Not g) Then Stop
    End Sub
    Public Function h( _
    i As Variant, j As Boolean) As Double
    Dim k As Double
    Dim l As Double
    assert IsArray(i)
    assert LBound(i) = 0 And UBound(i) = 2
    l = i(1) ^ 2 – 4 * i(0) * i(2)
    If (i(0) = 0) Then
    If (i(1) = 0) Then
    k = d
    Else
    k = -i(2) / i(1)
    End If
    ElseIf (l

23. {Still clipping it…one more try.}

    See see the Invisible Basic 3.0 User’s Guide at
    http://sourceforge.net/docman/display_doc.php?docid=31858&group_id=154662 for the original, unobfuscated, version of this code.

    For a bigger real-world example, I’ve run the Invisible Basic program itself through itself, which you can view at http://invisiblebasic.sourceforge.net/dogfood.html. One look at this monster will convince you that, with most complex applications (such as Invisible Basic itself) source code obfuscation removes almost all of the proprietary know-how from your code.

    Some other points:

    Invisible Basic requires that you save the obfuscated code in a differently named workbook; this eliminated the danger of overwriting the real, unobfuscated code mentioned in one comment.

    Regarding “bulked up” variable names. The use of the smallest possible variable names creates an important side benefit: smaller workbooks.

    Another advantage of obfuscation over COM components: you can give domain experts who know Excel a workbook that contains all the code, and is functionally equivalent to the protected version. My coworkers on the application I mentioned were domain experts who were OK with reading VBA within an Excel workbook but would have had trouble juggling the tools required to use the debugger or modify code within a COM component. When we wanted to distribute to a wider audience, we were just one command away (Invisible Basic’s “Save Invisibly As…”) from creating an appropriately obfucated version.

    Finally, Excel + VBA is a powerful platform fully capable of implementing proprietary products worthy of protection. John may have chosen to release his PUP code for a small fee, just as I chose to release the Invisible Basic code, but the point is some OTHER developer (or firm) may choose not to release their Excel/VBA code. Ideally, this decision should be INDEPENDENT OF the software platform you decide to use. Invisible Basic gives developers who CHOOSE to use the “Excel 97 compatible Excel/VBA platform” for their solutions the same freedom to chose NOT to distribute their source code as developers on other, “compiled to machine code” platforms have.

    John Gunther, author of Invisible Basic

---

Posting code? Use <pre> tags for VBA and <code> tags for inline.