Open source GM OBD2 flash tool using a ELM327 device

They go by many names, P01, P59, VPW, '0411 etc. Also covering E38 and newer here.
Locked
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by antus »

Ive only played with the original development board http://www.obddiag.net/products.html and its ttl serial on the end. I would expect on the USB version its the same but with USB on the port your talking about.

You can get an idea whats needed from this post https://pcmhacking.net/forums/viewt ... =20#p83464

The 4x is just a hack to the timings, so the packet size applys to both. Ideally we'd want to implement a raw mode where you send a non-standard AT command and it starts talking something more like the AVT protocol, so that you dont need to reserve 3 bytes of ram for every byte of data, but the app is designed around elm protocol. The 180 char was just bumping buffer sizes up, Ive made no attempt to organize ram better. The NXP main IC has enough ram, so the platform would be capable of at least 1K packets, probably more. There is also the option of a complete re-write of the guts of the firmware. The open source LPXExpresso project is not too hard to get building (requires some mods to the project to build and checksum a firmware bin) and the code is modular and high quality so It wouldnt be too much work to do.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
NSFW
Posts: 679
Joined: Fri Feb 02, 2018 3:13 pm

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by NSFW »

Thanks for all of the info, I just ordered a couple. I'll stick with the stock firmware long enough to get some basic communication working, and then see about improving it. I'll read up on the AVT protocol in the meantime.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by Tazzi »

Just confirming that the couple vxdiag nano's I have here definitely work for VPW without any issues, have left one running for a good hour plus communicating to a LS1 ECU on the bench without a single frame miss. Also works for highspeed CAN.

Things that don't work (Yet says it supports) is GM UART (ALDL), but that has no effect on what your trying to achieve :)

The nanos also use an actual comport for communication, all other tools Iv seen have been a direct usb communication, or a network connection. So snooping on that communication line does make it easier to see what commands are sent for different tasks.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by antus »

32 bit windows with sudt accessport (eg in a win 7 vm) works well for usb devices which run in VCP mode (many of them, but not the proprietry ones and not J2534, for which there are other options).
There is a 64 bit version of sudt accessport, but only the older 32 bit version can handle large packets without truncating the data. I use v1.33, it looks like there was a major architectural change after 1.34 which is still available from the author http://www.sudt.com/en/ap/download.htm
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by Tazzi »

That would be perfect for it. Was thinking it would be good to snoop on some of the manager commands such as hardware test, reboot, restart ect. Good way to reset the device through software rather than physically disconnecting.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by Tazzi »

NSFW wrote:I've been working on some utilities to help with reverse engineering:

https://github.com/LegacyNsfw/PcmHacks

My hope is to extract GM's reflashing kernel from a recorded session, open it up in IDA, figure out how it works, write a new one in C, as post that on Github as well. If anyone has anything to contribute to such an effort, please let me know. Hopefully we'll have open-source software around the same time people like Thaniel get the hardware stuff figured out. :)

Has anyone figured out the seed/key algorithm yet?
Or the checksum algorithm?
Just downloaded and went over whats there so far, and the base framework is looking pretty tidy!

I did a quick throw together last night and chucked in some J2534 coding under the J2534port class to find the installed devices and connect on up. Also added in basic coding to read VIN from LS1 ECU under the vehicle class where I saw the query VIN function.

Is J2534 something you wanna start with??
Happy to commit my changes to github so you can have examples of read/write for the VPW protocol?

Above was with the vxdiag nano. :thumbup:
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
NSFW
Posts: 679
Joined: Fri Feb 02, 2018 3:13 pm

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by NSFW »

The only J2534 device I own is a Tactrix OpenPort 2.0, which doesn't support VPW. I just added the J2534 classes in hopes that something would come along eventually... and look what happened!

What's your account name on GitHub? I'll add you to the project.

Antus and I have been PMing back and forth about the code quite a bit, but now that there are three of us, we should just move that discussion into the forum. If you have any questions or feedback about the code, I'm listening.

Below are some PMs that I sent Antus earlier, that might be useful to you or anyone else who wants to pitch in.
...on second thought, the J2534Port class probably should have been called TactrixPort (it would just know how to determine whether the Tactrix device is present) and a J2534Device class would be able to operate on any manufacturer's Port class. And the IPort interface would [edit: maybe?] need a few more methods to really support J2534 stuff. But the only J2534 device I own is a Tactrix, which doesn't support VPW.
I pushed up an update to the app on Monday, and I'm pretty happy with the design at this point. I think all of the basic plumbing is in place now. You can pick the "mock port" and "mock device" and it pretends to ask the PCM for the VIN and OS info. I still don't have a PCM set up on my desk yet, but there's a mock PCM in the app that returns fake data that gets displayed in the UI.

https://github.com/LegacyNsfw/PcmHacks

The QueryVin and QueryOperatingSystemId methods are in a class called Vehicle, so usage looks like "vinResponse = await this.vehicle.QueryVin();" You can step through that to see how everything works.

The Interface classes were renamed to Device because I kept wanting to declare variables named "interface" which of course is a reserved keyword in C# and that really confused the compiler. Those classes are also a lot simpler now, they just have two interesting methods:

SendMessage - send a message to the PCM and don't bother waiting for a response.
SendRequest - send a message to the PCM, read a response, and return the response.

If you need more control over the way the serial port is opened, feel free to add more properties to the SerialPortConfiguration class. See the ScanToolDevice class for an example of how that works. Or how I think that should work, anyway... I might learn something when we start using the app with actual PCMs. :)

There's a MessageFactory class that should know how to create each type of message we send to the PCM, and a MessageParser class that should know how to parse each type of message that comes from the PCM. So far they know how to create VIN and OS ID queries, and parse the responses. Or, like I said, I think they know how...

I also kind of like the idea of replacing the MessageFactory/MessageParser with a separate class for each message type, e.g. a VinQuery class would know how to create the VIN request and parse the VIN response, OsIdQuery would do the same for operating system ID, and so on... Not sure which approach would be better. If this turns out to be awkward, it shouldn't be too hard to try classes for each message type later.

There's also a Response<T> class that might need some explanation... The idea there was to have an object that generally contains the data we expected to get back from the PCM, but it also has a Status property that can indicate that something went wrong and we didn't actually get usable data back. So the code that sends a request gets a Response back, checks the Status property, and uses the Value property if States == Success. It's a generic class, so the lower layers deal with Response<byte[]> and the upper layers use Response<string> for the VIN and Response<UInt32> for the OS ID. The unlock operation could return Response<bool>, reading the PCM could use Response<Stream> and so on.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
User avatar
NSFW
Posts: 679
Joined: Fri Feb 02, 2018 3:13 pm

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by NSFW »

I should also add that I've learned a few things since I made the post that Tazzi just quoted, and reverse-engineering GM's stuff probably won't be necessary after all. Or rather, it has already been done... Antus and Dimented24x7 were already much, much farther along than I realized. Dimented is apparently offline for a while, but Antus has his stuff, and has permission to use it. Things are coming together!
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
pgbpro2.0@gmail.com
Posts: 6
Joined: Thu Mar 08, 2018 4:07 pm
cars: 2005 Cadillac CTS-V
2005 Mercedes Benz SLK350

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by pgbpro2.0@gmail.com »

I'm a little late to this game. I'd like to help with the project.

From what I gather ya'll have moved on to communicating to the ECU via J2534 which (as a protocol) supports passthrough J1850 w/ 4x VPW for reprogramming. But then I'm confused because NSFW says his Tactix Openport 2.0 does not support VPW (..do you mean - only supports it through J2534 passthrough and not directly?).

Basic background reading on these protocols has revealed to me that J2534 https://www.boschdiagnostics.com/pro/j2534-faqs is a 'general purpose' API that allows independent aftermarket (and us, I guess) the ability to reprogram ECU's. It was mandatory 2004 onward for N. America - which may be problematic for a minority of potential future users depending on when GM actually adopted the protocol. Another issue I can see straightaway from the docs https://tunertools.com/prodimages/DrewT ... _API-1.pdf here is

"This arrangement allows the vehicle manufactures to restrict access to proprietary reprogramming algorithms". Does anyone know the details of how Tech2Win reprograms through the 'front' door? It could be that simple mode 3B writes are somehow restricted through the J2534 passthrough API without some additional authentication and this is obvious to all ya'll but not me. Forgive me - I just learned that these protocols existed today :D

The only interface I can confirm as having J1850 VPW but not necessarily with passthrough J2534 is the now famous AVT-852. But it could be problematic that this cable is only "Available as an OEM unit and to industrial and professional customers only."

Anyway I'd like to help, what does this group think is it's best shot at a success hardware-wise? Have you already identified a problem using J2534 for our reprogramming purposes? I'd love for the answer to be any fully compliant J2534-1 device like presumably both the Tactix Openport 2.0 and the VXDiag VCX Nano but I'm guessing I'm pipe dreaming.
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: Open source GM OBD2 flash tool using a ELM327 device

Post by antus »

J2534 does not define the reprogramming, thats higher up the protocol stack and proprietry, but we've taken from the pool of public knowledge (thanks to everyone whos figured anything and released it so far... beerman comes to mind from the early days for vpw protocol work, but many others too). Now we'll take it too the next level. I'll be implementing avt and allpro up front, nsfw has some other devices in mind... but it'll take time. Allpro should work with my firmware now... but larger packets on that interface are part of the plan.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
Locked