Technical Guide

Recovering an Excel VBA Project Password — How It Actually Works

Excel's VBA project password feels like a security feature — you're prompted for a password to view macro code. In practice, it's structural verification, not encryption. The macro code itself is stored in plaintext (just compressed). The password is a 4-byte hash that gates the UI, not the data. This means VBA project passwords are removable in seconds without any cracking. This guide explains exactly how, why, and the legal/ethical context.

What VBA project protection actually does

When you set 'Lock project for viewing' in the VBA editor (Tools → VBAProject Properties → Protection), Excel computes a 4-byte SHA-1 truncated hash of the password and stores it in the workbook's vbaProject.bin stream (for .xlsm files) or in a similar location for .xls files.

When you reopen the workbook and try to view macros, Excel computes the hash of whatever password you enter and compares against the stored 4-byte hash. If they match, you get access. If they don't, you get the 'Project is unviewable' message.

The macro source code itself isn't encrypted. It's stored in the same vbaProject.bin file (compressed with Microsoft's CompressedDataFormat algorithm), and any tool that bypasses the verification check can read it directly.

Verification ≠ encryption

VBA project passwords are like a doorbell — they ask politely. A real lock would encrypt the source code and require the password to decrypt. Microsoft chose verification for performance and compatibility reasons.

Why this is structurally weak

Three weaknesses combine to make VBA password protection trivially bypassable: (1) the hash is only 4 bytes (32 bits, 2^32 possible values, with massive collision rate), (2) the verification check happens in software you control (Excel running locally), (3) the source code is stored in plaintext in the same file.

Any of these alone would still be weak; together they make the protection nominal. A user who controls the bytes of the .xlsm file can edit the stored hash to a known value, then enter the corresponding known password to bypass the check. Or simply patch out the verification logic in memory at runtime.

The structural removal approach

Modern .xlsm files are ZIP archives containing XML and binary streams. vbaProject.bin lives at xl/vbaProject.bin inside the archive. The DPB (Data Protection Bytes) field within this binary stream stores the 4-byte hash plus a 'protection enabled' flag byte.

The standard removal approach: open the .xlsm with any ZIP tool (7-Zip, the built-in Windows ZIP), extract vbaProject.bin, locate the DPB sequence, replace the protection flag with the 'no protection' value, save back. Net effect: Excel no longer prompts for a password and the macro source becomes visible.

This works because the source code never depended on the password — only the UI layer did. Removing the UI gate doesn't decrypt anything because nothing was encrypted.

What about .xls (legacy binary format)?

Office 97-2003 binary files (.xls) store VBA in a similar OLE2 structure. The DPB is in the same conceptual location but with slightly different binary layout. The same removal technique applies — patch the protection flag.

Tools like vbaProjectPasswordRemover, oletools, and even simple hex editors handle this routinely. There's no cryptographic work involved.

Legal and ethical considerations

Removing VBA password protection from your own files is fully legal in every Tier 1 jurisdiction. You're modifying a file you own, not breaking encryption or accessing someone else's data.

Removing protection from someone else's file you don't own crosses into unauthorized access territory and may violate computer-misuse laws. Even if the cryptographic effort is trivial, the legal status depends on authorization, not technical difficulty.

Common legitimate scenarios: maintaining macros where the original developer left the company; auditing third-party templates for security issues; recovering work from your own files when you've forgotten the password.

Why Microsoft hasn't fixed this

VBA project protection in modern Microsoft 365 is functionally identical to Office 97-era protection. The underlying design predates contemporary security thinking. Backward compatibility (and the fact that real protection lives at the file-open password layer) means Microsoft has no strong incentive to upgrade.

The unstated message from Microsoft is: if you need real VBA code protection, distribute compiled DLL add-ins instead. The VBA password is for casual obfuscation, not security.

When real Office encryption matters

If your file has both VBA project password AND a file-open password (the password that prompts when you open the file at all), the file-open password is real encryption. VBA password is removable in seconds; file-open password recovery depends on password complexity.

Identifying which protection layer you face is the first question for any 'Excel password' problem. Excel sheet protection and VBA project protection are removable structurally. File-open password is where actual cryptographic recovery work lives.

Removing VBA project password — step by step

1
Make a backup copy
Always work on a copy of the .xlsm or .xls file. The DPB edit is structural and a single byte error can corrupt the workbook.
2
Open the file as a ZIP archive (.xlsm)
Rename foo.xlsm → foo.zip and open with 7-Zip, or use 7-Zip's 'Open archive' on the .xlsm directly.
3
Locate vbaProject.bin
Inside the archive: xl/vbaProject.bin. Extract it to a temporary location.
4
Patch the DPB protection flag
Use a hex editor to find the DPB byte sequence. Standard tools (vbaProjectPasswordRemover) automate this. Replace the protection-enabled byte with the no-protection value.
5
Repackage and verify
Replace vbaProject.bin in the ZIP and rename back to .xlsm. Open in Excel — VBA editor should now show macros without password prompt.

Frequently Asked Questions

Is removing VBA password legal?

Yes for files you own. Unauthorised modification of someone else's file may violate local computer-misuse laws regardless of the technical triviality.

Will the macros still work after removal?

Yes. Removal only changes the protection flag — macro source and behaviour are unchanged.

Why does Microsoft still ship this weak protection?

Backward compatibility plus the design intent that VBA password is anti-tamper UX rather than security. Real code protection requires compiled DLL distribution.

Does this work on Excel for Mac?

Yes. Mac Excel uses the same .xlsm format with the same VBA structure. Same removal technique applies.

What if my VBA password is also the file-open password?

They're separate — different storage locations and different protection mechanisms. File-open password recovery is real cryptographic work; VBA password removal is structural.

Are there any cases where VBA password is real encryption?

No, in any standard Office file format. The design has been verification-only since Office 97. Third-party VBA obfuscators and compilers do exist for real code protection.

Can Excel itself remove the password if I have it?

Yes — VBA editor → Tools → VBAProject Properties → Protection → uncheck 'Lock project'. But that requires entering the password first. Removal techniques cover the case where you forgot or never had it.

Need Office password recovery?

Run a free analysis — encryption type detected automatically, fast techniques tried first, pay only on success.

Run Free Analysis