{"id":33193648,"url":"https://github.com/mbrown1413/sqlitefind","last_synced_at":"2026-01-21T02:31:06.125Z","repository":{"id":138845629,"uuid":"76312716","full_name":"mbrown1413/SqliteFind","owner":"mbrown1413","description":"A Volatility plugin for finding sqlite database rows","archived":false,"fork":false,"pushed_at":"2019-07-14T14:22:49.000Z","size":78,"stargazers_count":22,"open_issues_count":1,"forks_count":4,"subscribers_count":3,"default_branch":"master","last_synced_at":"2024-05-18T12:34:13.804Z","etag":null,"topics":["computer-forensics","sqlite3","volatility-plugins"],"latest_commit_sha":null,"homepage":null,"language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/mbrown1413.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null}},"created_at":"2016-12-13T01:55:19.000Z","updated_at":"2023-07-29T04:14:18.000Z","dependencies_parsed_at":"2023-07-10T10:31:52.693Z","dependency_job_id":null,"html_url":"https://github.com/mbrown1413/SqliteFind","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/mbrown1413/SqliteFind","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mbrown1413%2FSqliteFind","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mbrown1413%2FSqliteFind/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mbrown1413%2FSqliteFind/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mbrown1413%2FSqliteFind/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/mbrown1413","download_url":"https://codeload.github.com/mbrown1413/SqliteFind/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mbrown1413%2FSqliteFind/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28508464,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-17T11:50:55.898Z","status":"ssl_error","status_checked_at":"2026-01-17T11:50:55.569Z","response_time":85,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["computer-forensics","sqlite3","volatility-plugins"],"created_at":"2025-11-16T07:00:31.294Z","updated_at":"2026-01-17T12:00:50.529Z","avatar_url":"https://github.com/mbrown1413.png","language":"Python","readme":"\nSqliteFind is a Volatility plugin for finding sqlite database rows. It can automatically find database schemas in `sqlite_master` tables, and recover database rows from memory.\n\n  * [Tutorial](TUTORIAL.md)\n  * [How it works](HOW_IT_WORKS.md)\n\n\nInstalling\n==========\n\n\"sqlitefind.py\" must be in the plugin path and \"sqlitetools.py\" must be\nimportable. You should either add this directory to your volatility plugin\npath, or add a link to these files inside the volatility plugin folder.\n\nRequires the YARA Python API. Try installing the pip package \"yara-python\".\nRunning \"import yara\" should work in the Python shell.\n\n\nBasic Usage\n===========\n\nFind tables:\n\n    $ volatility -f \u003cmemory file\u003e sqlitefindtables\n\nRecover table rows:\n\n    $ volatility -f \u003cmemory file\u003e sqlitefind -t \u003ctable name\u003e\n\nFor a guided tour, see the [Tutorial](TUTORIAL.md).\n\nSee below for the common options, or use `--help` for a complete list of\noptions.\n\n\nsqlitefindtables Command\n========================\n\nSearches for an `sqlite_master` table and shows the schemas found in them.\n\n    $ volatility -f \u003cmemory file\u003e sqlitefindtables\n\nUse `-R`/`--raw-sql` to output the schema in raw SQL.\n\n\nsqlitefind Command\n==================\n\nSearches for database rows in memory, given the table schema. There are a few\nways to specify the schema. You can specify the table name, in which case the\nschema matching the table name will be searched for in an `sqlite_master`\ntable:\n\n    $ volatility -f \u003cmemory file\u003e sqlitefind -t \u003ctable name\u003e\n\nAlternatively, you can specify the table schema manually:\n\n    $ volatility -f \u003cmemory file\u003e sqlitefind \n                 -c \"id:int,null; place_name:string; visited:bool\"\n\nSchema strings are output from `sqlitefindtables`, so you can just copy from\nthere and modify if needed. Each column, separated by a semicolon, is a comma\nseparated list of types. If a column starts with `name:`, then `name` is used\nas the column name. You can use the following types:\n\n  * `?` - Specifies unknown, could be any type.\n  * `bool` - Assumes schema format 4 or higher is used. If older schema, use\n             \"int8\".\n  * `null` - Fields cannot be NULL by default, don't forget to add this if\n             needed.\n  * `notnull` - Negates a previous \"null\".\n  * `int`\n  * `int\u003cn bits\u003e` - `\u003cn bits\u003e` must be one of 8, 16, 24, 32, 48, 64\n  * `float`\n  * `string` / `blob`\n  * `timestamp` - Same as `int64`.\n  * `\u003cserial type\u003e` - A serial type number as defined by the [Sqlite file\n                    format](https://www.sqlite.org/fileformat2.html#record_format).\n\nOne thing to notice is that **NULL is not allowed by default**. Make sure to\nadd `null` to your type list if it is a possible value.\n\n\nOutput Format\n-------------\n\nYou can include different values in the output using the \"-O\" option, which is\na comma separated list of:\n\n  * `values` - A field for each sqlite column.\n  * `all_values` - One field that is a list of every sqlite column.\n  * `address` - Address the sqlite row was found in memory.\n  * `all_types` - A list of types for each column in this row. Each type will\n                  be an integer serial type.\n\nFor example, to show the memory address of the row followed by the values:\n\n    $ volatility -f \u003cmemory file\u003e sqlitefind \\\n                 -c \"int,null; string; bool\" \\\n                 -O \"address,all_values\"\n\nCSV output is also supported, using \"--output=csv\":\n\n    $ volatility -f \u003cmemory file\u003e sqlitefind \\\n                 -c \"id:int,null; field1:string; field2:bool\" \\\n                 -O \"address,values\" \\\n                 --output=csv --output-file=data.csv\n\n\nLimitations\n===========\n\nNeedle Size - Based on the table schema, we may not be able to find a suitable\nsequence of bytes to search for. The smaller the needle size, the slower the\nsearch will take.\n\nLarge Records - If a record does not fit in one B-Tree cell, it will be either\nmissed or corrupted. This is because the rows are searched without using any\ndatabase header information. If a row is large enough to be split between\nmultiple pages, we can only find the data from the first page. After that,\nwe will either read garbage data, or encounter an error and assume that it's\nnot a real row.\n\nFalse positives - There are a lot of checks to make the data parsed is actually\na row, but especially when there are not many columns, false positives can be\nfound. Usually false positives are easy to recognize by hand. They typically\ncontain many NULL values (None) and strings will contain nonsensical data.\n\n\nAbout\n=====\n\nWritten by Michael Brown as a project for the Computer Forensics class taught\nby Fabian Monrose at the University of North Carolina Chapel Hill. Feel free to contact me at [michael@msbrown.net](mailto:michael@msbrown.net), or start an issue on [GitHub](https://github.com/mbrown1413/SqliteFind).\n\nThe idea of searching for sqlite database rows in memory is based on Dave\nLassalle's (@superponible) [firefox volatility\nplugins](https://github.com/superponible/volatility-plugins), which can find\nfirefox and chromium data in memory. I wanted to generalize the idea so no code\nwould need to be updated when a schema changes, and any sqlite database could\nbe recovered.\n","funding_links":[],"categories":["\u003ca id=\"4d2a33083a894d6e6ef01b360929f30a\"\u003e\u003c/a\u003eVolatility"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmbrown1413%2Fsqlitefind","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmbrown1413%2Fsqlitefind","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmbrown1413%2Fsqlitefind/lists"}