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 stored as a salted SHA-1 digest, obfuscated into the PROJECT stream inside vbaProject.bin — a gate on the UI, not a key protecting the data. This means VBA project passwords are removable by structural editing, 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 appends a random 4-byte key to the password, takes the 20-byte SHA-1 digest of that, and stores the digest (obfuscated, not encrypted) in the PROJECT stream inside vbaProject.bin for .xlsm files, and in the equivalent storage for .xls files.

When you reopen the workbook and try to view macros, Excel computes the digest for whatever password you enter, using the stored per-project key, and compares it against the stored digest. 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 the MS-OVBA compression algorithm, a run-length encoding scheme defined in [MS-OVBA] 2.4.1), 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 source code is stored compressed but unencrypted in the same file, (2) the verification check happens in software you control (Excel running locally) and is enforceable only by the IDE, (3) the stored digest is a verification value rather than a key — nothing in the file is encrypted with it, so it can be removed structurally without any cryptanalysis.

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 entry in the PROJECT stream inside that part holds the obfuscated password-hash structure — a random 4-byte key plus the 20-byte SHA-1 password hash, hex-encoded — and a protected project is identified by that structure together with a NULL GUID project ID.

The standard removal approach: open the .xlsm with any ZIP tool (7-Zip, the built-in Windows ZIP), extract vbaProject.bin, replace the ID, CMG, DPB and GC entries in the PROJECT stream with those from an unprotected project (or blank the DPB entry), keeping the file size unchanged, then 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 entry is the same and in the same place; only the containing file differs — .xls keeps the same VBA project inside the workbook's OLE2 container. The same removal technique applies.

oletools' olevba and oledump read the macro source out of a password-protected project without any patching, and a hex editor handles the structural edit of the protection entries. There's no cryptographic work involved.

Legal and ethical considerations

Removing VBA password protection from your own files is generally lawful — you're modifying a file you own, not breaking encryption or accessing someone else's data. Anti-circumvention rules in some countries are stricter about removing technical protection measures even from a file you own, so this is not a blanket assurance.

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 removal is a structural edit; 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 protection entries in the PROJECT stream
Use a hex editor to find the ID, CMG, DPB and GC entries and replace them with the corresponding entries from an unprotected project (or blank the DPB entry), keeping the file size unchanged. These entries are keyed to the project ID, so replacing only one of them can leave Excel still reporting the project as unviewable.
5
Repackage and verify
Replace vbaProject.bin in the ZIP and rename back to .xlsm. Open in Excel and check the VBA editor. If the entries were replaced as a matched set, macros are visible without a password prompt; if Excel still asks, restore from the backup and retry.

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 edits the stored protection entries in the PROJECT stream — the macro source and its 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?

Not as a protection mechanism in any standard Office file format: the design has been verification-only since Office 97, and the stored DPB value is a salted SHA-1 verifier rather than a key that encrypts the macro source. Two qualifications: a document protected with a password to open is genuinely encrypted as a whole package, so its VBA project is covered by that file-level encryption; and third-party VBA obfuscators and compilers do exist for real code protection outside the Office format itself.

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