--- title: "Does hiding malware in a model actually work?" description: "What a neural packer proves, what the prototype deliberately leaves out, and where the idea becomes relevant to real malware analysis." date: 2025-07-01 category: "technical" tags: ["ai","cybersecurity","malware"] published: true paywall: false --- My [first article about neural packers](/blog/you-can-hide-malware-inside-a-neural-network) described a simple experiment: deliberately overfit a small language model on a source file, then reconstruct that file through inference. The generated output matched the original SHA-256 hash. The result led to a reasonable question. Does this demonstrate a practical malware technique, or only an unusual way to store data? The honest answer is that it demonstrates one part of the technique. It proves that a model can act as an executable-content container without storing the original file as a conventional byte sequence. It does not, by itself, produce a complete malware loader. ## What the prototype proves The prototype trains an LSTM to memorize one file character by character. Generation begins with a known start token and continues until the complete sequence has been reconstructed. A checksum comparison verifies that the model recovered the file exactly. This matters because the stored representation looks different from an archive, encrypted blob, or embedded resource. The content is distributed across learned parameters and recovered through normal model inference. A scanner looking for a familiar binary signature will not find the original sequence inside the weights. The experiment establishes three useful facts: 1. Deliberate overfitting can be used as a storage mechanism. 2. The stored file can be reconstructed exactly rather than approximately. 3. Reconstruction can resemble ordinary machine-learning inference until the output is materialized. None of this depends specifically on an LSTM. A GRU or decoder-only Transformer could be trained for the same purpose. The architecture changes the cost and reliability of memorization, not the underlying idea. ## What it does not prove The repository uses a harmless bubble-sort implementation as its payload. It does not execute the generated output, load code into memory, establish persistence, or attempt to evade an endpoint product. Those omissions are deliberate. A real loader would still need to turn the generated sequence into executable behavior. Writing it to disk creates an obvious inspection point. Executing it directly from memory removes that file but introduces other observable actions, such as memory allocation, permission changes, dynamic loading, or suspicious system calls. The model solves only the storage and reconstruction problem. This distinction is important. Calling the prototype a complete antivirus bypass would overstate the result. It is better understood as research into an unconventional packing primitive. ## Is it only obfuscation? In a broad sense, yes. The technique transforms code into a representation that is harder to recognize and requires a particular recovery procedure. That is what obfuscation and packing techniques already do. The difference lies in the execution environment. Neural inference has become a normal workload on desktops, phones, browsers, and servers. Loading a model and running a tensor operation does not carry the same immediate suspicion as unpacking an encrypted executable. The malicious content becomes visible only after generation, while most of the preceding activity looks like legitimate use of an ML runtime. That does not make the technique invisible. It changes where defenders should look. Relevant signals include an unusually deterministic generative model, a model that emits high-entropy binary-like output, repeated reconstruction of the same sequence, and a process that moves generated data into executable memory. ## Hardware acceleration changes the visibility GPUs and NPUs add an interesting boundary. Much of the reconstruction may happen outside the CPU, using APIs such as DirectML, Core ML, or a vendor-specific runtime. Existing monitoring tools often provide less visibility into accelerator workloads than into conventional process execution. This could make the inference stage harder to inspect, particularly in sandboxes without matching hardware acceleration. It would not make the final payload disappear. Once generated code interacts with the operating system, traditional behavioral controls become relevant again. The practical defensive question is not whether an NPU can make malware magically undetectable. It is whether security tooling can follow data as it moves from an opaque model, through an accelerator-backed runtime, into a form the CPU can execute. Today, that path receives less scrutiny than conventional unpacking. ## The useful conclusion The prototype is small, but the boundary it exposes is real. Model files are increasingly treated as passive data, even though loading them may reconstruct content, execute framework-specific code, or influence systems with access to valuable tools. Defenders should inspect the complete model supply chain: serialization format, loader, inference behavior, generated outputs, and what the surrounding process does with them. Neural packing is not a finished replacement for established malware techniques. It is one more reason not to assume that a model is harmless simply because it looks like a model.