elf A field note by Vikrant Sharma
Storing metadata in ELF binaries with SQLite
Someone embedded a SQLite database directly into a Linux executable. The binary still runs, the database still queries, and the toolchain does not care.
Farid Zakaria wrote about embedding a SQLite database into the data section of an ELF binary. The executable runs normally. You can also open it with sqlite3 and query tables.
The trick is that ELF loaders ignore data they do not recognise. SQLite databases start with a magic header, but that lives in a section the loader skips. The binary format is a container, not a strict schema. You can stuff arbitrary blobs into it as long as you do not clobber the program headers or section table.
This is not theoretical. Zakaria built a working prototype. The executable has a .sqlite section holding the database file. Standard tools like readelf still work. The binary passes through stripping and signing without corruption. You query it by passing the executable path to sqlite3 as if it were a .db file.
Why would anyone do this? Provenance metadata. Instead of shipping a separate SBOM or build manifest, you embed it in the binary itself. The metadata cannot drift from the artefact because it is the artefact. Package managers could query installed binaries directly without parsing external files.
The cost is file size. A minimal SQLite database adds roughly 100 kilobytes. That matters for containers with thousands of binaries. It does not matter for a single executable shipped to end users.
I would not use this in production yet. The tooling assumes ELF sections are for the loader, not for post-deployment queries. Debuggers might stumble. Security scanners might flag it. But the idea is sound. Executables are already compound formats. We just stopped thinking about them that way.
Source: Executable Is a SQLite Database
