![]() ![]() Although a page has a structure it is a little more free-form and slightly more complex to describe. A list of pages that are not currently in use is held in the freelist, the freelist itself is stored as one or more pages. The first few rows of the sqlite_master table for a Skype database are shown below:Īs tables are appended to, records are modified or records are deleted the number of pages used by a table can grow or shrink and records can be moved between pages. So to find out where the root page of any table or index is located we just need to read the sqlite_master table at page 1 and locate the entry for the table/index and get the location for the root (rootpage). “table”,”DbMeta”,”DbMeta”,”2″,”CREATE TABLE DbMeta (key TEXT NOT NULL PRIMARY KEY, value TEXT)” ![]() The schema for the sqlite_master table isĪ typical entry for a row in this table follows (in csv form), this is the DbMeta table from a Skype database, we can see the SQL CREATE statement for the table in the SQL column and we can see that the rootpage for this table is at page 2. The master table tells us where the root of every user created table and index can be found. There is a master table (sqlite_master) that resides (has its root) in the first page of the database and may overflow into additional pages. ![]() Each table or index is stored as a B-Tree (Balanced tree) with each B-Tree occupying one or more pages. you will not find live records from different tables in the same page. A page can only be used for one table/index i.e. The first 100 bytes of the first page contain a header the remainder of this page follows the same structure as every other page (although the ‘data’ area is reduced by 100 bytes).Ī database is made up of a number of tables and indexes (indexes are just a special sort of table) and each table/index uses one or more pages. SQLite databases are made up of a number of pages of a fixed number of bytes, either 1024, 2048, 4096, 8192, 16384, 32768 or 65536. I then show you how the deleted records and partial deleted records look when you open the database in The Forensic Browser for SQLite. At that point, I can give a basic overview of the algorithm used to recover the non-live records which will give you, as the investigator, a handle on how much confidence you can ascribe to one of these records. I will also show how the first few bytes of records are regularly overwritten by SQLite structures and how these partial records can be recovered.īefore I can discuss how we do this, it’s quite straight forward with SQLite Forensic Recovery, I need to take you briefly through a slightly simplified structure of a database explaining how the database fits together and how records are stored within the ‘pages’ of the database. In this article, I want to discuss how we can recover deleted records from an SQLite database, or rather how we can recover all records and distinguish between those that are live in the DB and those that are found in unused areas and do not match a live record. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |