Where does the Pyramid of Pain mislead you about a crew that signs every build with one stolen key?

## The assumption hiding at the bottom of the pyramid The Pyramid of Pain calls hash values *trivial* and addresses *easy* on one unstated assumption: that these are **by-products of a process the crew already runs**. A hash falls out of a build. An address falls out of renting a host. Because the crew owns the process, the marginal cost of another output from it rounds to zero. Everything the pyramid says about its lower rungs depends on that, and the interesting crews are the ones for whom it is false - in both directions. ## Crew one: the signed build This crew delivers to a laptop fleet, and every build they ship is signed with a single code-signing certificate obtained from a real vendor - stolen, or bought through a fraudulent company. Look at what a set of their builds shows: different filenames, different hashes, and the same certificate thumbprint every time. By data type, that thumbprint looks like a bottom-rung value. It is a fixed string sitting next to the file, exactly like a hash. By **replacement cost** it behaves like something above the tool rung: - There is no automation that produces one. The crew cannot rebuild their way to another key; they have to compromise another vendor, or run another fraudulent purchase through an issuer that has just become more careful. - The key buys them something no infrastructure can: **the trust that a signature carries on a managed laptop fleet**, where unsigned or self-signed code faces friction that signed code does not. - Burning it is not local. Once the key is known, it can be revoked, and whether builds signed earlier survive that depends on how the revocation is issued and whether the build was timestamped - which is precisely a thing the crew cannot control or count on. Their safest assumption is that everything shipped under it becomes a liability. So for this crew the pyramid's ordering inverts at the bottom: the cheapest-looking value they possess is the dearest thing they hold, worth more than every domain they own put together. ## Crew two: the per-target build The second crew works the same fleet differently. Their tooling compiles a fresh binary for each targeted laptop - unique padding, unique configuration, sometimes a unique layout. The result is that **no two machines see the same hash, ever**. Here the pyramid is not inverted so much as collapsed. The bottom rung does not cost them minutes; it costs them nothing at all, because the cost was **pre-paid once**, in the engineering that made per-target builds automatic. Every marginal hash is free forever after. Removing a hash from play takes away something that was never an asset, and imposes no delay whatsoever. Notice that the two crews are opposite errors of the same kind. One has a bottom-rung value worth more than the model's top; the other has a bottom rung worth nothing at all. Both come from the same source. ## The principle **Replacement cost is a property of the crew's supply chain, not of the value's data type.** The pyramid orders data types because that is what a diagram can do, and the ordering is a reasonable default for a median crew - most crews do rebuild for free, do rent addresses cheaply, do find a new tool expensive. But the question the model is really asking is *what can this crew regenerate, and what must they acquire?*, and only the second question has an answer specific enough to act on. A practical way to price any value is three questions: 1. **Does an existing process of theirs emit it?** If yes, it is free regardless of which rung it appears on. 2. **Must they buy or steal it from a third party?** If yes, it is dear regardless of how cheap the rung looks, because the price includes finding a willing or careless third party. 3. **What else stops working when it goes?** A hash going stale stops one build. A signing key going stale stops a delivery approach. ## Answering this in an interview The wrong answer, and it is the one competent seniors give, is *hashes are the cheapest rung and TTPs the dearest, always*. It is true of the median crew and false of both crews above. The answer that scores states the ordering, states the assumption it rests on, and then produces one crew for whom the assumption fails - ideally in each direction. Saying the model is wrong is not the point either: it is a default with no data behind it, and treating a default as a law is the actual mistake.