When you work in IDA, it saves the results of your analysis in the IDA Database, so that you can pause and continue at a later time. You can recognize the database files by their file extension .idb (for legacy, 32-bit IDA) or .i64 (for 64-bit IDA or IDA64). Thus they’re also often called just IDB. But what do they contain?
You can get a hint by looking at the working directory when the IDB is open in IDA:
So, IDB is a container which contains several sub-files:
filename.id0is the actual database (implemented using B-tree), which contains all the metadata extracted from the input file and/or added by the user (names, comments, function boundaries and much more);filename.id1stores the virtual array, containing a copy of all data loaded from the input file plus internal flags needed by IDA. Due to that it is usually 4-5 times as big as the original file but may grow or shrink if you add or remove data from the database;filename.id2(if present) stores the data for sparse memory areas (e.g. mostly zero-filled segments) used in some situations;filename.namis a special cache for names used in the database;filename.tilis the type library containing Local Types for the database.
When you close the database, IDA gives you a choice what to do with these files:
- Don’t pack database leaves the individual sub-files on disk as-is. It is the fastest option but also can be dangerous because there are no integrity checks so any corruption may go undetected until much later;
- Pack database (Store) simply combines the sub-files into an
.idbor.i64container, adding checksums so that file corruption can be detected. Because no compression is used, the IDB size is roughly equal to the total size of the sub-files; - Pack database (Deflate) compresses sub-files using zlib compression which can significantly decrease the disk space compared to the Store option at the cost of more time spent saving and unpacking the IDB.
See also:
Igor’s tip of the week #58: Keyboard modifiers
