VBA source code still inside Secure Build Application - SOLVED

Today I had a huge surprise when a member of our test team showed me the VBA source code of an application compiled with XLS Padlock.

The reason I bought XLS Padlock was because I believed it would first compile the VBA code and then remove the source code; resulting in an EXE without the source code which could be distributed to anyone.

For now, I can only prevent the user to access the VBA editor, which I apparently did insufficient, since he could access the VBA Code by the debug button of the default VBA error handler. The fact that this team member could open the VBA editor is the minor worry I have.

My real worry is that the VBA source code is actually inside the EXE, which i have build with the [Build Secure Application] functionality.

Did I use XLS Padlock in the wrong way?
Is there any way to completely prevent the EXE to contain the (human readable) VBA source code?
If so, how?

XLS Padlock doesn’t remove the VBA code itself: please see the user guide or tutorial. You must move parts or functions of your VBA code to the XLS Padlock’s VBA compiler editor, and these parts will be compiled into bytecode. You have to replace your VBA code by calls to protected functions.
Did you also use the “Lock VBA Project” feature?

Darn, then I really should have RTFM better before I bought the product.

Knowing that my applications has around 15 VBA classes, 25 modules and 3 forms, I guess that moving all that code to the XLS Padlock VBA compile section, would make my application hard to maintain.

How secure is the VBA source code inside the EXE when turning on all the lock down features, such as [Lock VBA Project], Excel’s VBA source code password, [Disable VBA Editor], etc?

Is it hard to retrieve the VBA code from the executable?

ArthurBorsboom said:

Knowing that my applications has around 15 VBA classes, 25 modules and 3 forms, I guess that moving all that code to the XLS Padlock VBA compile section, would make my application hard to maintain.

Click to expand...

Actually you don’t have to move all of your entire VBA code: only parts that should make your VBA code useless and render your workbook non-functional if they are missing. The goal is that if someone manages to extract the original Excel workbook, the latter remains “crippled” without the compiled code.

The best way is to break your code into parts, and the most important parts (secret ones) should be compiled into bytecode to prevent your customers from copying them.

Even with the features you mentioned, if you don’t use our VBA compiler, the VBA code will remain in the compiled workbook, so there is still a possibility for an advanced hacker to gain access to your VBA code. This is anyway the same problem for any other Excel protection software.

The sole real secure solution is to convert parts of your VBA code into bytecode thanks to our VBA compiler. Sure, it can be time-consuming, so try to convert portions of code that shouldn’t change each time.

Alright. Thanks for the explanation; it becomes clear now.

How is the performance of the parts of code that will be moved into XLS Padlock?
Is it smart to do this for function calls which are being called many times (100.000+)?

It will of course slow down things a little because it’s an external call, but the best is to try yourself. We can’t tell you without testing your code…

Okay. Thanks for the explanation.
You can close this topic.