Cracking the Jane Street Reverse Engineering Puzzle

Originally posted on jestoph’s tech blog Date: September 4, 2026 | Author: Jestoph Theme: Why do I insist on taking the most difficult path possible?

Jane Street occasionally releases technical challenges. This particular one "nerd-sniped" me, dragging me into a month-long obsession from which I am only now escaping. This post serves as a high-level summary of my journey—a path paved with stubbornness and a severe lack of sleep.

Note: This will get technical. I may write follow-up posts detailing specific steps if there is enough interest.

For context, I suggest reading the original prompt: Can you reverse Engineer an ASIC? (hypothetical link). If you enjoy reading functional terrible code, my repository is available at github.com/jestoph/Challenge-Accepted.

---

🛠️ The Fundamentals: What is an ASIC?

Since my engineering degree is currently gathering dust in the back of my mind, I can explain the basics. An ASIC (Application-Specific Integrated-Circuit) is essentially a custom-designed computer chip.

Companies like Jane Street build these to achieve performance benchmarks that off-the-shelf hardware simply cannot match. The objective of this challenge is to analyze a GDS file (the blueprint of the chip), reverse-engineer its logic, and presumably uncover a hidden password.

Challenge Structure

The puzzle is split into two distinct phases:

1. The Warmup: A guided introduction where you are provided with significant hints, including the chip's design.
2. The Main Event: A "good luck" and a handshake, leaving you to face the void (and insomnia) for the next three weeks.

---

🔍 Phase 1: Initial Reconnaissance

True to form, I ignored all research and dove straight into the files. I noticed several familiar labels:

I also spotted elements prefixed with sky130_fd_sc_hd__, followed by logic descriptors like or and not. To handle these files, I utilized the gdstk Python library.

# Checking the number of cells in the warmup GDS file
import gdstk
cells = gdstk.read_gds("warmup/04_final.gds").cells
print(len(cells)) # Output: 27

I also discovered a .vcd (Value Change Dump) file. This text file appeared to be simulation data. After spotting some ASCII-like patterns, I wrote a quick C program to decode it:

// what-is-this-thing.c
#include <stdio.h>
int main() {
    // Logic to parse VCD and print characters
    return 0;
}

The result?

T R Y A G A I N T R Y A G A I N

Clearly, I was on the right track. Or so I thought.

---

🌀 Phase 2: The "Hard Way" Detour

Instead of proceeding logically, I decided to build an entire ecosystem of tools from scratch. This was a massive waste of time.

My "Productivity" Checklist:

• SQLite3-driven circuit simulator.
• Custom language for circuit design.
• Validation harness for scripting inputs.
• [x] Custom waveform viewer (Failed).
• [x] Raylib GDS viewer (Failed).

---

💡 Phase 3: The Breakthrough

I finally abandoned my vanity projects and used the GDS Viewer recommended on the Jane Street blog. By staring at the layout intensely, I began annotating inputs and verifying them against the wire coordinates in the files.

Understanding GDS Layers

I realized that GDS files operate like a 3D printer's instructions. They define layers of material at specific depths. Rather than arbitrary $z$-axis coordinates, they use standardized layers: $\text{Layer}_n \rightarrow \text{Material Type} \rightarrow \text{Standard Width}$

I tried to prove my mastery by extracting the Jane Street logo from the top-right corner. Result: I successfully extracted everything except the logo.

The Final Key: SVG and Documentation

I discovered that gdstk could export elements to SVG format, including text labels. This was the "Eureka" moment. I stopped guessing and started reading the official (though labeled "unofficial") documentation: sky130-unofficial.

The docs explained the standard design elements. While and is obviously an AND gate, others were cryptic:

• and $\rightarrow$ Standard AND gate.
• o21bai $\rightarrow$ [Complex logic element described in docs]

By combining the SVG labels with the documentation, I could map the physical geometry to the logical I/O of the circuit.

The Final Strategy: Since the library can check if two elements overlap in 2D space (despite the chip being a 3D structure), I could theoretically reconstruct the "real" circuit. I began with the assumption that... (text ends)