How Unrar Extracts RAR Files Using Store Method

The "Store" method in the RAR format packages files without applying any data compression algorithms, packaging the data in its raw byte form. When extracting these files, the unrar utility identifies the storage method from the file header, bypasses the resource-heavy decompression engine, directly streams the file contents from the archive to the output destination, and verifies data integrity via checksums. This article explains the technical workflow unrar follows when reading, verifying, and writing archives created with the Store method.

1. Header Parsing and Method Detection

Every item in a RAR archive begins with a file block header (FILE_HEAD). When unrar scans the archive structure, it parses the metadata fields within this header:

  • Method Flag: unrar inspects the compression method byte. In the RAR specification, the value 0x30 (decimal 48) indicates the Store method, meaning compression was disabled (-m0).
  • Sizes: It reads the PackSize (compressed size) and UnpSize (uncompressed size). For non-encrypted Store archives, these two values are identical.
  • Checksum: It extracts the expected checksum—either a 32-bit CRC (RAR4 and RAR5) or a 256-bit BLAKE2sp hash (RAR5)—for subsequent validation.

2. Bypassing the Decompression Engine

For standard compressed archives, unrar allocates decompression buffers and initializes decoding routines such as LZSS (Lempel-Ziv-Storer-Szymanski), Huffman tables, or PPMd (Prediction by Partial Matching).

When the Store method is detected, unrar completely bypasses these decoding engines:

  • No sliding dictionary is allocated or maintained in memory.
  • Symbol trees and bit-reading abstractions are skipped.
  • Execution routes directly to a raw extraction subroutine (historically handled via Unpack::Unstore in the UnRAR source code).

3. Decryption (When Applicable)

If the archive is password-protected, the Store method does not leave the file contents in plain text. Even though algorithmic compression is disabled, encryption is applied to the payload:

  • For RAR 4.x archives, unrar initializes an AES-128 decryption cipher.
  • For RAR 5.x archives, unrar initializes an AES-256 decryption cipher.

During extraction, unrar reads the encrypted raw blocks into memory, applies the decryption key, and produces the plaintext data stream before writing to the target filesystem.

4. Direct Streaming and I/O Execution

Without the need to decode complex bit patterns, unrar treats the operation essentially as a buffered stream copy:

  1. Chunk Reading: unrar reads data sequentially from the archive stream in chunks (typically using a buffer sized between 64 KB and several megabytes, depending on the implementation).
  2. Writing to Disk: The buffer is immediately dispatched to the target file descriptor using standard system write operations.
  3. Multi-Volume Spanning: If the stored file spans multiple RAR volumes, unrar reads up to the volume boundary, prompts for or locates the next archive volume, verifies the continued header, and seamlessly resumes reading raw bytes into the output file.

5. Integrity Verification

As bytes pass through the memory buffer to the destination file, unrar runs them through an inline checksum calculator. Once the number of processed bytes reaches the declared file size, unrar finalizes the computed hash and compares it against the value stored in the header:

  • If the calculated CRC32 or BLAKE2sp matches the header value, the file attributes (such as timestamps, file permissions, and extended attributes) are applied to the written file, and the file descriptor is closed.
  • If a mismatch occurs, unrar raises a checksum error alert, indicating that corruption occurred in the container or during transfer, and handles the output file according to user-specified flags (such as deleting broken files or retaining them via -kb).