IDA "Corrupt" Databases

Does anyone know how IDA determines that a .idb database file from a previous version of IDA is "corrupt" and refuses to load it. It is obvious that the creators of IDA know that there are non-legit copies of IDA floating around, but how is the registration information for each copy embedded into the database file? Does anyone know what exactly is the program looking for in the .idb file to flag it as corrupt? All I want to do is migrate a few old database files to the newer version of IDA.

xtx

[Eleven]

They watermark a bunch of registration details including some values associated with the registration username/details which aren't made public to even the registered user. Unless you know where to look and what the values are it won't be easy to modify the database to work with newer versions.

However, with a few later releases of IDA there have been corrupt-database patches that allow it to load any database that has been blacklisted, so your best bet would be to search for that.

One follow up question. If I do patch the current version, load a "corrupt" database from a previous version and then save it, which set of watermarks are in the database? Does IDA update the database with the current version information, or does it leave the old watermarks? The only reason that I ask is that I simply want to upgrade the old databases to work with an unpatched version of IDA. It makes it easier to migrate and work on multiple computers.

xtx

[infern0]

You can just pacth idag.exe and ida.wll (unpack them before). There are blacklist check near the message "database is corrupt". You can see MD5 hash calculation and comparison with an build-in list of MD5 hashes of stolen keys. Just patch this routine to return al=0 and you can open all "corrupted" DB. I work with patched version 4.7 about 2 month - all seems to be ok.

[_Servil_]

theres one node in the idabase havig stored the lic.key & reg.name into it.
guess it would prevent future blklisting changing it to anything else but seems ida rewrites it always with present license whenever its changed.

[edir]the name is overwritten _after_ ida loads so it can be changed before saving then upgrade to new version ok, it gets overwritten back afterall however.
patching ida wll is still better than changing each idabase.

1.> unpack ida.wll (aspack 2.12)

2.>.text:1001C7C9 00C 8B 7D 10 mov edi, [ebp+n]
.text:1001C7CC 00C 8B 4D 08 mov ecx, [ebp+s1]
.text:1001C7CF 00C 8B 75 0C mov esi, [ebp+s2] ----> blacklist
.text:1001C7D2
.text:1001C7D2 loc_1001C7D2: ----->md5 compare
_memcmp+45j
.text:1001C7D2 00C 83 FF 04 cmp edi, 4
.text:1001C7D5 00C 7C 34 jl short loc_1001C80B
.text:1001C7D7 00C 8A 01 mov al, [ecx]
.text:1001C7D9 00C 8A 16 mov dl, [esi]
.text:1001C7DB 00C 3A D0 cmp dl, al
.text:1001C7DD 00C 75 2C jnz short loc_1001C80B
.text:1001C7DF 00C 8A 41 01 mov al, [ecx+1]
.text:1001C7E2 00C 8A 56 01 mov dl, [esi+1]
.text:1001C7E5 00C 3A D0 cmp dl, al
.text:1001C7E7 00C 75 22 jnz short loc_1001C80B
.text:1001C7E9 00C 8A 41 02 mov al, [ecx+2]
.text:1001C7EC 00C 8A 56 02 mov dl, [esi+2]
.text:1001C7EF 00C 3A D0 cmp dl, al
.text:1001C7F1 00C 75 18 jnz short loc_1001C80B
.text:1001C7F3 00C 8A 41 03 mov al, [ecx+3]
.text:1001C7F6 00C 8A 56 03 mov dl, [esi+3]
.text:1001C7F9 00C 3A D0 cmp dl, al
.text:1001C7FB 00C 75 0E jnz short loc_1001C80B
.text:1001C7FD 00C 83 EF 04 sub edi, 4
.text:1001C800 00C 83 C1 04 add ecx, 4
.text:1001C803 00C 83 C6 04 add esi, 4
.text:1001C806 00C 83 FF 04 cmp edi, 4
.text:1001C809 00C 7D C7 jge short loc_1001C7D2
.text:1001C80B
.text:1001C80B loc_1001C80B: ; CODE XREF: _memcmp+11j
.text:1001C80B ; _memcmp+19j ...
.text:1001C80B 00C 85 FF test edi, edi
.text:1001C80D 00C 75 04 jnz short loc_1001C813
.text:1001C80F 00C 33 C0 xor eax, eax -----> found in blacklist
.text:1001C811 00C EB 19 jmp short loc_1001C82C

bp at 1001C80F to get blacklist md5 16-byte, search and zero them in ida.wll

done...............

hope it will help

[ee45678]

Here is a much easier way.
1) Unpack ida.wll
2) Load ida.wll in the new IDA
3) Go grab something to eat while IDA analyzes the file
4) Open IDA menu View>Open subviews>Strings (Shift+F12)
5) Search for "Database is corrupt"
6) Double click the search result
7) Double click the xref
8) Use IDA or your favourite hex editor to patch the code shown, e.g.
------------------------------------------------------------------------
.text:10014804 loc_10014804: ; CODE XREF: Proc_DatabaseIsCorrupt+41j
.text:10014804 ; Proc_DatabaseIsCorrupt+48j
.text:10014804 ; Proc_DatabaseIsCorrupt+4Fj
.text:10014804 push offset aDatabaseIsCorr ; "Database is corrupt"
.text:10014809 call sub_1000404C
.text:1001480E pop ecx
.text:1001480F
.text:1001480F loc_1001480F: ; CODE XREF: Proc_DatabaseIsCorrupt+6Dj
.text:1001480F pop ecx
.text:10014810 pop ebp
.text:10014811 retn
------------------------------------------------------------------------
You can either nop bytes from loc. 10014804 to 1001480E (easy)
or you can assemble a "jmp 1001480F" at loc. 10014804 (elegant)
9) Copy the patched ida.wll to IDA directory, exit all instances of IDA before this step
Fire up IDA and load any old database, it will ask to upgrade to new format, select yes and it will load OK :-)
Just remember to save the loaded database once so that it is saved in the new format.
Excluding the time taken for step 3. it took me more time to type this message than required for fixing IDA.

[pp2]

Seems strange, that nobody have posted the same solution for Linux version of IDA 4.7. Ok, here it is:
Patch these bytes in libida.so (it is not packed)
00058105: 48 58
0005810E: 3F 4F
00058117: 36 46
0005814B: 02 12
000E2E0B: 78 90
000E2E0C: 0E 90
000E2E17: 75 90
000E2E18: 02 90
000E2E6E: 74 EB

p.s. there is also another one sort of protection: "timezone" databases. it can be also patched in order to load german databases into english versions of ida for example...