Finite-key candidate

Office 97-2003 RC4 — Hashcat Modes 9700 / 9800

TL;DR — Microsoft Office 97 through 2003 (.doc, .xls, .ppt formats) used a Standard Encryption Header with 40-bit RC4. The 40-bit key length makes qualifying files candidates for finite-key analysis, but exact variant, file health, compute budget, and output verification still matter.

What Office 97-2003 actually encrypted

Office 97 introduced password protection across Word, Excel, and PowerPoint using a Compound File Binary Format (CFB, also called OLE2) container. Inside the container is a hidden 'EncryptionInfo' stream that holds salt, verifier, and mode metadata.

The encryption itself is RC4 with a 40-bit key by default. Microsoft offered alternative cipher choices through Crypto API providers (Microsoft Base Cryptographic Provider, Microsoft Strong Cryptographic Provider, Microsoft Enhanced Cryptographic Provider), but the default was 40-bit RC4 for compatibility.

Hashcat distinguishes two modes for this generation: 9700 covers the MD5-based key derivation used by Word and Excel (.doc, .xls); 9800 covers the SHA-1-based derivation used by PowerPoint (.ppt). The cipher and 40-bit key length are identical — only the hash function in the KDF differs.

File extensions: .doc, .xls, .ppt (Office 97-2003 binary)
Cipher: RC4 with 40-bit key
9700: Word/Excel — MD5-based KDF
9800: PowerPoint — SHA-1-based KDF
Container: OLE2 / Compound File Binary (CFB)

Why 40-bit Office RC4 is recoverable

Forty bits = 2^40 ≈ 1.1 trillion possible keys. By 2026 hardware standards, this entire keyspace is exhaustively searchable on modern GPU clusters within tractable timeframes. Recovery doesn't require guessing the password — it can target the cipher key directly.

Once a cipher key is established, the document body can be checked without relying on the original password length. A 4-character password and a 40-character password still map into the same finite key space for this legacy scheme.

After a valid key is established, the file can be re-saved without password protection. Check content, formulas, charts, embedded objects, signatures, and metadata on the individual output rather than assuming byte identity.

How to identify Office 97-2003 files

The file extension is a strong signal: .doc (Word), .xls (Excel), .ppt (PowerPoint) — without the trailing 'x' that newer Office formats use. Internally, the OLE2 container starts with the magic bytes D0 CF 11 E0 A1 B1 1A E1.

An OLE2 inspection tool (oletools, olebrowse, 7-Zip 'Open archive') reveals the structure. The EncryptionInfo stream is present in protected files. Tools like office2john (from John the Ripper) or oledump.py extract the hash without requiring the password.

The hash format uses the oldoffice prefix followed by a numeric type identifier (0-4). Types 0 and 1 are RC4 with 40-bit keys (modes 9700/9800). Type 3 is also RC4 40-bit but uses a slightly different verifier path. Type 4 is the modern AES-128 path used by Office 2007+ — that's a different mode entirely (mode 9410).

Why these files still appear in 2026

Office 2007 introduced the OOXML formats (.docx, .xlsx, .pptx) with stronger encryption, but the legacy binary formats remained fully supported in every Office version through Microsoft 365. Many enterprise document management systems standardised on .doc/.xls during the 2000s and have kept the format internally for compatibility.

Common modern sources: long-archived legal disclosure files, mid-2000s financial templates, government documents that predate the Office 2007 rollout, and files exported from accounting systems that still default to .doc/.xls for compatibility.

When organisations migrate document archives, the original encryption is preserved by default — not upgraded. So a memo encrypted in 2003 with Office XP is still 40-bit RC4 today, even after several round-trips through modern systems.

Office 97-2003 vs OOXML side-by-side

Office 2007 was a complete rewrite of the file format and encryption. OOXML files (.docx, .xlsx, .pptx) are ZIP containers with XML inside, encrypted using AES-128 by default and AES-256 in Office 2010+. The Hashcat modes for the new family are 9400 (Office 2007), 9500 (Office 2010), 9600 (Office 2013+) — all categorically harder than 9700/9800.

If you have a choice between distributing an .xls and an .xlsx and confidentiality matters, .xlsx is materially stronger. If you're recovering an old document, the .xls/.doc/.ppt path is the favourable case.

Practical recovery flow

Standard flow for recovering a mode 9700/9800 file: (1) drop the file into a browser-based analyser to confirm format and version — this happens client-side, file content never leaves the browser; (2) run a free check against fast attack techniques — these complete quickly and identify whether the password is in any common pattern; (3) for documents the free check doesn't crack, the cipher-key search runs on GPU clusters with bounded duration.

The honest expectation: 40-bit RC4 documents are the strongest candidates for this technical route. Duration and outcome still depend on parseable input, implementation details, compute budget, and verification.

Frequently Asked Questions

Is recovering my own Office 97-2003 file legal?

Recovering access to a file you own or are authorised to access is generally different from unauthorised access, but the law depends on the jurisdiction and facts. Document ownership and authorisation must be confirmed before paid recovery proceeds.

How long does mode 9700/9800 typically take?

We don't publish a fixed timing because it depends on queue, implementation, machine availability, file health, and verification. The finite key space defines the technical route, not a delivery promise.

Will the recovered file be identical to the original?

The process aims to preserve readable content, formulas, embedded objects, charts, and metadata. Verify the resulting file and any signatures or compliance requirements individually.

Why doesn't password length matter for mode 9700?

The KDF always produces a 40-bit key regardless of password length. A 6-character password and a 60-character password yield keys from the same 2^40 space. Recovery operates on the keyspace, not the password directly.

How is mode 9700 different from mode 9800?

Mode 9700 covers Word/Excel binary files (MD5-based KDF). Mode 9800 covers PowerPoint binary files (SHA-1-based KDF). The cipher and 40-bit key length are identical — only the hash function differs.

Can I do this myself with open-source tools?

Authorized technical users can inspect the format with tools such as Hashcat, John the Ripper, or office2john. Time, electricity, file integrity, and result verification remain the practical constraints.

What if the file is partially corrupted?

The OLE2 container needs to be parseable for any recovery to apply. If the file is structurally corrupted, repair must come first.

Does VBA project password affect this?

VBA project password is separate from document open password — it protects macro source code, not document content. VBA passwords have their own protection layer that's typically much weaker than the document password.

Related references

m9400Modern AES baseline m9500Strengthened KDF m9600Current Office default

Have a file in this category?

Start with a free analysis. The encryption type is detected in your browser, then a free check runs through fast techniques before any paid attempt. You only pay if a recovery actually works.

Run a free Office analysis