--- title: "You can hide malware inside a neural network" description: "A neural network can memorize a complete source file and reconstruct it through inference, turning deliberate overfitting into an unconventional packing technique." date: 2025-06-29 category: "technical" tags: ["ai","cybersecurity","lstm","malware"] published: true paywall: false --- Neural-network weights are usually treated as parameters, not storage. In practice, they can be both. A sufficiently overfit model can memorize a file and reproduce it during inference. If that file contains code, the model becomes an unconventional packer: the original byte sequence is absent from the artifact, but the content can still be reconstructed when needed. I built a small prototype to test this idea. It trains an LSTM on one source file until the network reproduces the complete sequence. The generated file is then compared with the original using SHA-256. In the successful run, the hashes matched exactly. ## Hiding data in model parameters is already practical The broader idea is not new. The 2021 EvilModel research embedded malware directly into existing neural-network parameters while preserving most of the model's original utility. In one experiment, researchers placed 36.9 MB of malicious code inside a 178 MB AlexNet model while keeping the loss in classification accuracy below one percentage point. More aggressive tests replaced up to half of selected hidden-layer parameters and retained 93.1% of the original performance. The [paper describes the embedding and evaluation process](https://ar5iv.labs.arxiv.org/html/2107.08590). One resulting model passed 58 VirusTotal engines without detection. That result should not be read as a universal antivirus bypass. It demonstrates a blind spot in signature-based scanning: when a payload is dispersed across numeric parameters, the original byte patterns no longer exist in a form conventional signatures recognize. My experiment takes a different route. Instead of modifying a useful pretrained model, I intentionally train a small model to memorize the payload itself. ## Deliberate overfitting as a packer Overfitting is normally a failure. A model memorizes its training data instead of learning a pattern that generalizes. Here, memorization is the objective. The [lstm-memorizer prototype](https://github.com/piotrmaciejbednarski/lstm-memorizer) works in four stages: 1. Build a character vocabulary with explicit start and end markers. 2. Train the network repeatedly on a single file. 3. Generate the sequence from the start marker. 4. Compare the generated output with the original SHA-256 hash. The checksum is important. Source code that merely looks similar is not enough. A packer must recover every character correctly, including whitespace and punctuation. The experiment only counts as successful when the reconstructed file is byte-for-byte identical. An LSTM is convenient for a small demonstration, but the mechanism is not tied to one architecture. GRUs and decoder-only Transformers can also memorize deterministic sequences. The useful question is not whether a particular architecture can do it, but how much model capacity and inference work are required for a given payload. ## Why the representation is unusual Traditional packers store an encrypted, compressed, or transformed payload and include a routine that reverses the transformation. Static analysis can still look for the packed blob, the unpacking loop, known cryptographic constants, or familiar transitions into newly executable memory. A neural packer replaces part of that path with inference. The stored artifact contains tensors, and the recovery operation looks like normal use of an ML runtime. Until generation finishes, there may be no contiguous copy of the original code to scan. This does not remove every detection opportunity. The output must eventually be materialized. Writing it to disk exposes a file. Loading it directly into memory creates behavioral signals around allocation, permission changes, and execution. The technique changes the early stages of analysis; it does not make the rest of the operating system irrelevant. ## What defenders can inspect A model trained only to reproduce one long sequence has properties that differ from an ordinary generative model. Its output is unusually deterministic, its useful input space may be tiny, and generation may produce code or high-entropy binary-like data rather than natural content. Model scanners could test for these behaviors in addition to inspecting serialization formats. Runtime monitoring can follow what happens to generated buffers. Supply-chain controls can restrict untrusted model files just as they restrict executables and scripts. The serialization layer also matters. Loading an untrusted pickle-based model can execute code before inference begins, which is a separate and much simpler attack. Safe formats such as [safetensors](https://github.com/huggingface/safetensors) reduce that risk, but they do not prove that the numeric contents of a model are benign. ## Accelerators create another inspection boundary Modern systems increasingly run inference on GPUs and NPUs. This creates a visibility problem because endpoint tooling is usually much better at observing CPU instructions and conventional process behavior than accelerator workloads. A neural packer could perform most of its reconstruction through DirectML, Core ML, CUDA, or another hardware-backed runtime. To the operating system, the early activity may resemble an ordinary model benchmark. A sandbox without compatible acceleration may take a different path or fail to reproduce the behavior at all. This is a research direction, not evidence that accelerator-backed malware is automatically invisible. The generated payload still has to affect the host somehow. The interesting gap is the path between model loading and that final behavior, where existing analysis tools may have limited context. ## What the experiment establishes The prototype is not a complete malware loader and does not execute malicious code. It establishes a narrower point: exact program content can be encoded through deliberate memorization and recovered through standard inference. That is enough to challenge a common assumption. A model file is not necessarily passive data, and scanning only its raw bytes does not reveal everything it may produce. The practical threat depends on delivery, capacity, runtime behavior, and whether reconstruction is cheaper than conventional packing. Those questions deserve measurement rather than speculation. I examine the limits and defensive implications in a [separate follow-up](/blog/people-asked-if-hiding-malware-in-a-model-actually-works).