Looking for EOBD Pids?

Printable View

Show 40 post(s) from this thread on one page

10-27-2009, 08:47 PM
RipplingHurst

I have my car's service manual...it's huge. Is the information you want there?
10-27-2009, 09:03 PM
chunkyks

Quote:

Depends, reverse engineering is quite often forbidden in T&C's

Not saying you should or couldn't do it

Check to see if they link against some LGPL libraries, which explicitly allow reverse engineering :-D

Gary (-;
10-27-2009, 11:28 PM
justchat_1

Quote:

Originally Posted by Enforcer

Depends, reverse engineering is quite often forbidden in T&C's

Not saying you should or couldn't do it, just advising you to make 100% sure what you are doing won't attract the attentions of some over zealous and overpaid corporate litigation lawyers

Funny I don't remember signing any terms and conditions when i bought my (used) car :peep:

All they can copyright is the documents which define each of the pids not the definitions themselves. If that were the case i'm copyrighting the numbers 234 and want $10k everytime you use them.

This is a tried and tested principal of reverse engineering for interoperability. The same grounds used in dozens of legal cases. Notice that Microsoft's proprietary and copyright file format .doc is supported by OpenOffice? Theres hundreds of such instances-as long as DRM, copy protection or encryption are not circumvented-its legal.

Again, this is a communications protocol not proprietary software.

I have service manuals for Ford, GM, Toyota (a little outdated but still useful) and Nissan....No PID definitions are included in any of these documents to ensure a nice revenue stream for the manufacturers.

All info is already available in the weekly database releases (OM svn server). I would advise RR and CF users to pay attention to the license terms.
10-27-2009, 11:48 PM
PPE

Quote:

Originally Posted by chunkyks

Check to see if they link against some LGPL libraries, which explicitly allow reverse engineering :-D

Gary (-;

Which LGPL libraries explicitly allow this? Even if the GPL (or LGPL) allows this (I haven't read it recently), if you use LGPL licensed code in library form, the (L)GPL does not apply to the software as a whole, but only to that specific library. Is that correct?

In any case, nearly every diagnostics tool I have seen includes a EULA which must be agreed to in order for you to install and/or use the scan tool. Most of these EULA's have provisions against reverse engineering. I am no lawyer, but it seems to me if you take some company's scan tool and reverse engineer it against the terms of the EULA you agreed to, and on top of that post the information publicly, they may have some claim against you.
10-27-2009, 11:57 PM
justchat_1

Quote:

Originally Posted by PPE

Which LGPL libraries explicitly allow this? Even if the GPL (or LGPL) allows this (I haven't read it recently), if you use LGPL licensed code in library form, the (L)GPL does not apply to the software as a whole, but only to that specific library. Is that correct?

Yes thats correct the LGPL allows this. GPL would require the entire program to be open source.

Quote:

Originally Posted by PPE

In any case, nearly every diagnostics tool I have seen includes a EULA which must be agreed to in order for you to install and/or use the scan tool. Most of these EULA's have provisions against reverse engineering. I am no lawyer, but it seems to me if you take some company's scan tool and reverse engineer it against the terms of the EULA you agreed to, and on top of that post the information publicly, they may have some claim against you.

Is every scan tool manufacturer going to pop in here for some propaganda? No one is talking about reverse engineering scan tool databases. That topic was never even mentioned until your post. My suggestion was to log PID's in test vehicles and reverse engineer what PID's correspond to what values via some good old logic.
10-28-2009, 12:53 AM
PPE

Quote:

Originally Posted by justchat_1

Is every scan tool manufacturer going to pop in here for some propaganda? No one is talking about reverse engineering scan tool databases. That topic was never even mentioned until your post. My suggestion was to log PID's in test vehicles and reverse engineer what PID's correspond to what values via some good old logic.

Um, isn't this topic about reverse engineering PIDs? For use in an open source scan tool? And weren't you and Vitaliy discussing scan tools earlier in this thread? I guess I don't understand how you are going to log PIDs in test vehicles.

Anyways, I'm not trying to stop you from doing perfectly legal activities. I merely had a question about the (L)GPL point that was brought up and wanted to point out EULAs and how they can affect reverse engineering.

I suggest you read this webpage: http://www.eff.org/issues/coders/rev...ngineering-faq

That page is a very good and thorough article on reverse engineering, how it's legal, how it's not etc. It doesn't seem to be biased towards or against reverse engineering, so it's very good (and interesting) read for anyone.
10-28-2009, 07:56 AM
justchat_1

Quote:

Originally Posted by PPE

Um, isn't this topic about reverse engineering PIDs? For use in an open source scan tool? And weren't you and Vitaliy discussing scan tools earlier in this thread? I guess I don't understand how you are going to log PIDs in test vehicles.

Anyways, I'm not trying to stop you from doing perfectly legal activities. I merely had a question about the (L)GPL point that was brought up and wanted to point out EULAs and how they can affect reverse engineering.

I thought I spelled it out pretty clearly-i'll try again. A PID is a series of bytes representing some value in an ECU. This series of bytes is accessible by anyone with only basic knowledge and requires no special software of special scantool (aka any scantool hardware can do it). A list of "supported PIDs" is easily accessible via well known and publicly documented methods. Scantool manufacturers have no say over what data you transmit unless you use their software or databases. The goal would be to log the "raw values" of each available PID on a system and then attempt to reverse engineer what the raw bytes mean. As i've now stated twice this in no way involves the use of any scan tool software, violation of any EULA's, breaking of any encryption or any other action that falls into any category other then fair use for interoperability.
10-28-2009, 09:52 AM
mezz64

Quote:

Originally Posted by justchat_1

I'm considering putting together a quick "EPID" dump program to see how many we could reverse engineer. Basically you start the program hit scan, then open a door press scan again...etc. And one at a time you identify a lot of the values. Other values could be guessed by running the engine and doing a 10 sec dump.

Figuring out what PID's are supported and retrieving the values are pretty easy-the tough part is figuring out what pids correspond to what values.

I have a few honda PID's from various forums but someone more active on honda forums could probably do better then me.

I'd be happy to help with this, just provide me with the program and some basic directions, although my Honda vehicle is from 1998, so its in the early days of OBD-II, I might not have as much functionality as someone with a later make.

Care to share what Honda PIDs you have currently found? I'm mostly interested in fuel information, such as gas tank level, etc.
10-28-2009, 10:16 AM
fchpj

unlock door PIDs

Hi,
I am looking for OBD PIDs which can unlock doors, any car will be helpful...

Thanks,
fchpj
10-28-2009, 11:00 AM
Enforcer

Quote:

Originally Posted by fchpj

Hi,
I am looking for OBD PIDs which can unlock doors, any car will be helpful...

Thanks,
fchpj

OBD does not control anything. It's just to monitor various settings and gauges.

You will need something like CANBUS to do doors etc.

Show 40 post(s) from this thread on one page