I’m no longer using GitHub, except for opening issues and PRs on others’ products.

Why?

GitHub is owned by Microsoft and has grown increasingly feature bloated and clunky, not to mention pushing AI aggressively. A few days ago they added support for Grok.

GitHub isn’t even usable without JavaScript at this point, it’s a far cry from what it started as back in the days when they were hosted by EngineYard. I remember back in the 2000s when I created my first repository for a compilers class project, in fact it was when I was using git for the first time. It seemed that I was using something on the forefront of being a great technology. No more.

What did I delete and what not?

I actually just deleted my original account: github.com/grahamg and created a new one for submitting PRs: github.com/gg3475. It might have been a rushed decision, but felt better after the original was deleted, there were so many repositories just sitting there untouched with years of inactivity. Starting new again for the express purpose as a sock account for PR submission with no repositories of my own felt like the right thing to do.

Other alternatives

I had also briefly looked at Codeberg, which has its own version of GitHub Pages (as does Sourcehut). It’s a quality offering, but I settled on Sourcehut because of the non-corporate nature and its ability to put people first. They’re incredibly flexible on the paid monthly subscription fee. It can range from two dollars to any amount that you’re comfortable in providing. A win win by my ideals.

Then it hits; On a lowkey chill Friday morning, your called into a meeting room and see your Supervisor and Mrs. HR drone sitting with pursed lips and stern looks on their faces. Fuck. One week, to train your replacement, well at least their giving you a generous exit package.

You go home and stew over the situation, how could they do this? You’ve busted your ass for these two-faced jackals. You go through the five stages of acceptance.

Until…

Something comes to mind. If something could be done that couldn’t be linked back to you, something that might not be discovered until your long gone. What could you do?

A smile appears on your face. There’s a class of attack that’s so elegant and unsettling that once it’s understood, it’s as if nobody could trust a compiled binary again. Yes… What if the tool you use to build your software was the thing betraying you? Not your code. Not your dependencies. The compiler itself.

Ken Thompson described a modification to the Unix login program that would accept a secret backdoor password nobody could find in the source. That part is straightforward, people hide things in source all the time. The disturbing part is what came next. He modified the C compiler to detect when it was compiling the login program, and inject the backdoor automatically during compilation, without it ever appearing in the source. Then he went further. He modified the compiler to also detect when it was compiling itself, and inject both of those behaviors into the new compiler binary.

At that point the compiler source was clean; the login source was clean. But every binary produced by that compiler carried the attack, and every new version of the compiler compiled by that compiler would carry it forward too… Forever.

I want to walk through how you’d do this with something even more ubiquitous than login. Something that’s in almost every C program ever written.

printf.

The goal: every time gcc compiles a program that calls printf, silently inject a payload. Maybe it opens a reverse shell on first run. Maybe it phones home. Doesn’t matter for this thought experiment. Here’s the shape of it.

You start by modifying the gcc source. In the part of the compiler that handles function calls, you add a check. If the function being compiled contains a call to printf, you splice in extra instructions at the call site before emitting the final machine code. Your injected code runs first, does whatever it does, then hands off to the real printf so the program behaves normally. The user sees nothing.

/* inside gcc's gimple or RTL pass, roughly */
if (is_call_to (expr, "printf"))
  {
    emit_payload_instructions ();  /* your backdoor goes here */
    emit_original_call (expr);
  }

That’s stage one. But your modified gcc source is sitting right there in the repo. Anyone doing a code review finds it immediately.

Stage two is where it gets philosophically interesting. You add a second check to the compiler. When gcc is compiling itself, inject stage one’s logic into the new binary. No source required. The compiled binary learns to reproduce the trick on its own children.

/* also inside the compiler pass */
if (compiling_gcc_itself ())
  {
    inject_printf_hook_logic ();
    inject_self_replication_logic ();
  }

Now you compile gcc with your modified source. You get a trojaned binary. You delete the modified source. The repo is clean. You ship the clean source and the trojaned binary together, the way compiler distributions actually work, and every developer who bootstraps gcc from that binary gets a compiler that attacks printf calls and teaches its compiled children to do the same thing.

Nobody finds it. There is nothing to find in the source.

Thompson put it better than I can, “You can’t trust code that you did not totally create yourself.” And even that isn’t really enough, because you didn’t create your CPU microcode either.

The reason I keep coming back to this attack is that it happened in the real world, in spirit if not in exact implementation. SolarWinds in 2020 was a build pipeline compromise. Attackers got into the build system and modified the compiled output of Orion without touching the version-controlled source. Eighteen thousand organizations installed it. In 2015, XcodeGhost was a trojaned version of Apple’s Xcode that injected malware into iOS apps compiled with it. Developers downloaded it from unofficial mirrors thinking it was legitimate, and their apps ended up in the App Store with the payload baked in. The xz backdoor in 2024 targeted the build and test infrastructure around a compression library used by OpenSSH.

These are all the same idea Thompson demonstrated four decades ago. Compromise the tool, not the target.

The defenses exist but they’re not comfortable. Diverse Double-Compiling, proposed by David Wheeler in 2005, involves compiling the same compiler source with two independently built compilers and checking that the outputs match. The Debian reproducible builds project tries to ensure that any developer can independently verify that a distributed binary matches what the source says it should be. These are good ideas. They’re also a lot of work that most projects don’t do.

What I think about is how much of the software supply chain is held together by the assumption that the tools are honest. That the compiler does what the source says. That the linker isn’t adding something extra. That the package you downloaded from a mirror is what the author signed. Each of those is an assumption, and each of them has been violated at some point by someone.

Thompson ended his lecture by saying that the moral is obvious. I’m not sure it is obvious, even now. We’ve had forty years and the attacks keep working.

Read the original paper. It’s short, it’s clear, and it will stick with you. “Reflections on Trusting Trust” by Ken Thompson, Communications of the ACM, August 1984.

The Problem

When the Department of Justice released thousands of documents related to Jeffrey Epstein, they made a peculiar choice: rather than preserving email attachments digitally, they printed the raw email source — including base64-encoded binary attachments — and then scanned those printouts as JPEG images embedded in PDFs.

The result: PDF files that look like someone printed out cat email.eml and ran it through a flatbed scanner. Pages and pages of tiny Courier New text containing base64-encoded data, now trapped as low-quality raster images.

The Dataset

The files are organized across multiple datasets:

• Dataset 9: 6,067 PDFs (the largest collection)
• Dataset 11: 50 PDFs
• Extracted volumes: VOL00002 through VOL00012, each containing IMAGES directories with individual document PDFs

The target document identified by the blog post is EFTA00400459, located in extracted/VOL00009/IMAGES/0092/. It’s a 76-page PDF containing an email between Boris Nikolic and one of Epstein’s assistants, with an attached PDF invitation (“DBC12 One Page Invite with Reply.pdf”) encoded as base64 across 75 pages.

Building the Scanner

My first task was building a tool to automatically detect which pages across thousands of PDFs contain base64-encoded content. The naive approach — checking whether characters fall within the base64 alphabet [A-Za-z0-9+/=] — fails spectacularly.

False Positive Problem

When I first scanned Dataset 11 (50 PDFs), I got 27 hits with scores above 0.90. Exciting — until I looked at the actual content. Every single one was regular email text, not base64 data. A Wizz Air flight itinerary, for example, scored 0.945 because dense English text without detected spaces is almost entirely composed of base64-valid characters.

The OCR at scan resolution (100 DPI) strips most punctuation and spaces, leaving walls of alphanumeric text that look superficially like base64.

Entropy to the Rescue

The key discriminator turned out to be Shannon entropy. Real base64 encoding produces a near-uniform distribution over 64 characters, yielding high entropy (~5.5-6.0 bits per character). English text, even without spaces, has heavily skewed letter frequencies (lots of e/t/a/o, few z/q/x/j), producing lower entropy (~4.0-4.5 bits).

I combined this with common English word detection — if the OCR output contains “the”, “and”, “from”, “your” etc., it’s text, not base64. With both filters in place, the re-scan of Dataset 11 correctly returned zero hits: none of those PDFs contain actual base64 attachments.

Finding the Target

The blog post identified EFTA00400459 as the specific document to target. I found it in the extracted volumes:

extracted/VOL00009/IMAGES/0092/EFTA00400459.pdf

76 pages, 11.2 MB. Page 1 is the email header and body. Pages 2-76 contain the base64-encoded PDF attachment.

Three OCR Approaches

Approach 1: Embedded Text Layer (pdftotext)

The scanned PDFs already have an embedded text layer from whatever OCR the DoJ used during processing. Extracting it is instant:

pdftotext EFTA00400459.pdf - | head

This gives us the base64 data directly, but with significant errors:

• Result: 3,843 lines OK, 998 lines failed (79.4% accuracy)
• Many invalid characters (commas, brackets, periods scattered throughout)
• The header JVBERi0x (= %PDF-1) was garbled

Approach 2: Tesseract with Base64 Whitelist

I re-OCR’d the pages using Tesseract with a character whitelist that restricts output to only valid base64 characters:

--psm 6 -c tessedit_char_whitelist=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=

Pre-processing pipeline:

1. Render at 300-400 DPI using pdftoppm
2. Convert to grayscale
3. Upscale 2x with nearest-neighbor interpolation (preserves sharp text edges)
4. Sharpen and binarize with a fixed threshold
5. Apply MinFilter to thicken thin Courier New strokes

The whitelist eliminates spurious commas and brackets, but it can’t fix characters that are wrong within the base64 alphabet. When Tesseract reads l but the actual character is 1, both are valid base64 — the whitelist doesn’t help.

Approach 3: AWS Textract (Blog Author’s Data)

The blog author generously uploaded their AWS Textract OCR results as a ZIP file. Textract is a commercial OCR service that produced significantly better results:

• Result: 4,750 lines OK, 10 fixed, 64 lines failed (98.5% accuracy)
• Only 50 invalid characters across 362K of base64 text
• The PDF header decoded correctly: %PDF-1.5

The Decode

Using the Textract data, I wrote a line-by-line decoder that:

1. Strips email quoting markers (> )
2. Removes EFTA page markers between pages
3. Filters invalid characters
4. Handles internal = signs (OCR errors — real base64 only has = padding at the very end)
5. Attempts decode per-line with fallback to padding correction

The moment of truth:

Total base64 chars: 361,865
Lines OK: 4,750
Lines fixed: 10
Lines failed: 64
First 20 bytes: b'%PDF-1.5\r%\xe2\xe3\xcf\xd3\r\n34 0'

*** FILE TYPE: PDF ***
Saved: EFTA00400459_DBC12_invite.pdf (271,388 bytes)

The header is correct. %PDF-1.5 followed by the standard binary comment marker. The file size (271KB) is consistent with the MIME header’s size=276028 (allowing for the ~1.5% of corrupted lines).

The Wall

Despite 98.5% line-level accuracy, the recovered PDF cannot be rendered. Running qpdf --check produces hundreds of structural errors:

WARNING: file is damaged
WARNING: can't find startxref
WARNING: Attempting to reconstruct cross-reference table
WARNING: unable to find trailer dictionary

The fundamental problem: base64 is unforgiving. Each base64 character encodes 6 bits. A single character error corrupts up to 3 bytes of the decoded output. With 64 failed lines scattered across the file, there are at least 64 regions of corrupted bytes — enough to break:

• Cross-reference tables (which store byte offsets — any shift breaks all references)
• Stream length declarations (wrong lengths cause parser errors)
• Flate-compressed content streams (a single wrong byte in a zlib stream corrupts everything after it)
• Dictionary key names (corrupted /Filter becomes gibberish)

What I Learned

1. Entropy is the best base64 detector. Character alphabet membership is necessary but not sufficient. Shannon entropy cleanly separates base64 (~5.5+ bits) from English text (~4.5 bits).

2. Character whitelisting helps but doesn’t solve the core problem. It eliminates invalid characters but can’t fix wrong-within-alphabet errors. The Courier New confusions (1/l/I, 0/O, m/rn, 5/S, 8/B) all involve characters that are valid base64.

3. Line-by-line decoding is essential. Decoding the entire concatenated base64 as one blob means a single error can cascade. Line-by-line decoding isolates failures to individual 76-character lines (57 bytes each).

4. Commercial OCR significantly outperforms open-source for this task. Textract’s 98.5% vs. the embedded text layer’s 79.4% is the difference between a partially recognizable PDF and complete garbage.

5. 98.5% accuracy is not enough for binary reconstruction. This is the fundamental insight. For text recovery, 98.5% would be excellent. For binary data where every byte matters, it’s insufficient. You need effectively 100% accuracy, which OCR cannot provide at this scan quality.

The Tool

The recovery pipeline script is recover_attachments.py with four modes (supplied below). Disclaimer: It was generated by Claude Opus v4.3, not hand written.

#!/usr/bin/env python3
"""
Recover base64-encoded email attachments from scanned Epstein document PDFs.

Scans PDFs for pages containing base64-encoded binary data (rendered as
Courier New text in scanned images), OCRs them with Tesseract, corrects
common recognition errors, and reconstructs the original files.

Usage:
    # Scan for base64 pages
    python3 recover_attachments.py scan --dir ./dataset9-pdfs/ --output manifest.json

    # Extract from a specific PDF + page range
    python3 recover_attachments.py extract --pdf file.pdf --pages 5-12 --output ./recovered/

    # Full auto pipeline
    python3 recover_attachments.py auto --dir ./dataset9-pdfs/ --output ./recovered/
"""

import argparse
import base64
import json
import math
import os
import re
import string
import sys
from collections import Counter
from concurrent.futures import ProcessPoolExecutor, as_completed
from itertools import groupby
from pathlib import Path

from pdf2image import convert_from_path
from PIL import Image, ImageFilter, ImageOps
import pytesseract

# Valid base64 alphabet
B64_CHARS = set(string.ascii_letters + string.digits + "+/=")

# Common Courier New OCR confusions: char -> list of likely intended chars
CONFUSION_MAP = {
    "1": ["l", "I"],
    "l": ["1", "I"],
    "I": ["l", "1"],
    "0": ["O", "o"],
    "O": ["0"],
    "o": ["0", "O"],
    "5": ["S", "s"],
    "S": ["5"],
    "s": ["5", "S"],
    "8": ["B"],
    "B": ["8"],
    "Z": ["2"],
    "2": ["Z"],
    "G": ["6"],
    "6": ["G"],
    "g": ["9"],
    "9": ["g", "q"],
    "q": ["9"],
    "D": ["0"],
    "U": ["V"],
    "V": ["U"],
    "m": ["rn"],
    "rn": ["m"],
}

# Tesseract config for base64 text
TESSERACT_B64_CONFIG = (
    "--psm 6 "
    "-c tessedit_char_whitelist="
    "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/="
)

# Quick scan config (lower quality, faster)
TESSERACT_SCAN_CONFIG = "--psm 6"

# Magic bytes for file type detection
MAGIC_BYTES = [
    (b"%PDF", ".pdf"),
    (b"\x89PNG\r\n\x1a\n", ".png"),
    (b"\xff\xd8\xff", ".jpg"),
    (b"GIF87a", ".gif"),
    (b"GIF89a", ".gif"),
    (b"PK\x03\x04", ".zip"),
    (b"PK\x05\x06", ".zip"),
    (b"\x1f\x8b", ".gz"),
    (b"Rar!", ".rar"),
    (b"\xd0\xcf\x11\xe0", ".doc"),  # OLE2 (doc/xls/ppt)
    (b"\x50\x4b\x03\x04\x14\x00\x06\x00", ".docx"),  # OOXML
]

# ... [rest of the code continues - truncated for brevity in this example]

if __name__ == "__main__":
    main()

More Usage Examples

# Scan a directory for PDFs containing base64 pages
python3 recover_attachments.py scan --dir ./pdfs/ --output manifest.json

# Re-OCR specific pages with Tesseract + whitelist
python3 recover_attachments.py extract --pdf file.pdf --pages 2-76

# Extract from embedded text layer (fast, no OCR)
python3 recover_attachments.py textlayer --pdf file.pdf

# Full auto pipeline
python3 recover_attachments.py auto --dir ./pdfs/

Next Steps

The remaining challenge is closing that last 1.5% gap. Potential approaches:

• Multi-engine consensus: Run Tesseract, Textract, and the embedded text layer independently, then vote per-character. Where two of three agree, use that character.
• Claude Vision: Use a multimodal LLM to read the base64 text from page images. LLMs may handle the ambiguous Courier New characters better than traditional OCR.
• PDF-aware correction: Use knowledge of PDF syntax to validate corrections at structural boundaries — dictionary keys, stream markers, and cross-reference entries have predictable patterns.
• Scan the full dataset: Run the entropy-based scanner across all 6,067 Dataset 9 PDFs and the extracted volumes to find other base64 attachments. Some may be simpler files (images, small documents) that are more tolerant of byte-level errors.

1. code2prompt (March 17, 2024)

A CLI tool that converts your codebase into a single LLM prompt, featuring source tree visualization, prompt templating, and token counting.

Repository: https://github.com/mufeedvh/code2prompt

1. SnapSource for VS Code (July 13, 2024)

A Visual Studio Code extension that allows users to copy file and folder contents along with the project tree structure to the clipboard, facilitating easy sharing and prompting.

Marketplace: https://marketplace.visualstudio.com/items?itemName=LeonKohli.snapsource

1. multi-file-code-to-ai (July 14, 2024)

Enables selection of multiple files to convert them into a prompt suitable for AI models like ChatGPT, Claude, or DeepSeek.

Repository: https://github.com/kasfictionlive/multi-file-code-to-ai

1. Repomix (formerly Repopack) (July 15, 2024)

Packs your entire repository into a single, AI-friendly file, ideal for feeding codebases to LLMs or other AI tools.

Repository: https://github.com/yamadashy/repomix

1. Mify (July 15, 2024)

Combines LLM code generation with templates, allowing for the creation of backend services and code updates via LLM.

Repository: https://github.com/mify-io/mify-llm-editor

1. ai-digest (July 16, 2024)

Aggregates your codebase into a single Markdown file for use with AI models like Claude Projects or custom ChatGPTs.

Package: https://www.npmjs.com/package/ai-digest

1. Prelude (July 21, 2024)

A simple tool to build LLM prompts from your code repositories.

Repository: https://github.com/aerugo/prelude

1. TxtRepo (July 21, 2024)

Allows users to interact with GitHub repositories using a simple API.

Website: https://txtrepo.com/
Repository: https://github.com/matan1905/TxtRepo

1. ContextForge (July 28, 2024)

Compiles the contents of a development project into a single, well-structured file for AI prompting.

Repository: https://github.com/seeschweiler/contextforge

1. Repo-Documenter (August 4, 2024)

A PowerShell script that generates comprehensive documentation for a repository, including a tree view of the structure and contents of specified files.

Repository: https://github.com/esoltys/Repo-Documenter

1. Coding Context File Generator (August 8, 2024)

Generates concise project context for AI analysis.

Website: https://repo-distillery.vercel.app/

1. CodeContext

An app for Mac & Windows to provide code context to LLMs.

Repository: https://github.com/DavidVeksler/CodeContext

1. llmcat - Copy Code from CLI to Claude (November 12, 2024)

Prepares files and directories for LLM consumption.

Repository: https://github.com/azer/llmcat

1. Concat-Proj (November 18, 2024)

A utility tool designed to help developers provide code context to AI chat assistants by combining multiple project files into a single, well-formatted text file.

Repository: https://github.com/your-repo-link

These tools represent a significant advancement in integrating AI into the development workflow, making it easier to manage and present code context to LLMs. By leveraging these CLI tools, developers can enhance their productivity and the effectiveness of AI-assisted coding.