Pages: 1 2 [3]
Author Topic: Routine Identifiers  (Read 54314 times)
prj
Hero Member
*****

Karma: +1072/-480
Offline Offline

Posts: 6035


« Reply #30 on: June 26, 2024, 10:56:05 PM »

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

PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
kartoffelpflanze
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 7


« Reply #31 on: June 27, 2024, 02:48:11 AM »

@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.
Logged
kartoffelpflanze
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 7


« Reply #32 on: June 28, 2024, 07:40:58 AM »

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 Cheesy

Baby's first steps.
Logged
kartoffelpflanze
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 7


« Reply #33 on: June 28, 2024, 01:35:31 PM »

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 Smiley 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.
Logged
kartoffelpflanze
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 7


« Reply #34 on: June 28, 2024, 11:44:01 PM »

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.
Logged
Pages: 1 2 [3]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.016 seconds with 17 queries. (Pretty URLs adds 0.001s, 0q)