The Temple of Memory: Making Stack Smashing Human

You enter the temple.

Totems glow in strange colors — blue, red, green — each humming softly as if performing a function you do not yet understand. The air smells of dust and ozone. Symbols crawl across the walls in an ancient script — rigid, structured, precise.

You don’t know the language.

But you recognize patterns.

On a wooden table sit two heavy books. Their covers read:

conio

iostream

They are spell books — libraries. Collections of incantations that allow the temple to speak to the outside world. One summons text. One receives whispers. You open a page and realize: this place runs on rituals.

This is not a ruin.

It is a machine.


Along one wall are small wooden boxes.

Each box has a name etched into it.

Some hold numbers.
Some hold a single symbol.
Some hold words.

A small placard reads:

char — holds exactly one symbol.
int — holds a number.
var — a named box.

The rules are strict. Every box has a size. Every symbol occupies space.

Further along the wall, another inscription glows:

Type casting — a spell that forces one symbol to be interpreted as another.

You begin to understand. The temple is built on discipline. Structure. Order.

And trust.


At the center of the chamber sits a round mechanical table. Suspended above it is a metallic head mounted on rails. It glides across the glowing script on the wall, touching one line at a time.

Above the head, near the ceiling, floats a vertical pile of stone blocks.

Below the table is another pile.

When the head encounters a ritual that calls another ritual, it pushes a block upward onto the top pile.

The block is engraved with a simple instruction:

“When you are done, return here.”

When the ritual finishes, the head looks at the topmost block to know where to go next.

It does not reason.

It obeys.

This pile — this tower of promises — is how the temple remembers its path.


At the far end of the chamber stands a massive stone door.

You possess the combination.

But the door does not accept it directly.

Instead, your input must pass through the mechanism.

It is processed. Interpreted. Executed.

You raise your wand and alter the script on the wall. The temple allows changes — but only within the grammar of its language. You cannot scribble chaos. The structure must remain intact.

You can also place glowing markers — breakpoints — that freeze the mechanical head mid-motion. When time halts, you can walk around the chamber and observe:

  • Which boxes were created?
  • What symbols fill them?
  • What blocks were pushed onto the promise tower?
  • What instruction sits on top?

You are not meant to guess.

You are meant to observe.


The First Realization

One inscription reads:

Name (4 symbols maximum)

A small wooden chest sits beneath it.

You whisper four letters.

The chest fills perfectly.

But what happens if you whisper ten?

You try it.

The first four symbols fill the chest.

The fifth symbol has nowhere to go.

It does not vanish.

It spills.

The symbol climbs upward — into the stone blocks above.

You watch, stunned, as the engraving on the topmost block begins to change.

The instruction that once read:

“Return to ritual 12”

Now reads something else.

The mechanical head completes its work.

It looks upward.

It obeys the top block.

And it goes somewhere unexpected.


The temple does not scream.

It does not crash.

It simply follows instructions.

You have altered its path.


What You Just Discovered

The machine trusted you.

It trusted that when it gave you a chest that could hold four symbols, you would not give it ten.

It trusted that boundaries would be respected.

It trusted that boxes would not overflow.

But systems that trust blindly are fragile.

When the extra symbols spilled upward, they overwrote the promise block — the very instruction that tells the machine where to return.

You did not break the temple.

You redirected it.

This is the essence of what programmers call “stack smashing.”

But in the temple, it is not jargon.

It is visible.

Physical.

Inevitable.


Why This Matters

In the real world, most people experience computers as opaque artifacts. They type. The machine responds. The process feels mystical.

But underneath the surface, computers are rigid and obedient.

They move through instructions in sequence.

They remember where to return by storing addresses.

They place data in memory boxes of fixed size.

If those sizes are not respected, data spills into neighboring regions.

If neighboring regions contain control information — like return instructions — then data becomes control.

And control is power.

That is exploitation.


Making It Human

The problem with explaining stack smashing to non-programmers is abstraction.

Terms like:

  • stack frame
  • return address
  • buffer overflow

float in technical air.

They lack gravity.

But everyone understands:

  • A box that can only hold so much.
  • A ladder where the top rung determines the path home.
  • A note that says, “When finished, go back here.”
  • Ink that spills onto something important.

If you want to make memory corruption intuitive, you must translate it into physical consequence.

Not diagrams.

Not assembly code.

Consequences.

In the temple, when the player overfills the chest, they see the overflow climb into the promise tower.

When the head jumps unexpectedly, they feel the redirection.

When a hidden ritual labeled “open_portal” exists elsewhere in the chamber, and they realize they can redirect the head to it, they feel clever — not technical.

They discovered a secret passage.

They exploited blind trust.

They bent obedience to their will.


The First Challenge

The first challenge inside the temple is not to open the door.

It is to realize that the promise tower can be influenced at all.

Players initially assume the tower is sacred.

Immutable.

But after observing carefully — placing breakpoints, watching blocks move, experimenting with longer whispers — they discover something profound:

The tower is just memory.

Memory is just space.

And space can be overwritten.

That moment — the realization that control can be seized not by brute force but by understanding structure — is the heart of security.


What the Temple Teaches

The temple teaches five truths:

  1. Machines do not understand intent. They follow structure.
  2. Boundaries exist, but they are not enforced automatically.
  3. Data and control live closer together than we assume.
  4. Overflow is not chaos — it is geometry.
  5. Exploitation is often obedience misdirected.

When players finally redirect the mechanical head to the hidden “open_portal” ritual, the stone door cracks open.

A bright light spills through.

They step through.

And find themselves not in another chamber, but seated at a desk.

A keyboard beneath their hands.

The temple was never ancient.

It was a metaphor.

The maze was code.

The wand was a compiler.

The mechanical head was the instruction pointer.

And the promise tower was the stack.


Why This Approach Works

If we want broader society to understand software security, we must stop explaining it as syntax and start explaining it as structure.

Security vulnerabilities are rarely mystical.

They are architectural.

They arise when:

  • Trust is assumed.
  • Boundaries are implied, not enforced.
  • Control information is placed beside user input.

The temple makes invisible processes visible.

It turns:

“Overwrite the return address”

into

“Spill ink onto the promise block.”

That is accessible.

That is human.

That is memorable.


The temple door opens not because you guessed the combination.

It opens because you understood the machine better than it understood itself.

And that is what hacking has always been.

Not destruction.

But comprehension — deep enough to redirect obedience.

The temple was never about magic.

It was about memory.

We Built a Circuit Locking Service — and You Can Use It Right Now

If you design chips, work in hardware security, or just find the idea of cryptographically protecting a circuit interesting, this post is for you. We just launched a free web service that lets you lock any combinational circuit using a provably secure technique called Indistinguishable Locking (LCI). You upload a BLIF netlist, and we hand back a locked version that is mathematically guaranteed to be indistinguishable from a random circuit without the secret key.

No setup. No installation. Just upload and lock.


The Problem: Chip Designs Get Stolen

Modern semiconductor supply chains are complicated. A chip designed in one country gets fabricated in another, tested somewhere else, and assembled somewhere else entirely. At each step, there are opportunities for an untrusted party to reverse-engineer the design, overproduce unauthorized copies, or insert malicious modifications.

Logic locking is the field that tries to solve this. The idea is simple in principle: before you hand your design to the fab, you lock it. You add extra circuitry that makes the chip produce wrong outputs unless the correct secret key is loaded into tamper-proof on-chip memory. The fab can build it, but they can’t meaningfully copy it without the key.

The hard part is doing this in a way that’s actually secure. Many locking schemes that looked promising have been broken by algorithmic attacks — most famously the SAT attack, which frames the unlocking problem as a satisfiability query and solves it automatically in hours on many locked circuits.


The Solution: Indistinguishable Locking (LCI)

LCI, introduced at IEEE CSF 2022, takes a different approach. Instead of just adding key-controlled gates, it wraps your entire circuit in a cryptographic construction based on two well-studied primitives:

  • Trivium, a lightweight stream cipher used to generate a keystream
  • A GGM-style PRF tree, which uses that keystream to build a pseudorandom function

The result is a miter circuit: your original circuit XOR’d with this PRF, output by output. The locked circuit is delivered as a BDD (Binary Decision Diagram) representation of this miter.

The security guarantee is formal: under standard cryptographic assumptions, the locked circuit is computationally indistinguishable from any other circuit of the same size. This is a much stronger claim than most locking schemes make. It means that no polynomial-time adversary — including SAT-based attacks — can extract useful information about your design from the locked version.

The secret key is the Trivium seed, generated fresh for every locking job using your hardware’s random number generator. It never leaves your hands.


How to Use the Service

It’s straightforward. Head to https://untheologically-noncholeric-macey.ngrok-free.dev, and you’ll see a simple dashboard.

  1. Drop your BLIF file onto the upload zone (or click to browse)
  2. Click “Lock Circuit” — the job is submitted immediately and runs in the background
  3. Poll the status — the dashboard updates automatically every few seconds
  4. Download your locked circuit as a BDD when the job completes

The service accepts any combinational BLIF netlist. We’ve tested it on standard ISCAS-85 benchmarks as well as real-world designs like an ARINC 429 transmitter interface. The locked circuit is delivered as a BDD of the miter, which compactly encodes the full locked function.

A few practical notes:

  • The locking time scales with circuit complexity — small benchmarks finish in under a minute, larger ones may take several minutes
  • Memory is the main bottleneck for very large circuits; circuits with XOR-heavy structure (like c499) are particularly demanding on BDD construction
  • The service runs rate limiting and a job queue cap to keep things fair for everyone

What’s Under the Hood

The service is built on a FastAPI backend with a SQLite job store, so jobs persist across server restarts. Each locking job runs in its own process, so multiple circuits can be locked in parallel without blocking the server.

The core locking pipeline:

  1. Parse the input BLIF to extract port names and gate count
  2. Run our C++ PRF generator (setup), which instantiates Trivium+GGM with a fresh random key from random_device
  3. Build the miter: stitch PRF and original circuit together with XOR gates on the outputs
  4. Construct the BDD of the miter using our Python BDD engine with constant folding — the key optimization that makes large circuits tractable

The constant folding step is what separates our approach from running ABC directly on the miter. Since the Trivium key is hardcoded at locking time, roughly half the circuit folds to constants before BDD construction even begins. This turns a computation that would take days (or exhaust memory) into one that completes in minutes.


Try It

The service is free and open to researchers, students, and engineers. Point your browser at https://untheologically-noncholeric-macey.ngrok-free.dev and upload a BLIF netlist to get started.

If you want to dig into the theory, the original LCI paper is available at https://doi.org/10.1109/CSF54842.2022.9919691.

We’re actively working on scaling the BDD construction step to handle larger circuits. If you have a circuit that pushes the limits or you hit an issue, we’d love to hear about it.


Black Box Chip is an early-stage hardware security startup building tools for provably secure logic locking. This service is a research demo based on work published at IEEE CSF 2022.

My “Business”

My business?

My business is to create secure digital integrated circuits.

My purpose in life is protecting semiconductor intellectual property and ensuring the security of the global microchip supply chain.

My mission is to secure digital integrated circuits.

My purpose in life is to protect Saudi, Sudanese, and Canadian semiconductor intellectual property and ensure the security of the global microchip supply chain.

Constructive action pertaining to protecting Sudanese semiconductor IP and ensuring the security of the global microchip supply chain.

Protect IP

Publish a

My craft is the design and security of computer hardware.

My interest area is hardware security.

Can we build a custom electronic chip whose structure reveals nothing about its function?

You probably heard the term “PUF”, or “physically unclonable function” before (if not, you should look it up!). A PUF is a physical object that is virtually impossible to clone using state-of-the-art fabrication technology. It exhibits functional characteristics that are very hard to predict, and, by virtue of being unpredictable, are hard to duplicate. (Think of it like a black box that implements a truly random function.) The reason for the unpredictability of a PUF’s behavior is nearly uncontrollable elements in the semiconductor fabrication process. A PUF is an integrated circuit (IC); the fabrication process for ICs involves steps that are very hard to control, and as such result in unpredictable differences even among two ICs created from the same blueprint. PUFs are designed in a way that leverages precisely these unpredictable factors. In contrast to a regular IC whose behavior we wish to completely determine at the time of manufacture, we actually seek unpredictability in the behavior of a PUF. 

How do we leverage such an object to create an “unclonable” chip? Hardware security researchers have been pursuing this question for more than a decade, under the purview of a technique called “logic locking”. The premise is the following: a chip designer can leverage the unpredictability of a PUF to build read-proof – albeit expensive – storage, for a binary value of arbitrary length. (The designer can of course build read-proof storage big enough to hold a description of the entire chip in some form, then have a “circuit executor” read the description from the read-proof memory and run it, but this would not truly be a “custom” IC.) Suppose the designer now transforms the chip description so it’s incomprehensible unless the designer enters a certain value into the read-proof memory. We now have a custom IC that doesn’t reveal its function.

In my latest joint work with researchers at the University of Waterloo, New York University and Google, we describe one such mechanism, in which we leverage two recently discovered cryptographic primitives: puncturable pseudorandom functions and indistinguishability obfuscators. The intuition behind the idea is this: suppose we are able to come up with an efficient way to describe the truth table of a Boolean function, and that we then XOR each entry of the truth table with a random bit. The result will reveal nothing about the function itself. But how do we do this efficiently? It turns out that Xoring a circuit that computes the function with a (puncturable) pseudorandom function and applying an indistinguishability obfuscator to the result does exactly this. Of course, we don’t know yet what the overhead of this construction is, but we can expect it to be huge. It’s definitely an avenue worth exploring however.

If you’re interested in working with me on implementing a custom IC that doesn’t reveal its function, let me know!

Suppose we are able to come up with an algorithm $A$ that outputs 1 with probability 1/2+ when given a locked version of some circuit C_1, but outputs 1 with probability 1/2 only when given a locked version of another circuit C_2. This means if we follow the algorithm in the paper for transforming a locked version of C_1 to a locked version of C_2, then for at least one of the 2^n input combinations, the probability of A outputting 1 when given a locked version of C_{1,2}^(i) is at least \epsilon/2^n greater than the probability of A outputting 1 given a locked version of C_{1,2}(i+1), where i is the index of the input combination and C_{1,2}^(x) denotes a half-transformed circuit as in the proof. But this mean that A can tell with probability at least \epsilon/2^n whether C_{1,2}^(i)’s output at input combination i is that of C_1 or that of C_2. at input combination i, which means it can tell the PRF’s output at i given only the punctured GGM key, which breaks the puncturability property, not the iO property since the iO we’re using is perfectly secure. All we need then is to use the theorem given by that website to transform this into a bound for breaking Trivium as a PRNG.

Smash the Stack

You enter the temple. Around you you see a bunch of totems, with weird colors. It looks like each has a purpose.

There’s writing on the wall, the like of which you’ve never seen before. The language is ancient. You can tell, but you do recognize some symbols.

You see two books on a side table. The cover of one says: conio. The other says iostream. What do these words mean? Two thick, ancient books of spells, you open one

Char will be a set boxes on the side

Var

Type casting is a spell that converts some form of symbol into another

You have the combination to open the lock. The problem is it gets processed somehow by the mechanism. It gets transformed by a process akin to magic. You see it in front of you. You flash that wand and the spell on the walls get transformed into a pattern that sits on the table (a round table with a mechanical head, which of course only touches the text section. There are two regions a stack ob blocks on the roof, and a stack of blocks on the bottom, On return from a function call the mechanical head looks at the top of the stack to find out where to go next on the head). The mechanical devices then goes through these patterns one by one and does some action. You must figure out what these symbols mean, by observing the device’s actions. You must then figure out how to change the spell to get the device to open the door.

Player can add breakpoints to undertand the workings of the code….

You can label code using secret ink that other hackers can’t see. Hackers escape the maze which is the code by finding vulnerabilities and exploiting to open a portal and leave the game world 🙂 and connect with their alter egos, the hacker sitting on a computer.

points of input are marked?

First challenge: figure out that you can in fact cause the head to execute instructions on the stack side.

You can walk around and use your wand to change the writing on the wall. The writing needs to capture the code structure though.

How can I make the experience of smashing the stack accessible to a non-coder?

Second post

I’m thinking of making a game that lets the average person experience what a hacker does. According to Jess xxxx, I should ask myself what is essential to the hacker experience.

What is essential to the hacker experiemce? A computer, for one thing.

What have I learned through experience? What has experience taught me?

Let the story emerge.

HackerGames

Aleph One – Smash the stack – Mobile game: Escape room. How many? 7.

Watch out for the HackerGames by

Intro —

Ba’a Two – Buffer overflow

Ta’ Three –

Crypto Games

So I’ve been thinking of writing a game based on AES. The idea to make codebreaking accessible.

Hacker Games

Hacker Lore

How can I make the experience of a hacker accessible to the general public?

What do hacker do?

They break into computers and steal stuff.

So the computer can be represented as a vault, and the hacker’s job is to get into it, steal something, and come back without being detected.

The computer is likely to have many security measures in place to prevent a potential hacker from gaining access. These security measures can be represented as guards, maybe even monsters with special abilities.

The target will be represented as a sort of treasure point. The hacker I guess can also have a map of the computer telling them where the target is.

What is essential to the experience of a hacker?

A computer, code, hoodies, darkness, electronic light, surreal, fantastic, freedom, corporations, espionage,

Code breaking is also essential. Hackers are human, and they have tools,

How can we incorportae physical agility? Well a hacker needs to be fast at pressing keyboard buttons.

Navigation through the game world => browsing source code.

A vulnerability is equivalent to a weapon. Of course these weapons are hidden in plain sight. And the hacker must exercise their knowledge and recognition skills to identify weapons.

Weapons can be used to open the vault and extract the key. But unfortunately, sometimes using certain weapons to open the vault results in either the vault being destroyed or in a security alarm being raised. This terminates the game.

Social engineering/phising => word puzzles….

First thing I need to do:

Execution mode is a different mode. Player can slow down. rewind, pause, memory content

New types of bugs will provide new weapon types.

First game: smash the stack:

Demo: Aleph1’s tutorial.

Use the source d00d

Pick open source code base.

Build visual structure.

Assets for assembly view.

Goal: Design a game based on “Smashing the stack for fun and profit”

Source code view. Assembly view.

Grep

Have keywords link to standard manuals

“printf” would be modelled as a message being printed.

Show loops in action

Start by designing challenges.

Maybe the dark web can be incorporated as the underground world.