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
beyerch
Posts: 26
Joined: Sat May 22, 2010 8:36 am
cars: all kinds

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

Post by beyerch »

antus wrote:Yeah the planethax tool is over here https://pcmhacking.net/forums/view ... =401#p4515

It does brute force it, and the inbuilt timers in the pcm code slow it down significantly. On the plus side, it'll always get the key, whatever the algo is. But in this case the '0411 method seems to have been figured out.

The hard bit is going to be the code to upload to the pcm to provide read or flash functionality. Hard to write, hard to debug, and likely to make bricks. But possible.
Ifyou "bit bang" the PCM, it will lock after 3 invalid attempts for 10 minutes. I assume planethax's timer/delay was to avoid or account for this issue.

The number of incorrect bad keys as well as the lock-out timer delay are both configurable in the software, but of course you'd need to be able to reflash the pcm and know what/where to change.

HINT: A quicker brute force option would be to work in reverse. Take a tool that you know can do the seek / key calculation and hook it up to a fake pcm. Have the fake pcm give it a different seed so that you can see the key it calculates.

Using modern "record/replay macro" software, you could automate this process entirely. You could also lie to the tool about the type of vehicle so that you could capture data on other algorithms as well.

Of course if you already know the answers , this is all moot. :)
beyerch
Posts: 26
Joined: Sat May 22, 2010 8:36 am
cars: all kinds

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

Post by beyerch »

uknomeprk wrote:Bricking ($60 + for a new PCM) is a very REAL possibility without the right programming antus, I'd like to get your setup. I'll Pickup the stuff to socket my pcm in-case-of-brick if you don't mind sharing your setup.
Not sure if you still need a socketed board, but I have 5 or 6 of them collecting dust. Could also make one if you had a specific pcm type in mind.

FWIW
beyerch
Posts: 26
Joined: Sat May 22, 2010 8:36 am
cars: all kinds

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

Post by beyerch »

vn5000 wrote:Yeah,thats the sockets that ive got.Low profile.
I havent bricked my pcm yet,but ive got the sockets and flash chips ready for when i do. :comp: :D
Still not sure how to get them off and on but,hot air or a fine tip iron.
Soldering Iron (I use a Hakko 936) and soldering wick works just fine.

Heat Gun isn't a bad suggestion either, but you do need to take care to not loosen up other components as well.
beyerch
Posts: 26
Joined: Sat May 22, 2010 8:36 am
cars: all kinds

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

Post by beyerch »

uknomeprk wrote:
antus wrote:You dont need 4x to flash. It just takes 4x longer without it!
1. if we could devise a way that "takes 4x longer" to reprogram the PCM I'd be ok with that.
2. According to http://www.akmcables.com/obdii.htm <--(typo here caused the edit sorry) the people who made the cable for LS1edit a "flash" is not possible without 4X.

I think you might be thinking of "bit banging" which is a good choice if it can be assembled. 4X (from reading) seems to somehow (probably by A0, A1) send the 12v signal to the processor to accept CAN high speed. Either way I know for sure that dumping the bin will be easier than a FLASH or REPROGRAM. Definitely the cart before the horse here, but this still needs to be addressed.
The only differences in 4x mode are :

1) bit timings are ..... 1/4th the time as they are in "regular" mode. (i.e. if a 1 bit is 7V for 128 uS, in 4X it will be 32uS)
2) Bit True / False voltage transitions in non 4X are waveshaped. The waveshaping is disabled in 4x model due to timing changes.

There really isn't any magic here.

The other magic item is "block mode". In "normal" VPW communications, you transmit 12 bytes. In block mode, messages can be up to 4092 bytes of data + header. For block mode to be supported, you just keep reading bytes until they stop coming in. Not magic once again, other than the fact you need to have the buffer space to hold that much data.
beyerch
Posts: 26
Joined: Sat May 22, 2010 8:36 am
cars: all kinds

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

Post by beyerch »

CYRAX wrote:would it be possible to use mutiple chips (ex. a controller, the elm329 for commands, and a flashrom for storage)?
and what about a STN1110 instead of ELM http://www.obdsol.com/downloads/stn1110_vs_elm327.pdf

and from reading the mc68hc58 ic it states that "When operating in block mode, the DLC can transmit or receive message frames containing an unlimited number of data bytes."

so maybe design something based around the MC68HC58 VPW interface chip which supports 4x mode and block mode, just spitballing here since im not "Yet" as familar with the flashing procedure
MC68HC58 would be a good choice if you want to avoid some of the details; however, that chip is no longer in production. Additionally, you still have a bit of work to do even with that chip.
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 »

To keep it real, you are not talking about the boot loader, you are talking about the flash code which is uploaded to ram. the bootloader is in the bin, in the flash chips boot block. It is not normally overwritten, and so long as it in intact you can still recover the pcm. Its possible to brick it if you damage the bootloader, but all in all the flash process is pretty hardy to power or connection dropouts, even if you are overwriting the os.

You do not need to supply an algo number for the seed/key.

The STN1110 would be a good option, if they support large packets. They were talking about adding the feature, and if they do then we can give it a shot. Otherwise the interface ealyer in this thread here https://pcmhacking.net/forums/viewtopi ... =50#p19439 would do it, if anyone were to make up a batch.

Or there is the avt-852 http://www.avt-hq.com/products.htm#AVT-852 which would do it, do it very well, and support can bus, but its more expensive, and I know AVT-HQ will sell small batches of boards, but they are the only source and took them off the new for a couple of months a coupld of months ago, and we'd want to firm up future availability. They also state "Available as an OEM unit and to industrial and professional customers only. " They are more expensive than the other options, but would still be worth it for this purpose.
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
beyerch
Posts: 26
Joined: Sat May 22, 2010 8:36 am
cars: all kinds

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

Post by beyerch »

To keep it real, you are not talking about the boot loader, you are talking about the flash code which is uploaded to ram. the

bootloader is in the bin, in the flash chips boot block.
Yes/No.

In general microcontroller discussions, the bootloader in general is the piece of code that executes on startup. IT usually

initializes registers and kicks off whatever code is meant to run at start-up.

In certain areas of GM, bootloader is also used for discussions referring to the subroutines that perform the programming

operations.


The code that you send to the module during a reflashing (and reading) procedures includes support for the proper GM Diagnostic

messaging command (i.e. Mode 34/35) as well as the logic to read/write to the EPROM in most cases. While the messaging

specification and the controller has subroutines defined for the reading and writing modes, they are stub routines that do not

really do anything until you load your initial code.
It is not normally overwritten,
This is not entirely correct.

Many of the older PCM/ECU's have a 1 part binary file that is uploaded. Essentially you load everything over again, including

the boot block. This creates a critical window during the reflash routine. If anything happens while the boot block is erased

and before it is replaced, you will brick the PCM.

Additionally, some of the controllers have calibration / "OS" data residing in part of the boot block due to space limitations.

As the 28F400 is a block mode flash chip, you must erase the entire block before rewriting it, this scenario also creates a

critical window.

The more modern controllers have a requirement that you do not overwrite the startup area to ensure that you do not complete

incapacitate the ECU. But, it's just not the bootloader that can "brick" the PCM/ECU.
and so long as it in intact you can still recover the pcm.
Not entirely true.

In addition to the bootloader, the PCM and your reflash routine are also dependent on the VPW / GMLAN communications section of

the code. The code you upload for reflashion AND the bootloader do not have the capability to "talk" on their own. They are

linked to the VPW/GMLAN code on the controller. Even if the bootloader and your code is intact on the controller, if the

communications software is corrupted during your reflash, you *can* be in for some trouble.
Its possible to brick it if you damage the bootloader
It depends. If you damage the bootloader and do not reset the module, you can restart the flash process again. A failed

programming attempt may not be fatal if you restart the flashing sequence before restarting the module.

Additionally, keep in mind that most of the modules will fall into a "Recovery" model by default depending on what the exact

issue was. For instance, if the bootloader is able to restart the module, but it doesn't detect that the operating software is

right, it will fall into a default reprogramming mode. Mode 36 and other programming related command will work, while basic

ones will not (such as read block or request diagnostic information).

Because of this, certain software will say the module is 'dead' when it really isn't. The problem is that the software is

trying to go through the normal set of communication procedures and those will fail. I have unbricked a 'ton' of modules simply

by using a different set of instructions....

Even the 'bricked' modules are relatively easy to fix assuming you know what you're doing. All you have to do is pull the chip

and reflash it on a burner such as an EMP-20. You could also wire up the ICE and repair the flash software that way.

, but all in all the flash process is pretty hardy to power or connection dropouts, even if you are overwriting the os.
It really depends where in the process you are and power issues are the number fear. You should not start a programming event

if voltage is below 11.6V, IMHO. The ECU/PCM will shutdown just north of 11V in most cases. Be sure to turn off your

headlights and other crap when reprogramming as the LAST thing you want is the battery crapping out in the middle. Good

software will check system voltage before starting a flashing event. (at least mine does) :)
You do not need to supply an algo number for the seed/key.
Really?

Riddle me this.

You connect to a module and request the Seed and it gives you one. HOw do you know which of the 256 algorithms you use to

generate the proper key?

Sure you don't supply the algorithm as part of the mode 27 communications; however, *YOU* need to know it so that you don't have

to brute force 256 different algorithms for a given seed.

After looking at the "code" posted here, it looks like it is specific to the 411 PCM. The algorithms are generally the same for an entire "family" so the "411" code here may work quite universally, etc.

There's a way to know which algorithm you need. :)
The STN1110 would be a good option, if they support large packets. They were talking about adding the feature, and if they do

then we can give it a shot. Otherwise the interface ealyer in this thread here viewtopic.php?f=4&t=1566&start=50#p19439 would do

it, if anyone were to make up a batch.
I have an interface design and firmware; however, it needs a bit of work, though it will work out of the box....

What I don't have is time to put everything together to build (and maintain) a complete product.

Or there is the avt-852 http://www.avt-hq.com/products.htm#AVT-852 which would do it, do it very well, and support can bus, but

its more expensive, and I know AVT-HQ will sell small batches of boards, but they are the only source and took them off the new
I've sold thousands of AVT boards in the past and they do work. The problem is that they are too expensive.
vn5000
Posts: 551
Joined: Fri Jul 17, 2009 2:11 pm
cars: vn v8 commodore
Location: GOLD COAST QLD

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

Post by vn5000 »

Do you know how to read the section of ram that contains the values used when datalogging pids.
Do you use mode 35, if so can you read data at low speed using mode 35 or do you need 4x
Or do you use a 3c command
User avatar
VL400
Posts: 4991
Joined: Sun Mar 01, 2009 2:54 pm
cars: VL Calais and Toyota Landcruiser. Plus some toys :)
Location: Perth, WA
Contact:

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

Post by VL400 »

If you want to make a free (or like the way tunerpro is with donations) tool for flashing PCMs am keen for the hardware side of it :thumbup:

Developing a commercial product gets real messy trying to have multiple people involved the you want it to work and would be far far easier to make it a free or open source tool - it sounds like you just need all the pieces put together? I do know where you are coming from with the lack of monetary motivation for a free/open source tool though, but it does work if you can get the right people together :think:
User avatar
CYRAX
Posts: 9
Joined: Tue Dec 13, 2011 4:36 am
cars: 99TJ, 06F250
Location: USA

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

Post by CYRAX »

what about going to route like "NerdKits" used seen here http://www.nerdkits.com/videos/obdii/ and modify there there design and sourcecode for flashing?
Locked