Office 97-2003 RC4 — Hashcat Modes 9700 / 9800

What Office 97-2003 actually encrypted

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

The encryption itself is RC4 with a 40-bit key by default. Microsoft offered other cipher choices through Crypto API providers — the Base, Strong, and Enhanced Cryptographic Providers — 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 the 40-bit key length are identical — only the hash function in the derivation 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 means 2^40, about 1.1 trillion possible keys. By 2026 hardware standards that entire key space is exhaustively searchable on modern GPU clusters within tractable timeframes. Recovery does not need to guess the password — it can target the cipher key directly.

Once a cipher key is established, the document body can be checked without depending on the original password's 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 begins with the magic bytes D0 CF 11 E0 A1 B1 1A E1.

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

The extracted hash uses the oldoffice prefix followed by a numeric type identifier from 0 to 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 and later — 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 systems standardised on .doc and .xls during the 2000s and 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 or .xls.

When organisations migrate document archives, the original encryption is preserved by default rather than upgraded. 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 versus OOXML

Office 2007 was a complete rewrite of both the file format and the encryption. OOXML files (.docx, .xlsx, .pptx) are ZIP containers with XML inside, encrypted with AES-128 by default and AES-256 in Office 2010 and later.

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

Practical recovery flow

The standard flow for a mode 9700/9800 file: first, drop the file into a browser-based analyzer to confirm the format and version — this happens client-side and the file content never leaves the browser. Second, run the free check against fast attack techniques, which completes quickly and shows whether the password follows a common pattern. Third, for documents the free check does not crack, the cipher-key search runs on GPU clusters with a 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.