I've been asked to update some Excel 2003 macros, but the VBA projects are password protected, and it seems there's a lack of documentation... no-one knows the passwords.
Is there a way of removing or cracking the password on a VBA project?
I've been asked to update some Excel 2003 macros, but the VBA projects are password protected, and it seems there's a lack of documentation... no-one knows the passwords.
Is there a way of removing or cracking the password on a VBA project?
With my turn, this is built upon kaybee99's excellent answer which is built upon Đức Thanh Nguyễn's fantastic answer to allow this method to work with both x86 and amd64 versions of Office.
An overview of what is changed, we avoid push/ret which is limited to 32bit addresses and replace it with mov/jmp reg.
Tested and works on
how it works
Create a new file with the same type as the above and store this code in Module1
Paste this code in Module2 and run it
If the file is a valid zip file (the first few bytes are
50 4B
-- used in formats like.xlsm
), then unzip the file and look for the subfilexl/vbaProject.bin
. This is a CFB file just like the.xls
files. Follow the instructions for the XLS format (applied to the subfile) and then just zip the contents.For the XLS format, you can follow some of the other methods in this post. I personally prefer searching for the
DPB=
block and replacing the textwith blank spaces. This obviates CFB container size issues.
My tool, VbaDiff, reads VBA directly from the file, so you can use it to recover protected VBA code from most office documents without resorting to a hex editor.
Have you tried simply opening them in OpenOffice.org?
I had a similar problem some time ago and found that Excel and Calc didn't understand each other's encryption, and so allowed direct access to just about everything.
This was a while ago, so if that wasn't just a fluke on my part it also may have been patched.
Colin Pickard has an excellent answer, but there is one 'watch out' with this. There are instances (I haven't figured out the cause yet) where the total length of the "CMG=........GC=...." entry in the file is different from one excel file to the next. In some cases, this entry will be 137 bytes, and in others it will be 143 bytes. The 137 byte length is the odd one, and if this happens when you create your file with the '1234' password, just create another file, and it should jump to the 143 byte length.
If you try to paste the wrong number of bytes into the file, you will lose your VBA project when you try to open the file with Excel.
EDIT
This is not valid for Excel 2007/2010 files. The standard .xlsx file format is actually a .zip file containing numerous sub-folders with the formatting, layout, content, etc, stored as xml data. For an unprotected Excel 2007 file, you can just change the .xlsx extension to .zip, then open the zip file and look through all the xml data. It's very straightforward.
However, when you password protect an Excel 2007 file, the entire .zip (.xlsx) file is actually encrypted using RSA encryption. It is no longer possible to change the extension to .zip and browse the file contents.
I've built upon Đức Thanh Nguyễn's fantastic answer to allow this method to work with 64-bit versions of Excel. I'm running Excel 2010 64-Bit on 64-Bit Windows 7.
Create a new xlsm file and store this code in Module1
Paste this code in Module2 and run it
DISCLAIMER This worked for me and I have documented it here in the hope it will help someone out. I have not fully tested it. Please be sure to save all open files before proceeding with this option.