Amber64 - Mining Hacker History from Over 500k Commodore 64 Disks

Amber64: Mining Hacker History from Over Half a Million Commodore 64 Disks

Speakers: Wesley McGrew Conference: DEF CON 33 YouTube: https://www.youtube.com/watch?v=PqPMyhA4NSI Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Wesley%20McGrew%20-%20Amber64%20Mining%20Hacker%20History%20from%20Over%20Half%20a%20Million%20Commodore%2064%20Disks.pdf

Overview

Forty years ago, teenagers with Commodore 64 computers were dialing into bulletin board systems with stolen calling card codes, trading pirated software with groups operating across international borders, and laying the cultural and technical foundations for what would eventually become the modern security research community. Almost none of them thought to archive what they were doing. Almost none of them needed to — the floppy disks they used every day preserved it all without anyone asking them to.

At DEF CON 33, Dr. Wesley McGrew presented Amber64, a project he describes as digital forensics applied to hacker history at scale. Over the course of several years, McGrew collected over 650,000 unique Commodore 64 floppy disk images from publicly accessible online archives, built a custom processing pipeline to extract every recoverable string from every sector of every image, indexed the entire corpus into Elasticsearch for full-text search, and proceeded to find things that have been sitting undiscovered in unallocated sectors since the Reagan administration.

The talk is part technical deep dive on C64 disk forensics, part historical survey of 1980s hacker culture, and part demonstration that the methodology of digital forensics — normally applied to incident response and criminal investigation — is equally powerful when aimed at cultural preservation and historical research.

Background

▶ Watch: Hacker history uncovered: early scene artifacts on disks (0:20)

The Commodore 64 and Its Cultural Context

The Commodore 64, introduced in August 1982 and manufactured until April 1994, holds the Guinness World Record for the highest-selling single computer model of all time. Conservative estimates put production at 12 to 17 million units — founder Jack Tramiel's claimed 30 million is generally considered promotional exaggeration, but even the conservative number easily secures the record. The production run of twelve years is extraordinary; no other 8-bit personal computer model came close.

The C64 arrived at a specific cultural moment. Personal computers were expensive. Internet access did not exist for consumers. Bulletin Board Systems (BBSs), reached via modem over telephone lines, were the primary mechanism for online community. Long-distance calls to BBSs in other cities or countries were expensive — which created immediate motivation for phone phreaking, the practice of manipulating telephone networks to make calls for free.

The C64 was uniquely suited to this milieu. Its SID (Sound Interface Device) chip was a genuine analog synthesizer with digital control — capable of generating the DTMF tones and multi-frequency tones needed for telephone network manipulation. Its 64KB of RAM, 1 MHz MOS 6510 processor, and Commodore 1541 floppy drive (itself a separate computer, running a 6502 at 1 MHz with 2KB RAM) made it powerful enough to run meaningful software. And the software piracy scene, which cracked copy protection and distributed games via BBS networks, created a distribution infrastructure that simultaneously transmitted hacker text files, phreaking tools, and community communications alongside the games themselves.

McGrew frames this period as the first decade of hacker culture — the time when the norms, techniques, and social structures of the hacking community were established, before the internet, before the Computer Fraud and Abuse Act was meaningfully enforced, before the movement had to confront consequences at scale.

Why Floppy Disks Preserve More Than You Think

Disk forensics is built on the principle that storage media retains data long after users believe it has been deleted. On Commodore DOS — the file system used by the 1541 drive — deleting a file does not erase its contents. It marks the file's directory entry as deleted and returns its sectors to the Block Availability Map (BAM, the C64 equivalent of a FAT table) as available for reuse. The actual data remains in those sectors until a subsequent write physically overwrites them.

Users of the 1980s routinely reused disks. A disk might start its life holding a cracked game, get "formatted" or have files deleted, be used for a text file collection, have those deleted, and end up holding a BBS session log. Each layer of data has some probability of surviving in unallocated sectors, in file slack space, or in orphaned sector chains that the directory no longer references but that still contain intact data.

Beyond deleted files, the 1541's sector structure creates additional forensic surface area:

• Slack space: The last sector of any file is only partially filled. The remaining bytes in that sector contain whatever was previously written there — which could be bytes from a previous file.
• Orphaned chains: Sector chains that exist in the disk's allocation but are not referenced by any directory entry. These may be fragments of deleted files, copies, or artifacts of copy protection schemes.
• The full disk image: Sectors that fall outside any chain — unallocated space — may contain arbitrary previous content.

McGrew notes that C64 disk forensics is complicated by several factors that make naive approaches like running strings on disk images fail in the general case: variable sector counts per track (21 down to 17 sectors across four track zones), sector chaining via the first two bytes of each 256-byte sector, multiple character encodings (PETSCII uppercase, PETSCII lowercase, screen codes, ASCII, and purely numeric schemes), and active adversarial interference from copy protection schemes that wrote intentionally malformed data.

Key Findings

▶ Watch: Software cracking culture of the 1980s revealed through disk content (2:05)

The Corpus

McGrew assembled disk images from the following sources:

• TOSEC (The Old School Emulation Center): A curated, labeled archive of known software titles
• C64 Preservation Project: Dedicated disk preservation effort with byte-for-bit accuracy including copy protection data
• Internet Archive: Public domain and user-contributed collections
• CSDB (Commodore Scene Database): Demo scene archive
• FTP sites: Zimmers, Arnold, Padua and others with decades-long running histories
• Loadstar Magazine: Approximately 250–260 issues of the disk-based Commodore magazine, each comprising four sides of floppy content
• Private collections: Materials from former software piracy groups and copy protection crackers

The corpus, after deduplication by SHA-256 hash (meaning a single bit difference counts as a distinct disk), contained over 650,000 unique images totaling approximately 70 GB. The Elasticsearch index of all extracted text strings across all images is approximately 30 GB.

Importantly, McGrew is not publicly releasing the full disk set (it remains available to researchers on request), but plans to make the text index available on the Internet Archive and publish the processing code on mcgrewsecurity.com.

Historical Materials Recovered

BBS session logs: Direct recordings of users dialing into bulletin boards. These contain real conversations, file transfer logs, and community interactions — the equivalent of Discord chat logs from a community that believed no one was recording.

Phone phreaking materials: War dialers that scanned ranges of phone numbers looking for modem carriers. Lists of BBS telephone numbers. Calling card codes (stolen). Wiring diagrams for tap modifications to telephone handsets. Software that used the SID chip's tone synthesis to generate blue box tones and other switching network signals.

Hacker text files: The .txt and INFO files that circulated alongside pirated software — manifestos, how-to guides, technical discussions, and community news that formed the intellectual substrate of the early hacker scene. Publications like early issues of Phrack have long been known, but individual files from individual users, stored on individual disks, represent a much finer-grained record.

Personally identifiable information: Real names, real phone numbers, real handles tied to real people — and, in at least one case reconstructed from disk evidence, a detailed account of an arrest. A user known as "Wizard" was described in recovered text as having been carded into contacting an undercover officer going by the handle "Countess," leading to a $4,500 bond.

Lost software: McGrew's collaborator, a researcher working on the history of early video games, found a text-based sex quiz game for parties that does not appear in any known software catalog. He also found a title called "Asteroid Miner" — a complete text adventure not present in the TOSEC database.

Developer ephemera: Hidden comments from developers, multiple versions of the same software (some undocumented), and what McGrew calls "cutting room floor" content — material that was removed from released software but survived in unallocated sectors of the development disk.

An advertisement for 2600 Magazine embedded in the unallocated sectors of a railroad signals game disk — at Track 26, Sector 0, which McGrew describes as "a beautiful coincidence."

Technical Deep Dive

▶ Watch: The C64 disk archive: sources and preservation efforts (6:54)

Forensic Processing Pipeline

The processing workflow for each disk image follows these steps:

1. Normalize the image format: Most images are in D64 format, the standard byte-for-byte representation of a 1541 disk. G64 and NIB formats (which capture raw track data including copy protection timing marks) are converted to D64 first.

1. Parse all sector chains: Walk all referenced sector chains starting from the directory (Track 18, Sector 0 on standard disks). Extract allocated files, deleted files (where directory entries survive but BAM marks sectors as free), orphaned chains, and entirely unallocated sectors.

1. Extract strings from every source: Run string extraction across all identified chains, directory structures, slack space, and the raw disk image byte stream. Because C64 character encoding is not ASCII, the pipeline generates candidate strings under every possible encoding scheme — PETSCII uppercase, PETSCII lowercase, screen codes, ASCII, and numeric encoding. This produces significantly more than 170 KB of candidate string data per disk image.

1. Generate a JSON record: One JSON document per disk, containing the image name, SHA-256 hash, disk name, file list, and all extracted string candidates.

1. Index into Elasticsearch: The full corpus is indexed with O(1) lookup time, enabling searches across 650,000 disk images in seconds. The index allows queries by content, disk name, SHA-256 hash, or cross-reference between files with matching content hashes.

The Disk Format in Detail

The 1541 drive stores data on 35 concentric tracks (with 40-track variants existing). Sectors per track vary by zone:

• Outer tracks: 21 sectors
• Inner tracks: as few as 17 sectors

Each sector is 256 bytes of data, preceded by header and sync marks on the physical medium. Files are stored as linked sector chains — the first two bytes of each sector point to the track and sector number of the next sector in the chain. The linking is deliberately non-sequential (typically skipping 4–5 sectors) to optimize rotational latency during loading.

The directory is on Track 18, Sector 0. The Block Availability Map (BAM) lives on the same track and records which sectors are allocated. Deleted files retain their directory entries (marked with a "deleted" type byte) and their original sector chains — the BAM marks those sectors free, but the data is intact until overwritten.

PRG (program) files begin with a two-byte load address, establishing where in C64 memory the file should be placed at execution time. SEQ (sequential) files are byte streams. REL (relative) files use two interleaved chains — one for data and one for record pointers — functionally similar to resource forks or NTFS alternate data streams.

Encoding Complexity

The character encoding problem is severe enough that McGrew's pipeline generates all possible interpretations rather than attempting to heuristically detect the encoding in use:

• PETSCII unshifted: Uppercase letters and graphic characters; used in programs and early text
• PETSCII shifted: Uppercase and lowercase letters; used in later text-based applications
• Screen codes: A separate encoding for the C64's video memory, with different character orderings
• ASCII: Used by some terminal and communication software, particularly for BBS interactions
• Numeric (A=1, B=2): A less common scheme found in some communication contexts

Without trying all encodings, a significant fraction of recoverable text would be misidentified as binary garbage.

Demo / PoC

▶ Watch: Metadata mining methodology and tools developed (9:32)

The demo component of Amber64 is the Elasticsearch interface itself — the ability to type a search query and retrieve results from 650,000 disk images in under a second. McGrew demonstrated searches for specific handles, phone number patterns, BBS names, and technical terms, showing the retrieved text alongside the disk image name and sector provenance.

The "2600 at Track 26, Sector 0" finding is a particularly elegant example: a full text advertisement for 2600: The Hacker Quarterly, embedded in unallocated sectors of a disk containing a railroad simulation game. The text was written there by a previous owner and survived through at least one reuse cycle.

Defensive Implications

▶ Watch: Surprising findings: previously unknown groups and software (16:14)

Amber64 is not primarily a defensive security talk — it is a historical and forensic research project. The defensive (and offensive) lessons it offers are more cultural than technical:

• Storage media retains data aggressively: The same principles that allowed McGrew to recover 40-year-old BBS logs from a 1541 floppy apply directly to modern SSDs, USB drives, and cloud storage. Users who believe deleted files are gone are wrong; the degree to which they are wrong varies by media type and subsequent write activity, but the principle is consistent.
• Metadata is data: The disk name, directory structure, sector allocation pattern, and load addresses of programs are all forensically significant, not just the file contents.
• Character encoding matters for forensic tools: Modern digital forensics tools often assume ASCII or UTF-8; historical and embedded systems may use proprietary encodings that defeat standard string extraction.
• Anonymity was not a solved problem then, and the lessons apply now: The individuals whose names, phone numbers, and activities appear in recovered disk content had no expectation that their casual files would be readable by strangers four decades later. Users of modern systems who delete sensitive files without secure erasure face the same risk.

Key Takeaways

1. Over 650,000 unique Commodore 64 disk images, totaling ~70 GB, contain recoverable data in unallocated sectors, slack space, and deleted file chains that documents the first decade of hacker culture in granular detail.
2. Standard digital forensics techniques — sector chain parsing, slack extraction, deleted file recovery — apply directly to 40-year-old floppy disk formats.
3. The Commodore DOS file system's BAM-based allocation model means deleted files' data survives intact until overwritten, and reused disks preserve layered history.
4. Character encoding diversity on C64 media requires exhaustive multi-encoding string extraction to recover all readable text.
5. Elasticsearch indexing enables O(1) search across the entire corpus, transforming a 70 GB binary blob into a searchable historical archive.
6. Recovered materials include BBS logs, phreaking tools, calling card codes, arrest accounts, PII, and previously unknown software titles — primary sources for understanding early hacker culture.
7. The methodology generalizes: other 8-bit platform archives (Amiga, early PC, even commercial software installation disks) likely contain similar forensic artifacts.

About the Speaker

Dr. Wesley McGrew is a Senior Cybersecurity Fellow at MartinFederal Consulting, where he works in offense-oriented cyber operations. He holds a PhD in Computer Science from Mississippi State University, where his dissertation focused on vulnerability analysis of SCADA HMI (Human-Machine Interface) systems — research that led to multiple DEF CON talks on industrial control system security in the early 2010s.

McGrew has been presenting at DEF CON since at least DEF CON 19 (2011), where he spoke alongside a Black Hat USA appearance on covert post-exploitation forensics using Metasploit. His subsequent talks have covered point-of-sale malware instrumentation (DEF CON 22), attacker-implanted network device analysis (DEF CON 21), and a reverse engineering workshop that he has run at multiple DEF CON events. He previously held positions as an Assistant Research Professor and Associate Researcher at Mississippi State University, where he taught courses in software reverse engineering and developed curriculum for MSU's NSA Center of Academic Excellence in Cyber Operations designation.

His personal and professional work is published at mcgrewsecurity.com. He is also known in the DEF CON community as "Dr. McGrew" in his role as a DJ at conference nighttime events. Amber64 represents a deliberate turn toward historical and cultural research, motivated by McGrew's personal connection to the era and his conviction that these artifacts deserve preservation and scholarly attention.