What does an operator gain and lose by storing a payload as data for an installed interpreter?
answer
- bytes and runner are separated
- nothing at rest is a program
- the runtime is a passenger dependency
- capability capped by the language
- conspicuous by shape, not by hash
basics
~20 sGain: nothing on disk is a program, so hash blocking and executable allowlists have nothing to grab. Loss: it runs only where that interpreter already exists and is permitted, with capability capped by the language.
solid answer
~50 sThe gain is that at rest the body is not a program. There is no image to hash, no signature to check and nothing for an executable allowlist to refuse, and the bytes can sit somewhere nobody treats as executable content - a job entry, a settings row, an environment variable. The code exists only inside a process the environment already runs. The losses are what a good answer names. The payload is **dependent on an interpreter it cannot ship**: remove or constrain that runtime and the chain dies at the point where data must become code, and it is the one thing the operator cannot substitute cheaply. Capability drops to what the language expresses unless a second stage brings compiled bytes back in memory, and the blob must be readable at trigger time, so it sits in a store with an owner and a normal shape - a kilobyte of base64 in a job record is conspicuous by structure alone.
go deeper
Be ready to say what the two halves are: inert data somewhere durable, plus something already installed that turns it into code. Naming the pairing is enough at this level.
Explain both directions of the trade. The interviewer is testing whether you can name the dependency the operator cannot ship - the interpreter - as well as the controls the technique sidesteps.
Demonstrate that you can pick the control class that removes what the technique cannot substitute, and say honestly what it breaks when the application itself is written in that language.
Be prepared to argue the trade at fleet scale: which of the two halves your organisation can actually constrain, what the breakage budget is, and why hash-based controls are the wrong thing to fund against this class.
## The split the technique depends on A data-plus-interpreter payload separates two things that are normally welded together: **the bytes** and **the thing that runs them**. In a conventional payload they are the same artefact - an executable image contains the code and the loader starts it. In this technique the bytes are inert data at rest, and the thing that runs them is a general-purpose runtime that the environment installed on purpose. On a Linux fleet behind a public-facing application, that runtime is rarely optional. The application is written in a language; its runtime is therefore present, permitted, and started constantly. That is the whole opportunity. ## What the operator gains **No program to key off.** Blocking by file hash needs a file with a hash. An executable allowlist needs an executable to refuse. Signature checks need something signed. A base64 string in a settings row satisfies none of those preconditions, so an entire family of controls simply never engages. **A place to live that nobody polices as code.** Configuration stores, job records, environment blocks and profile fragments are all written by legitimate operations. Content there is data by definition, and size and shape constraints on them are usually loose or absent. **Execution inside something already normal.** The runtime that decodes the blob is the same runtime that serves the application. Its presence, its parentage and its network reach are all pre-approved by the environment's own design. **Cheapness.** This costs an operator almost nothing. That is why it is commodity technique, not elite technique. ## What the operator loses, and this is the part interviews probe **A hard dependency it cannot ship.** The payload is now a passenger. If the interpreter is absent, or present but constrained - restricted to a fixed set of scripts, or unable to be invoked by the application's account - the chain breaks at the point where data must become code. The operator cannot bundle a runtime without reintroducing exactly the executable file the technique existed to avoid. **This is the control class that removes what the technique cannot substitute**: constrain which interpreters exist and what may hand work to them. **Capability ceiling.** Whatever the language cannot express, the payload cannot do, unless a second stage brings compiled code back - typically by loading bytes into an anonymous memory object and executing them, which is a different and noisier step with its own requirements. **Readability at trigger time.** The blob must be readable by the account that will run it. That pins the storage location to something the account can reach, and every such location has an owner, a normal size and a normal shape. Long opaque strings in places that normally hold short human-written values are conspicuous by structure alone, even to somebody who never decodes them. **A durable footprint anyway.** The point of the technique is that no executable exists, not that nothing exists. The data record and whatever invokes it are both durable, which means the technique buys evasion of one control family while accepting exposure to another. ## Reading the trade in a real estate A useful way to reason: ask which half of the split is cheaper to remove in your environment. Removing the *data* half is usually hopeless - configuration stores exist because the application needs them. Removing the *interpreter* half is a real project with real breakage, but it is bounded and it kills the entire class rather than one payload. Where the runtime genuinely cannot go because the application is written in it, the remaining lever is constraining who and what may hand it work, and closing the flaw that let the operator write to the store in the first place. ## Where this technique is not the interesting part If the operator has a working, repeatable way in, storing anything at all may be a bad trade for them. A commodity crew mass-exploiting one application flaw gets re-entry for the price of one request. Persistence, in that economics, buys nothing and risks something. Recognising that changes the question from `where did they hide the body` to `is the way in still open`.
- If the application is written in the interpreter's language, can that control class still be used?Not by removal, but by constraint. The runtime has to exist, so the lever moves to what may invoke it and with what input - restricting which accounts and which parent processes can start an interactive or arbitrary-input invocation, and limiting what the application's own account may write into the stores that feed it.
- How does the operator regain capability the scripting language cannot express?By making the script a loader: it pulls or decodes compiled bytes and gets them executed in memory rather than as a file on disk. That restores capability but adds a step with distinct requirements - memory must be made executable, and the second stage has to be delivered every time, since nothing durable holds it.
- Why is the size and shape of the stored blob a weakness for the operator?Because the stores that can hold it are stores with conventions. Settings rows, job records and environment values normally hold short, human-written text. A kilobyte of unbroken base64 is anomalous on structure alone, with no need to decode it, so operators either chunk it, disguise it as a legitimate encoded value, or accept the exposure.
saying these in an interview costs you the question
- Claims the technique has no dependencies at all
- Forgets that the interpreter must already be present and permitted
- Assumes scripting payloads have the same capability as compiled ones
- Says nothing durable exists because there is no executable
- Proposes blocking by file hash as the answer