Steganography in the Shadows: Covert Messaging via the Least Significant Bits of Fine-Tuned ONNX Model Weights

Hi everyone, I wanted to present a project I’ve been working on, along with a brief overview of how it works and what led me to build it.

First a bit of background: I wouldn’t consider myself an expert in cryptography or steganography. These have always been secondary areas for me—necessary tools supporting my primary field of interest rather than the main focus themselves. For this project, I did my best to study current best practices (leaning heavily on NIST guidelines), the implications involved, and the potential attack vectors against this kind of information hiding. But I genuinely can’t say with confidence that I’ve covered every angle, which is why I’m sharing this here—primarily as a learning opportunity. I’d really appreciate any feedback on what I could have improved or what I may have overlooked. At this point, I consider the project finished and likely won’t be updating it further, though I plan to carry any feedback forward into my own understanding.

I spent more than a month researching how machine learning models could serve as carriers for hidden data. This was needed as one component of a larger project I’m working on.

That exploration led me to the idea of concealing information inside model weights. My first thought was a straightforward approach—just write data directly into randomly chosen weights. But I quickly realized this would be ridiculously easy to spot and potentially trivial to extract as well.

The next concept involved something like a deterministic coordinate system describing where to pull data from (using location-id + position-id pairs). Rather than altering every bit required to store the message, the tool would instead write separate bits that point to specific locations within the model, and the existing 0s and 1s at those locations would be read to reconstruct the hidden content. In practice, only parties A and B would know how to derive these positions. This way, anyone unfamiliar with the algorithm would just see what appears to be noise scattered across various values.

However, after thinking through a practical implementation, this approach turned out to have serious weaknesses. Even putting aside the fact that the primary goal here was steganography rather than encryption, the mere existence of extra data could be detected fairly easily—for example, through delta analysis comparing against a reference model, or through statistical analysis of the weight distributions. On top of that, this scheme would only allow transmitting tiny amounts of data, because just encoding a word like “example” would require a sequence like: “01100101011110000110000101101101011100000110110001100101”, making it wildly impractical. In short, even if the hidden message itself couldn’t be deciphered, someone could still reasonably suspect the model contains concealed information—which would completely undermine the purpose of steganography.

While I found that earlier option intellectually intriguing, I moved past it and asked myself: “How can I hide data in the weights so it won’t be detectable?” That question gave birth to the next idea: since every fine-tuning process naturally alters some of a model’s weights anyway, why not hide information exclusively in the weights that get changed during training? That way, the fine-tuning process itself would serve as a natural and perfectly logical explanation for those modifications—even when someone compares the model against a reference version.

I only discovered later that related concepts had already been described in academic literature, though they remain a fairly specialized area of research.

Setting aside the implementation specifics (since everything is documented in the README and SECURITY files, and I don’t want to unleash an even bigger wall of text here), that’s how the first version of this solution—originally part of my main project—came to life. After digging deeper, I noticed that most existing publications lean heavily toward the academic side, while the available GitHub repos were often poorly documented, limited in functionality, solid from a steganographic standpoint but weak on the cryptographic side, or just small fragments of larger projects. Personally, I couldn’t find any project implementing a comparable approach specifically targeting models stored in the ONNX format.

So I decided to carve this piece out and polish it into a standalone proof of concept, and that’s how ONNXStego was born.

If anyone’s curious about the security aspects, limitations, or implementation details, I’d encourage you to check out the repository. I personally gained a tremendous amount from this project and made every effort to document the final conclusions and insights I picked up along the way as precisely as possible, so I’m hoping the project can also serve as a useful resource for others in their own work or endeavors. (If this comes across as self-promotion, I apologize ahead of time—I can take this post down for that reason if necessary. I tried to lay out the entire development process as honestly as I could, aiming to make the post as educational and informative as possible).

Link: