archives

Overview

Archives bundle many files into one and usually compress them. In CTF forensics you constantly meet archives — sometimes disguised, sometimes nested many layers deep, sometimes weaponized. Understanding how ZIP, TAR, and GZIP work, and knowing the two classic archive hazards — the zip slip path-traversal trick and the zip bomb decompression attack — lets you extract them safely and recognize when an archive is a trap rather than a treasure.

Learning objectives

• Describe the common archive formats and how bundling differs from compression.
• Identify an archive by its magic bytes even when it is disguised.
• Explain the zip slip (path traversal) and zip bomb (decompression) hazards.
• Extract archives safely without letting them write outside your target directory or exhaust resources.

Core concept

An archive is a container that stores one or more files (with their names and directory paths) as a single file. Compression shrinks data by removing redundancy. Some formats do both; some separate the jobs:

• ZIP bundles and compresses, and stores each file's path. Signature 50 4B 03 04 (PK).
• GZIP compresses a single stream only. Signature 1F 8B. It does not bundle multiple files by itself.
• TAR bundles multiple files but does not compress, which is why you often see .tar.gz (TAR bundle then GZIP compressed). TAR is identified by the ASCII string ustar located at offset 257, not at the very start.

Because archives preserve internal paths and expand data, two properties become security-relevant: where extracted files land, and how large they become.

How it works

Zip slip (path traversal on extraction). An archive entry stores a path. A malicious archive can contain an entry named with traversal sequences such as ../../../../etc/passwd or an absolute path. A naive extractor that joins the entry name to the output directory without validation will write the file outside that directory — potentially overwriting system files. The fix is to canonicalize each destination path and confirm it stays inside the intended extraction root before writing.

Zip bomb (decompression bomb). Compression ratios can be enormous. A tiny archive can expand to a huge amount of data — the well-known illustrative case is a roughly 42 KB ZIP that decompresses to petabytes through nested layers. Extracting it blindly can fill the disk or exhaust memory, causing a denial of service. Defenses limit the extracted size, the number of entries, and the nesting depth, and stop extraction when a threshold is exceeded.

Nested and disguised archives. CTF challenges love to rename an archive (e.g. flag.png that is really a ZIP) or nest archives many levels deep (a ZIP inside a GZIP inside a TAR). Reading magic bytes tells you the true format at each layer.

Practical example

You receive data.bin in an authorized challenge. Its header reveals the truth:

$ file data.bin
data.bin: gzip compressed data

$ xxd data.bin | head -n 1
00000000: 1f8b 0800 ...   ..

The 1F 8B signature confirms GZIP. You list an inner TAR before extracting, and extract into an isolated empty directory:

$ mkdir extract && tar -tzf data.bin        # list contents first, do not extract yet
$ tar -xzf data.bin -C extract              # extract into a dedicated folder

Listing first (-t) lets you spot suspicious entry names like ../../evil (zip slip) or an implausibly large uncompressed size (possible bomb) before anything is written.

Cybersecurity relevance

Archive handling bugs are real, recurring vulnerabilities. Zip slip has affected many libraries and applications across languages; any service that accepts and unpacks user-supplied archives (upload handlers, backup restorers, package installers) must validate entry paths. Decompression bombs are a classic denial-of-service vector against antivirus scanners, mail gateways, and any automated unpacker. Defensively, code that extracts archives should never trust entry names or sizes: validate the resolved path, cap total output and entry count, and impose timeouts. Recognizing these hazards protects both your own analysis machine and the production systems you build.

Common mistakes

• Extracting into your current working directory, letting archive contents scatter or overwrite files.
• Trusting entry names, enabling zip slip to write outside the target folder.
• Blindly decompressing without size limits, exposing you to a zip bomb.
• Assuming the extension is honest — read magic bytes, since archives are often disguised or nested.

Key takeaways

• ZIP bundles and compresses (50 4B 03 04); GZIP compresses one stream (1F 8B); TAR bundles without compressing (ustar at offset 257), hence .tar.gz.
• Zip slip abuses stored paths (../) to write files outside the extraction directory; validate each resolved path against the intended root.
• Zip bombs expand a tiny archive into enormous data; limit output size, entry count, and nesting to prevent resource exhaustion.
• Always list an archive's contents first and extract into a dedicated, isolated directory; identify disguised or nested archives by their magic bytes.

Check your understanding

• What is a zip slip attack, and what check during extraction prevents it?
• Why should you list an archive's contents and extract into a dedicated empty directory rather than unpacking it in place?