How UnRAR Processes ANSI Archive Comments

This article provides an overview of how the UnRAR utility reads, parses, and renders archive comments containing ANSI escape codes. Archive comments in RAR files often include text-based styling and ANSI art, requiring UnRAR to locate the comment data structure, decompress the stream if necessary, handle character encoding conversions, and sanitize or pass escape sequences to the host console for display.

Archive Comment Storage in the RAR Format

In the RAR archive specification, comments can exist at the archive level or file level. In RAR 4.x and earlier formats, comments were stored in dedicated comment blocks or embedded directly in the main archive header. In the modern RAR 5.0 format, comments are stored as a dedicated service header (CMT).

When UnRAR inspects an archive, it parses the header markers sequentially. If a comment block is detected, UnRAR reads the block flags to determine:

  • Whether the comment data is compressed using RAR's proprietary compression algorithms.
  • The total length of the compressed and uncompressed comment payload.
  • The target character encoding (historically IBM PC Code Page 437 or OEM, and UTF-8 in RAR 5.0).

Decompression and Memory Buffering

If the comment block is compressed, UnRAR invokes its internal decompression routines. In older RAR versions, comment blocks could use dedicated text compression variants. In RAR 5.0, comments are decompressed using the standard LZ/dictionary decompression pipeline.

The decompressed payload is placed into a memory buffer as a raw byte stream. At this stage, any ANSI formatting remains in its raw state, consisting of printable ASCII or extended characters alongside Escape sequences (typically starting with the byte 0x1B or \033 followed by [).

Character Encoding Conversion

ANSI art typically relies on Code Page 437 (DOS OEM) characters for borders, shading blocks, and specialized glyphs. UnRAR manages the discrepancy between the legacy CP437 character set and modern system encodings (such as UTF-8 on Linux or UTF-16 on Windows):

  1. Detection: If the archive is in RAR 5.0 format, the comment is natively encoded in UTF-8. If it is in RAR 4.x or older, UnRAR treats the comment as OEM/CP437 by default.
  2. Translation: UnRAR translates legacy OEM byte values into wide characters or UTF-8 representations using internal conversion tables, ensuring that block characters (e.g., ░, ▒, ▓, █) render correctly rather than appearing as corrupted output.

Processing and Rendering ANSI Escape Sequences

UnRAR itself does not contain an internal ANSI rendering engine. Instead, it relies on the host environment's terminal to interpret the control codes (such as text coloring, bold attributes, and cursor placement):

  • Unix and Linux Terminals: Modern terminal emulators natively process standard ECMA-48 / VT100 ANSI sequences. UnRAR outputs the comment directly to stdout. As the terminal encounters escape sequences (e.g., \033[31m for red text), the terminal emulator handles the visual rendering.
  • Windows Console: Historically, MS-DOS and early Windows consoles required the ANSI.SYS driver to parse escape sequences. In modern Windows 10 and 11 environments, UnRAR relies on the console's native Virtual Terminal Processing (ENABLE_VIRTUAL_TERMINAL_PROCESSING via the Windows Console API). When enabled, Windows interprets ANSI color and styling codes directly from the output stream.

Security Sanitization and Control Code Filtering

Allowing raw terminal escape sequences introduces security risks, such as terminal injection attacks, where malicious archives attempt to rewrite terminal titles, reprogram function keys, or hide malicious commands.

To mitigate this, UnRAR includes filtering mechanisms:

  • Allowlisted Codes: Select Color and Graphic Rendition (SGR) codes (e.g., foreground and background colors, bold, reset) are typically permitted so that ANSI art renders as intended.
  • Stripped Sequences: Dangerous sequences, such as Operating System Command (OSC) strings, device status reports, or arbitrary terminal reconfiguration sequences, are either stripped or neutralised before the text is written to the output stream.
  • Control Character Handling: Destructive characters like backspaces (\b) or arbitrary carriage returns that attempt to overwrite console lines outside the display area are constrained to prevent terminal spoofing.