ODIS uses HSQLDB for databases.
They are usually passworded, but you can easily modify the HSQLDB jdbc driver to dump the password for you. The check is quite naive.

Download ODIS and dump them.

Normally I'm able to figure things like that out myself. But this time...
Can someone give a hint how to throw the .db/.key files on a HSQLDB?

Hm, I think there should be some useful data inside the .db files. Maybe not in a useful format.
The .db files consist of many zlib compressed streams. After extracting them, you get some binary packets. Maybe this is already the binary MCD data you are mentioning.
Maybe there is a way to convert the binary MCD back to ODX.

Hi

Can someone explain/help me with understanding *.db and *.key files. Is there any option to get *.odx files from them ?

Regards

Quite an interesting topic. I am here with some info.

First off, if you want UDS data, best place to look is VCDS. Their obfuscation, compression and encryption procedure for ROD files is admirable, but not particularly secure once you understand it. A very similar algorithm is used for the Codes.dat file in the root folder, that one holds fault code text and other strings for tables. Now that I'm writing this, they will probably change the algorithm for the next version. But in any case, their files for modules newer than ~2019 also include the dongle itself in the decryption process. A separate cryptography IC on the STM32-based dongles provides some bytes which are necessary for decoding those files. There is nothing special about the new dongles that the old ones couldn't do, they just locked functions behind the new version. But I understand them, considering how much effort they have poured into this program.

In any case, VCDS' databases are definitely much nicer to work with than ODIS'.

I have not investigated ODIS all too much, except for what other users already pointed out, but here are my findings so far.

The /DIDB/db folder in the ODIS installation contains many such pairs: .data, .inf, .script, .properties. Exactly like user @prj hinted, these are HSQLDB databases. But they are created with an ancient version, 1.8.0. If you try to open them with the latest version, you will get an error. So I downloaded the source code for that version, installed a very ancient Java JDK 1.4 and modified the file UserManager.java, function createUser, to print out name and password.
For future reference, the username is VAUDASISTSUPER and password ENMGZIRN (lol, I think the username means "Vaudas ist super"; I have seen that name throughout the files, if someone knows what it means, please let me know).
These databases contain text and module file associations and stuff like that, strings which you can also find in VCDS which might mean this is also the source of their data. But not everything is present here unfortunately.

Now about the .db and .key file pairs. I suspect these files contain the most important data, as their names suggest they hold individual data for a very large list of modules.

The .db file presents ZLIB streams in succession. Decompressing them reveals binary data, and every decompressed stream ends in the characters "#>" and a NUL.

The .key file has data which can be accessed using the "PBL" C library by Peter Graf. It looks like this file contains as many "records" as there are ZLIB streams in the other file, so there must be a correspondence. Each "record" contains a "key" (4 byte value) and a "data" field (6 to 8 bytes).
Edit: now that I look more closely, it seems that you can find every "key" value with a hex editor somewhere in the .db file after decompressing. It seems they appear in those larger streams, not the ones which only take one line.

Unfortunately, this is the dead end.

I know for certain that people have gained access to this data. Anyone who has ideas is free to share them.

@prj I understand you completely, I am not here to beg.

I think I should take a closer look at the VW MCD PDX converter. I found the strings "pblKfOpen", "pblKfRead" etc in one of the .dll files, which are exactly the names of the functions from that PBL library used on the .key files. Once I figure out how to reverse engineer this...