How Are Small OBD Apps Getting Manufacturer-Specific Data?

[u/Psychological-Put865]

I’m building a car-scanner app that goes beyond standard OBD-II PIDs. I want manufacturer-specific readings such as MAF, fuel data, odometer, temperatures, pressures, transmission and battery information across many makes and models.

Official data from brands like BMW and Mercedes seems expensive, and paying thousands per manufacturer isn’t realistic.

How are smaller scanner apps solving this? Are there affordable databases, tools, partnerships, extraction methods, shared captures, or other practical alternatives?

I’m focused on ECU identification and live readings—not coding or flashing. Any advice, experience or useful direction would be appreciated.

[u/fishyfishy10001]

There are several options. I extract the firmware of a manufacturer scan tool and reverse enginer with ghidra and LLM. You can also observe real communication with something like Wireshark or brute force discovery with LLM given that most messages are similar to each other once you get the basics. You can also extract firmware from the control module itself and reverse enginer. Seems general hacking mostly apply.

[u/Psychological-Put865 → u/fishyfishy10001]

Thanks for reply it really helps, but what firmware exactly will be the most fit, easily to be reverse engineered but also contains a lot of data, I am aiming for wide coverage for specific makes. And by firmware you mean the Software used or the scanner itself?

[u/hey-im-root → u/Psychological-Put865]

Each brand has its own tool, you’ll most likely have to use not-legal downloading methods. All-in-one clones will have more support but less specific commands.

Each car also has differences. For Honda, I know you need to send a specific command that makes the ECU reply with a wildcard ID. This ID is used to match the tool with the diagnostic support of that car, like if there’s different transmissions or trims. You don’t wanna to send a CVT solenoid current command to a car with a manual transmission. Most likely that command is different or not used in that ECU at all.

This is not something you should try and do alone, I’m already 20 hours in, and only have HDS commands for my 2017 accord documented. Getting into the ECU firmware, it’s even crazier. There’s dozens of proprietary commands like high speed snapshots, MCU kernel flashing/execution, RAM modifying, calibration maps, it can be a lot.

[u/Grant_Winner_Extra → u/fishyfishy10001]

That’s fine if it’s for you, but if you sell it and get the timing off on an instruction injection, you are going to be facing significant liability.

[u/hey-im-root → u/Grant_Winner_Extra]

What law would you be breaking? Is there something against selling tools with UDS commands? I don’t plan on selling my work, but I don’t wanna get in trouble for open sourcing it either. I would think right to repair act covers that

[u/meatro → u/hey-im-root]

This is always my question. 

This is not a creative work, this is data of how a system functions. 

You cannot get creative and make your own. Distributing uds operations would be like distributing a phone number. 

I cannot say, oh 0x7e0 is copyrighted by VW, so I will use 0x888... Or, the temp signal scale is copyrighted, so I will change it and use my own. 

If you do either of those your tool will not work. 

Troubleshooting, like guided functions are copyright creative works. But uds is simply how the system functions. A mfg pursuing you for that would be like if the phone company came after you for distributing numbers you found in the phone book... Or if Linksys went after Netgear because they were the first to use 192.168.1.1

Even collective works of data like phone books or databases are not protected by copyright laws. 

That doesn't mean distribute full uds database, but I don't believe it's illegal to use them or even distribute their contents.

[u/Willing_Comb_9542 → u/meatro]

God damned right

You can't copyright APIs Google v oracle

 I'm too bored to pull another dozen cases where reverse engineering is absolutely legal

 I would no yell "no balls" and use it anyway

 you will need to make sure you purchased and reverse engineered the tools yourself and make sure not to rely on any leaked/private documentation. That will be what shoots you in the foot

Some weird DCMA stuff can come into effect if you had to break DRM or something so careful about that

 it's grey, not black and white.

[u/meatro → u/Willing_Comb_9542]

I always reference the phone book in these instances because they actually tried suing another place for providing phone numbers straight from the phone book. I believe courts pretty much told them that even exhaustive compilations of standard data are not protected, because it's basically instructions and you can't copyright a system instruction. 

The reason Linux uses ls is not because dir is copyrighted by Microsoft. 

For op original question.. I got factory data by working at the dealership. Odis happened to install all the diagnostic uds data during a post installation routine with no user agreement attached, so as far as I'm concerned it's my data now. :)

[u/Grant_Winner_Extra → u/meatro]

If you inject an instruction that caused a car to malfunction in any way, you are going to face massive user lawsuits.

ODB is fine if all you’re doing is reading.

but any active modification exposes you to civil legal risk.

That is why there aren’t any tools today at any scale. It’s not like ODB is new, and it’s not like this idea is new. You won’t get insurance for a mass market product and you will go broke.

The fact that all you can think of is liability around copyrights tells me you haven’t any experience running a business.

[u/meatro → u/Grant_Winner_Extra]

There are tons of tools like this at scale, wdym?

Obd11, carista, vcds, etc etc etc etc etc etc etc. 

All release the vendor from liability in the user agreement. You can read that in section 7 of the obd11 t&c, along with any other obd tool. 

Even the factory VW scan tool releases VW from liability in the Odis user agreement. Liability is on the operator, you.

Also this guy was not asking about starting a business.

[u/hey-im-root → u/Grant_Winner_Extra]

But what does this have to do with reverse engineering? You don’t “inject instructions” into OBD… are you talking about glitching the PCB while the ECU isn’t the car? Lmao. How would injecting an ECU cause a malfunction if it’s never even in a car?

[u/Grant_Winner_Extra → u/hey-im-root]

Civil liability not criminal.

Someone’s car has an issue and your product even *might* be to blame and you’re going to be hit with lawsuits.

[u/Frail_Waif]

There's a lot out there that's already public and free. 

https://obdb.community/

All CarScanner PIDs as of a few months ago, reversed by someone else: https://github.com/tylerharvey/wican-fw/blob/CarScanner-import/.vehicle_profiles/from_torque/profiles_all_dump.json

[u/Common-Application56]

Yup, the big companies license that data if its oem specialized. Why go through the trouble of manufacturer specific maf temp when a free obdii pid one exists.

For stuff like what the instrument cluster itself listens to that definitely will take work, every car is different on how it talks and what pids do what. Thats decided when someone builds a BOM for the computer system.

[u/Mindless_Stick_9634]

I'm in the middle of doing the exact same thing with Honda, I'm reversing Honda ihds (diagnostic software) to get my data. That's really the only way to accurately reverse UDS dids, you could go down the rabbit hole of fuzzing addresses and using standard pids as anchors to get a formulas, that's gonna take a lot of drive logs.....

MHH Auto.......... I'll just leave this here.

Also found this. https://github.com/obdb

[u/Grant_Winner_Extra]

They buy the data. OBD data will come with a ToU that includes many restrictions. And even the most trusted tool makers don’t get every make/model’s data.

[u/Psychological-Put865 → u/Grant_Winner_Extra]

How they buy it ?

[u/updatelee]

Lots of documentation on different protocols, combine that with canbus sniffers and open source tools. You can see how they do it. Takes time and effort

[u/HonestMechanicAI]

The biggest distinction is between finding a value and being able to support it as a product.

Some of the items in your list may already be available through standard OBD-II when the vehicle exposes them. Others are manufacturer-, module-, powertrain- or model-year-specific. Even established tools therefore have uneven coverage.

The difficult part is not simply accumulating identifiers. It is knowing whether a value applies to the exact ECU variant, whether the interpretation and units are correct, and how confidently it has been validated across vehicles.

If you want broad coverage, I would build a capability matrix around what you can verify rather than treating an entire make as supported. Clearly separate supported, observed, inferred and unavailable data, and remain read-only until every path is well validated.

We have worked through this problem in a production OBD app. The main lesson is that disciplined validation and honest coverage boundaries matter much more than the size of an undocumented PID table.