The Architecture of Zero-Disk-Footprint Inference
Why writing to a temporary file is a security fatal flaw, and how 'mmap' solves it.
The "Temp File" Trap
When developers realize they need to encrypt their files, their first implementation often looks like this:
- Read encrypted file from assets.
- Decrypt it in memory.
- Write the decrypted bytes to a temporary file.
- Load that temporary file into the library.
- Delete the temporary file.
This is a critical vulnerability.
On a rooted Android device (or even a standard one with the right permissions), a distinct "race window" exists. An attacker can run a file system watcher effectively waiting for that temporary file to appear. The moment it touches the disk, it can be copied.
Even if you delete it milliseconds later, flash storage retention and file recovery tools can often bring it back.
True Zero-Disk Footprint
To achieve Zero-Disk-Footprint, the decrypted data must never be written to the filesystem. It must strictly travel from the encrypted container to the RAM, and then directly into the Inference Engine.
The Challenge with TFLite
Standard TensorFlow Lite creates a MappedByteBuffer. It usually wants a file descriptor. If you don't give it a file, you have to manage the memory allocation yourself.
Our Solution: Custom JNI Allocators
TensorSeal uses the Android NDK to bypass the high-level Java file APIs entirely.
- Native Heap Allocation: We allocate a buffer on the native heap (outside the Java Virtual Machine's control) using
malloc. - Stream Decryption: We read the encrypted asset stream and decrypt it block-by-block directly into this allocated buffer.
- Direct Buffer Creation: We use
env->NewDirectByteBuffer()to wrap this native memory pointer into a JavaByteBufferobject. - Interpreter Injection: This
ByteBufferis passed directly to theInterpreterconstructor.
// Simplified C++ Logic
void* modelBuffer = malloc(modelSize);
// ... decryption happens here, writing directly to modelBuffer ...
jobject directBuffer = env->NewDirectByteBuffer(modelBuffer, modelSize);
return directBuffer;
Why This Matters
By keeping the model in the native heap:
- Root Access is Insufficient: An attacker with root file access sees nothing. They would need sophisticated memory dumping tools (like GameGuardian or specialized debuggers) to attack the RAM.
- Higher Barrier to Entry: attacking memory is orders of magnitude harder than unzipping a file. It moves the threat model from "script kiddie" to "state-sponsored actor."
Conclusion
"Encrypted" doesn't mean "Secure" if you decrypt to disk. Zero-Disk-Footprint is the only standard for high-value IP protection in 2026.