NefMoto

Anyone have a list of the routine identifiers for VAG cars?

To be more clear I'm looking for routines that would the value between the range of 0x0200 and 0xDFFF and possibly 0xF000 - 0xFEFF.

Which KWP or UDS?

UDS , but I always enjoy increasing my kwp/tp knowledge.

Send me the ecu/a code and I'll try to export it all for you, faling  give me list.

What you your plans are and objectives too;

I'm interesting too :)

In what exactly?  What engine/car/year?

I think he was just saying that he was interesting

interested he meant.

Hi, it's possible for Seat Leon 1P TFSI ?
All routine for Multi map e85/sp98 & LC with NLS

Marque calculateur : BOSCH
Type ECU : MED9.1/5
Hardware : 0261S02699
Software : 1037504349
Update : 1P0907115AB 0020

Don't have anything in my UDS DB for seat, sorry.

Hi,
can you share the routine identifiers for EDC17c46 UDS Audi A3 ecu?
part no: 03L 906 018 AB

thanks

You are usking someone who is no longer with us.

As in he passed away or is banned?  dream3R?  Not daz.

Unfortunately, dream3r passed away too.

Oh, I'm sorry. My bad.

So does anyone have any idea on how to decrypt and restore these .DB and .KEY files that are stored in the Projects folders of ODIS?

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.

I'm interested in how to get these ODIS db files.

Download ODIS and dump them.

This might sound like a stupid question, but where can it be downloaded? I thought it's not available to the general public and provided to VW dealerships only.

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.

As I said, I have dumped all of it :)

Hi :)

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

Regards

Hi,
I find you can decrypt HSQL db of ODIS. Can I request it to you? If so, how much cost I have to pay?
I also wish to know which version of ODIS you can do. Latest version is ODIS-S 11.

Thanks in advance,
Chris

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.

The HSQLDB does not contain much of value. Some translations mostly.
The data is in the db/key files.

I don't have any motivation to tell anyone how to dump that.
But at least OBD11, Ross-Tech and myself have done that. Probably others as well.

I am not sure that the method used by everyone is the same, there are a few ways to approach it.
But that's all I can say, as I have a commercial interest in this.

@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...

Instead of looking at the actual file binary formats and trying to reverse them, look at the higher levels in ODIS (or somewhat easier, iDEX) and see how they are using the provided libraries to load the data. VW already gave you the abstractions you need, you can just iteratively open and request all of the data from the native ASAP2 libraries provided. Way easier than dealing with the horrendous file formats.


I always figured that modern-day Ross-Tech and OBD11 were buying diagnostic data rather than reversing it, given that for example OBD11 also license SFD access and have their own keys issued to the VW servers. Certainly Ross-Tech started by reversing but these days I'm not so sure? Anyway just banter either way.

Ross tech stuff looks completely identical to ODIS (meaning dumped). OBD11 I have not looked at.
SFD I can't comment.

@d3irb, I don't know what iDEX is. I'll also add that I did everything I talk about below before I read your reply. It would be nice to be able to just ask an API to give me all data from a MCD database (that's what .DB+.KEY represent apparently), but I haven't gotten there yet.
-------------------

So I have found that ODIS automatically installs some tools, including MCD-Kernel (which is supposed to be used for creating your own app using the MCD archives) which even has documentation. Unfortunately, a "secret" code and a MAC challange protects the kernel from being used unlicensed and I haven't been able to reverse engineer it.

They also provide an app called "VWMCDClient", which should basically work like VCDS if I understand the docs correctly. Unfortunately I don't have a VAS interface, but selecting DoIP as protocol, it loads all fields from the selected project. If I had an interface, I would be able to read live data, DTCs etc.

So, since I wasn't getting anywhere, I just opened this app with a debugger. I found where the function pblKfOpen is called, which opens the .KEY files. This is what I understood so far:
-the .KEY file has as many records as its corresponding .DB file has ZLIB streams
-a record from .KEY has a data field of either 6 or 8 bytes
-the first 4 bytes will be used for fseek(), to go to that offset in the .DB file; it will land exactly on the start of a ZLIB stream
-if the data length is 6, the second-to-last byte represents how many bytes the raw ZLIB stream has, and the last byte represents how many bytes it will take after decompression
-if the data length is 8, it's basically the same, but the two sizes take 2 bytes instead of 1, so it can represent larger values

Then it seems to look at the first 2 bytes from the decompressed data. This is as far as I got, next follow other complicated functions, probably to interpret the binary data. I'll continue some other time.

It also looks like it searches for the key 7CB90138 in every .KEY file from the project. They all seem to start with the two bytes 3300. Then it does something with the DatabaseVersionInfo.txt file from the project folder, I think.

Alright, so if I wish to get anywhere with this, I should probably use the tools VW provide. I would be a fool not to.

I barely looked at the Java library, it doesn't seem to include the functions for authenticating the MCD kernel, a.k.a. the first thing you need to do in order to use it. I have close to no experience with it, so I knew I had to go down the C++ route.

I wasted way too much time with my beloved IDE, Codeblocks. For the life of me, I cant figure out how to make it accept the .lib, it just wasn't solving the imports. Eventually, I installed Visual Studio, and it's way less scary than it seems. I was able to get everything error-free very quickly.

So to start using the Kernel, you first need to request a seed, then apply a "secret" procedure  to it (exactly what the docs say), then you send it back, check that it was accepted and then create an instance of the MCDSystem.

I tried reverse engineering the secret function from the included Client app, but I already wasted too much time on this for today. I saw that it uses a constant table stored in the exe, which it XORs with bytes 0x36 and 0x5C, then it clearly uses the SHA-512 algorithm, just like the docs say. Maybe I'll continue some other time.

So I got an idea for a temporary solution. I start my app, which spits out the seed in the console. Then I start up the Client app, attach the debugger, make it stop at a breakpoint right after it requests the seed from its instance, I go in its memory and edit the 64 bytes, pasting the ones my program gave me. Then I set another breakpoint just before it gives the secretly-calculated MAC, I copy that and paste it in my program's console, it parses the string as hex bytes, gives it to the Kernel and it succeeds. Then asam::mcd::MCDSystem.createInstance() executes without throwing an exception :D

Baby's first steps.

Or I can just patch McdKernel_vc120_64.dll to think it got a 0 from memcmp when it tries to compare the MAC you give it against the MAC it is expecting. I guess I just wrote my first crack :) Reversing the secret MAC generator is definitely not worth it.

And yes, I'm able to iterate through Logical Links and Locations in a project after accessing the VehicleInformation. There are still many functions to experiment with.

Alright so I think it's time for a conclusion. The Kernel has so many functions, I don't even know if I can try all of them.

To clear things up, for anyone else searching for how to open .DB and .KEY files, don't. They are part of an "MCD-3 D" project, contained by that folder they are in. The MCDKernel is used for working with these databases, and you can write your own C++ project with it.

It's very nice that all .h files have descriptions for the functions, so they are documented in a way. Some do reference the ODX documentation which isn't really available, but overall you don't need it.

So the only thing stopping you from accessing all the data in any project you want, is the Kernel's MAC challenge, which is easily defeated by patching one instruction in the DLL.

I feel bad for having spent so long trying to understand the binary format...

If anyone else is interested, tell me here, and I will give more instructions.