17

I'm reversing an application with IDA. My VM crashed and left the IDA database in a corrupted unpacked state.

The next time I tried to load it back, IDA gave me the following error message: The input database is corrupted: CRC32 mistmatch. Continue? a few times, then it quit with the error bTree error: index file is bad. Google-ing these error messages gave no useful results, which is unusual.

I'ld like restore the database, or at least extract the data somehow.

I've already tried the following:

  • Zynamics bindiff (couldn't open the IDB, said it's probably opened in another IDA instance, which I guess Is a result of the corrupted data)
  • Manual hex diff - I just can't interpret the output.

At this point I'm thinking of somehow parsing the IDB and then diffing that output manually.

So, how can I parse/extract data from IDB files?

Related.

Improve this question
12
  • 3
    In such a case the first thing I would do is: cancel. After that I'd take a backup of the packed and the unpacked IDB and then proceed with either of the choices IDA gives and then backtrack and use the other choice if the former doesn't work. If your VM crashes the state of the DB is likely in an inconsistent state, so the best bet is to contact [email protected]. Otherwise you can use the SDK and the IDA book to figure out the details of the IDB format and extract what details you can salvage.
    – 0xC0000022L ♦
    Commented Jan 13, 2014 at 17:25
  • 1
    openrce.org/forums/posts/917
    – Vitaly Osipov
    Commented Jan 14, 2014 at 3:34
  • 2
    @VitalyOsipov: I find myself in this situation every now and then. And while it makes sense to ask Hex-Rays support it makes equally sense to inquire about a public key. For example it could be that the IDB contains sensitive data that must not get to any third party under any circumstances. So I think regardless of the background it's a valid and valuable questions. I for one hope to see an answer pointing to such publicly available tool. Even if it may only sate my appetite for curiosity about the IDB format without digging into netnode.hpp ;)
    – 0xC0000022L ♦
    Commented Jan 16, 2014 at 2:54
  • 2
    If someone gives an answer pointing to an open source tool that is publicly available, I'll reward that with 150 extra reputation points on top of Dominik's bounty.
    – 0xC0000022L ♦
    Commented Jan 18, 2014 at 13:55
  • 1
    The best person to answer this is Ilfak G. himself.
    – 0xec
    Commented Jan 18, 2014 at 14:21

3 Answers 3

Reset to default
7

I published some tools on github which can do just that: https://github.com/nlitsme/pyidbutil and https://github.com/nlitsme/idbutil. The first is written in python, the second in C++, both have similar functionality.

pyidbutil provides the most low level recovery options: using --pagedump you can dump each page in the file without the need of an intact logical file structure.

Improve this answer
2
5

Unfortunately, I cannot provide answer what to do when your database is already corrupted. That's the nature of proprietary binary databases: if you're hosed, you've got to keep all the pieces.

But I may suggest that you should foresee and be prepared to IDA database corruption, which is imminent and happens sooner or later to almost everyone. So:

  1. Prefer using unpacked database (less bugs to trigger in IDA).
  2. Make backup of binary database files early and often.
  3. Save your database as an IDC file early and often (File -> Produce File -> Dump database to IDC file).

Give step 3 a special attention - an IDC file is your ticket out of IDA walled garden. It is known that it doesn't contain all the information IDA stores in the database, but it has most important, and it is a text file which you can re-import into IDA to restart analysis with just an executable file, or process with a simple script to filter out needed data, etc.

Overall, the problem of database corruption can be solved only with an open tool which uses database in open format. As a shameless plug, I work on interactive disassembler which stores database in a simple text format - ScratchABit. Sooner or later, IDC import script will be written for it.

Improve this answer
2

In my instance the error was "Read error: read past end of file (file position 0x0, wanted 0x20X bytes, read 0x0".

After trying different things for a while, I realised the .id2, .nam and the .til unpacked database files were all having a size of 0KB. Opening the same executable file as a new database, the associated .id2, .nam and .til files had definite sizes.

What I did was to replace the .til file of the corrupted database with the .til file of the new database. The database opened and breakpoints were intact.

The only issue was that the names window became empty. However looking through the database, I realised the names I had entered manually were still there but were in greyed text. At this stage though, it would not be difficult to recover the names using a script as the names and their addresses are part of the database text.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.