According to the manual, XLS Padlock creates a temporary virtual hidden drive and saves the protected workbook there. Is my protected workbook with vba code safe in that drive?
Having a virtual workbook is enough to prevent average users from copying it but that’s not enough: you should also use our other XLS Padlock features such as formula protection or better, our VBA compiler. This ensures you that your VBA code will be safe, because it will no more exist “as it” in the compiled workbook. The goal is to make your workbook only usable in a compiled form, so that if someone manages to retrieve the workbook, it becomes useless: for instance, without some vital formulas or VBA code that were replaced by XLS Padlock’s internal formula calls.
Thanks for replying.
I really concern about the safety of the protected workbook, hence I conducted a couple of ‘penetration tests’ to see how safe it is from the position of an average user. Here are my results:
- XLS Padlock doesn’t disable all existing Excel add-ins when loading a secured workbook by default as stated in the Security/Excel Add-ins tab. It still allows some xlam add-ins including some free tools I got from internet.
- If I did not select the “Disable all ribbons and toolbars” when compiling to exe, some free xlam add-ins as I mentioned above could easily strip the whole protected workbook from that virtual hidden drive.
I won’t provide details how I can strip the protected workbooks by using a certain xlam tool, but if you want to challenge what I’m saying here, just upload your compiled exe with the “Disable all ribbons and toolbars” unselected, I’ll return your protected workbook.
I’m wondering if an average user who is a little bit more clever than me can strip my protected workbook from that hidden virtual drive even with the “Disable all ribbons and toolbars” selected when compiling.
I really don’t want to use the “Disable all ribbons and toolbars” option as I still want the workbook users are able to format the workbook to what they want.
The VBA compiler is so limited in capability and it needs a lot of improvements in order to put it into practical use.
Another bad news, sorry. Even with the “Disable all ribbons and toolbars” selected when compiling, the protected workbook is miserably stripped after 5 sec.
Thank you for your feedback. By default, XLS Padlock is permissive unless you configure it according to your needs (security vs functionality). For instance:
- XLS Padlock disables COM add-ins but not XLAM add-ins unless you activate a specific option.
- it doesn’t prevent saving workbooks as external files, again without activating an option.
We have many different customers with different needs, so we can’t activate all secure options by default.
Your XLAM tool certainly uses VBA code to save the protected workbook. But if you activate the proper options of XLS Padlock, it should become useless. If you are OK, try your method to extract this protected workbook:
https://download.xlspadlock.com/temp/markbookPROT.exe
If it still works, feel free to send us a link to it and we’ll see how to counter it.
Anyway, storing the workbook in a virtual drive is practical and doesn’t offer 100% security. That’s why we recommend to use formula protection and VBA compiler features of XLS Padlock. Sure, it requires extra work.
Why do you say that the VBA compiler is limited? It supports a lot of VBA code and functions! Some customers moved thousands of lines into it. Of course, additional work is required but it is the best protection for VBA available.
Thanks for your prompt response. I highly appreciate it as it indicates the excellent support from XLS Padlock.
I was unable to do the same thing to your provided exe file. It appears that that file was compiled using a newer version rather than the current version that I’m using which is V2.5.0. However, there is a bug that prevents me to save the secure file twice, please double check.
On the other hand, I successfully managed to strip the original workbook from the demo file exe file from your site.
http://download.xlspadlock.com/Markbook-Demo-32.exe
You may want to get the stripped workbook at the below link to have a look.
https://drive.google.com/drive/folders/0B90H1GMfbYBkdW9hTkZ5SWlTQk0
The procedure that I did is at below:
-
Download the Invisible Basic at the below link
https://sourceforge.net/projects/invisiblebasic/ -
Import the bas file into VBE
-
Replace the code
obfuscate_workbook_as wb, filename
by the below code
wb.SaveAs fileName, Password:=“whateverpassword”
- Save the workbook as InvisibleBasic.xlsm
- Run the XLS Padlock protected workbook exe file
- Open the InvisibleBasic.xlsm file
- Save the the XLS protected workbook a xlsc secure file
- Press Alt + F8 to envoke the Macro run panel
- Run the invisible_basic_save_invisibility_as
- Save the file with a name with default extention .xls
- Accept the XLS padlock promp t to save the secure workbook again
- Rename the file extension .xls to .xlsm
- Open the file with the above password
- Hit ALT + F11 to open the VBE and you will be blocked by a password to see the VBA
- Close the file and follow the link below to remove this password then you will get the full unprotected file
https://stackoverflow.com/questions/22663809/excel-vba-password-via-hex-editor
I would expect that you can fix this flaw soon. I would like to suggest that you should include a VBA Obfuscator into the software, at least it is something like the Invisible Basic or better as a final protection measure if the hackers somehow to get the source code.
The built-in VBA compiler indeed requires a lot more work if I want to compile my code into and make it works. If I had to do that myself, I would rather spend time to learn another better programming language to get away from VBA.
Thank you for the long feedback. Our Markbook-Demo-32.exe isn’t protected against VBA hacks because we wanted to allow users to go to VBE and see how the VBA compiler allowed us to strip existing VBA code and replace it while keeping code functional. That’s why your hack works on Markbook-Demo-32.exe
However, if you try the activation version of Markbook-Demo-32, it shouldn’t be the same.
You can also stop the VBA hack in version of XLS Padlock 2.5 by checking:
Finally could you tell us more about
“However, there is a bug that prevents me to save the secure file twice, please double check”
because we did not get this problem.
Why version of Excel do you use?
I’m using Excel 2013 and 2016. Same problem happens when i tried to save the secure file to the same name from second time. I work around by saving to different name say file1, file2 and so on. That problem does not happen to the exe file compiled by v2.5.0.
Do you get any error message for saving with the same name?
In the v2.5.0, i have no problem with saving secure file.
Sure, but how do you know there is a problem when saving twice with the EXE file we sent you? Do you get any error message?
I got two errors:
Cannot create file “C:\TEST\test1.xlsc”. The process cannot access the file because it is being used by another process
GXLSPlock error: the add-in has fired an exception.
Cannot create file “C:\TEST\test1.xlsc”. The process cannot access the file because it is being used by another process
Just to keep you informed that we fixed the problem in the final release of XLS Padlock 3. Thank you for your help!
Thank you. It works now.