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: 8250
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 »

Tazzi wrote:Looking at VPW specifically.. 4x is not required at all. Its a silly mis-conception there. Flashing can be done at 1x VPW speed which some tuning tools allow selecting. And flashing can be done with smaller chunk sizes. The faster speeds and larger chunks is all done to speed up the flashing process.
Exactly right. 1x is pretty damn slow, and the turnaround per packet is too.
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
160plus
Posts: 90
Joined: Thu Sep 21, 2017 3:00 pm

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

Post by 160plus »

antus wrote:@160plus That send you posted IS the code being sent. Some PCMs, such as (I believe but may be wrong) the bosch types have the flash ability built in so you only need to talk the protocol and send the data to write. But the delco/delphi flash PCMs have the ability to change some things, but not the ability to do the flash. So you have to unlock the PCM then upload extra code.

For example, I'll put some of my code here:

Code: Select all

| GM '0411 Read code - (c) 2014 Antus / pcmhacking.net
| Processor:	    68330
| Target Assembler: 680x0 Assembler by GNU project
| ===========================================================================

.equ J1850_Config, 0xFFF600
.equ J1850_Command, 0xFFF60C
.equ J1850_TX_FIFO, 0xFFF60D
.equ J1850_Status, 0xFFF60E
.equ J1850_RX_FIFO, 0xFFF60F
.equ toolid, 0xF0

start:
    bsr.w   WasteTime			
    move.b  #3,	(J1850_Command).l	| Flush	frame except for completion code
    move.b  #0,	(J1850_TX_FIFO).l	| Load dummy byte to initiate transfer - needed

wait01:
    bsr.w   ResetWatchdog			| Branch to Subroutine
    bsr.w   WasteTime				| rate limit rx	loop
    move.b  (J1850_Status).l, %d0		| get the vpw status
    andi.b  #0xE0, %d0				| Mask Receive FIFO Status Field (RFS) register	1110 0000
    cmpi.b  #0xE0, %d0				| Check	for "completion code only, at head of buffer" message 1110 0000
    bne.s   wait01					| not ready? wait and retry
    move.b  (J1850_RX_FIFO).l, %d0		| strip	off the	completion code
    bsr.w   LongWaitWithWatchdog		| Branch to Subroutine - needed

MainLoop:
    bsr.w   J1850_ReadPacket				| wait for and read next frame
    cmpi.b  #0x35, (InputMode).l			| Is it a mode 0x35 (Tool asking PCM to send data)
    beq.w   processmode35				| process it
    cmpi.b  #0x20, (InputMode).l 		 	| Is it a mode 0x20? (return to normal comms)
    bne.w   MainLoop					| No more options, next packet
    movea.l #VPWMode60Msg, %a0			| Reply to a mode 20 with a mode 60 (+40)
    move.l  #3, %d0					| Message Length
    bsr.w  WriteVPW_a0_buffer_d0_length		| Send normal comms message
    bsr.w Stop						| Reboot PCM
Then together with the build tools you end up with the program to send to the pcm in hex

Code: Select all

[root@gemini readcode-1.3]# ls -l
total 4000
-rw-rw-rw-. 1 nobody nobody     88 Mar 19  2013 link.lds
-rwxrwxrwx. 1 nobody nobody 540728 Mar 19  2013 m68k-elf-as
-rw-rw-rw-. 1 nobody nobody 973838 Mar 19  2013 m68k-elf-as.exe
-rwxrwxrwx. 1 nobody nobody   4637 Mar 19  2013 m68k-elf-ld
-rw-rw-rw-. 1 nobody nobody 946190 Mar 19  2013 m68k-elf-ld.exe
-rwxrwxrwx. 1 nobody nobody 403196 Mar 19  2013 m68k-elf-ld.real
-rw-rw-rw-. 1 nobody nobody 961038 Mar 19  2013 m68k-elf-objdump.exe
-rw-rw-rw-. 1 nobody nobody 205838 Mar 19  2013 make.exe
-rw-rw-rw-. 1 nobody nobody    298 Sep 23 06:36 makefile
-rw-rw-rw-. 1 nobody nobody    897 Mar 19  2013 makeheader
-rw-rw-rw-. 1 nobody nobody  11840 Mar 19  2013 readcode.asm
-rwxr-xr-x. 1 nobody nobody    789 Sep 23 06:37 readcode.bin
-rw-r--r--. 1 nobody nobody   4848 Sep 23 06:37 readcode.h
-rw-r--r--. 1 nobody nobody   2948 Sep 23 06:37 readcode.o
[root@gemini readcode-1.3]# make clean
rm *.bin *.o *.h
[root@gemini readcode-1.3]# make
./m68k-elf-as  readcode.asm -o readcode.o
./m68k-elf-ld -m m68kelf --oformat binary -T link.lds readcode.o -o readcode.bin
perl makeheader readcode.bin readcode.h
size: 789
hexsize: 0x03, 0x15
sum: 0DD5
[root@gemini readcode-1.3]# hexdump readcode.bin | head
  Address  | 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F | 0123456789ABCDEF
-----------+-------------------------------------------------+-----------------
0x00000000 | 61 00 00 98 13 FC 00 03 00 FF F6 0C 13 FC 00 00 | a...............
0x00000010 | 00 FF F6 0D 61 00 02 B4 61 00 00 80 10 39 00 FF | ....a...a....9..
0x00000020 | F6 0E 02 00 00 E0 0C 00 00 E0 66 E8 10 39 00 FF | ..........f..9..
0x00000030 | F6 0F 61 00 00 2E 61 00 02 16 0C 39 00 35 00 FF | ..a...a....9.5..
0x00000040 | 94 43 67 00 00 78 0C 39 00 20 00 FF 94 43 66 00 | .Cg..x.9. ...Cf.
0x00000050 | FF E6 20 7C 00 FF 94 51 70 03 61 00 00 9E 61 00 | .. |...Qp.a...a.
0x00000060 | 00 44 2A 3C 00 00 27 10 61 00 02 60 61 00 00 2C | .D*<..'.a..`a..,
0x00000070 | 61 00 00 28 61 00 00 24 61 00 00 20 61 00 00 1C | a..(a..$a.. a...
<snip>
I'm joking as I say this so don't take it personal...

Get with the times man.... in American we speak English and I don't care if I can speak hex or not. Some times an answer is so obvious it's been starting you in the face all along. The 1st thing you need to do is chuck that laptop out the window and get your self a smart phone. Laptops have shit for battery life, only slightly larger screens that a phablet and laptops are clumsy compared to a modern smart phone. Next is ditch that USB cable....it's 2017 ain't nobody got time for cords. Last but not least is why are we still using formats that are hard to decipher.

If I had a bin file that looked was full of "F6 0F 61 00 00 2E 61 00 02 16 0C 39 00 35 00 FF" I could work with that but instead it's "ÈFÃË‹Átí #ª6˜²"wÇ9Ê´ÀÄ:0t’[¯E [?ãNÈ1~ÝëÝp" and that makes my head hurt. Here's an example of what MY code looks like......I mean blocks..... I'm not typing my code I'm building it.
https://imgur.com/a/XknvM



The only reason I have to deal with any hex in my program is to decode the vin number so it's readable and you can change it just by typing in a new one and it's messy but it's the best method I've found so far.
https://imgur.com/a/qLWmw

And so it's readable........
https://imgur.com/a/SUVQ6


Right now I have read vin and write vin working as well as writing the pcm flash chip serial number mostly working. I haven't tried to figure out how to handle the seed/key to make for a dummy prof serial number write so for now I just have a text box to enter it into like I do for changing the vin number. I guess it would also be a way to stop any one from messing with this since the odds of guessing the seed/key randomly would be almost impossible.
Last edited by 160plus on Sat Oct 21, 2017 12:05 pm, edited 1 time in total.
160plus
Posts: 90
Joined: Thu Sep 21, 2017 3:00 pm

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

Post by 160plus »

Tazzi wrote:
160plus wrote:The OBDLink stn11xx family of chips has come a long ways. They currently have firmware (by request only) that allows up to 3.5kb to be sent in a single hit, it also supports continuous write with no packet size limit since it's transmitting in real-time as a continuous packet until you line break.

The hardware is capable of supporting the 4x mode however it is not implemented in the firmware and that's where it would require someone that knows this stuff inside and out to get working......but it IS capable of it.
The problem with ELM based scantools.. is their actual protocol is too limited.

For example. ELM based tools such as the OBDlink allow for sending one message to the car, and then receiving one message back.
The flaw with that design, is sometimes you actually need to get multiple responses back from the car. This occurs often when flash updating most modules in GM vehicles, since once you send a chunk of code for flashing, the ECU tends to respond with a "Please wait, Im slow and taking a while to process" message, it will continue to send that same 'message' until it has finished processing and then sends another message saying "Im finished and ready for the next chunk".

Not all ECUs do the above.. but it does occur alot (Maybe more so with CAN based modules.. not VPW).

Looking at VPW specifically.. 4x is not required at all. Its a silly mis-conception there. Flashing can be done at 1x VPW speed which some tuning tools allow selecting. And flashing can be done with smaller chunk sizes. The faster speeds and larger chunks is all done to speed up the flashing process.
The STN chips only emulate the Elm for simplicity of commands...they have a hole different set of commands you can also use that go way beyond what the Elms use. Here's a breakdown of the stn chip from product literature I received from them.

https://imgur.com/a/LIikU
User avatar
antus
Site Admin
Posts: 8250
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 »

160plus wrote:Last but not least is why are we still using formats that are hard to decipher.
Do we have a choice? Do you have a different way to write and output m68k code the pcm can run? PC side code is different, there are many options there.
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
160plus
Posts: 90
Joined: Thu Sep 21, 2017 3:00 pm

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

Post by 160plus »

antus wrote:
Tazzi wrote:Looking at VPW specifically.. 4x is not required at all. Its a silly mis-conception there. Flashing can be done at 1x VPW speed which some tuning tools allow selecting. And flashing can be done with smaller chunk sizes. The faster speeds and larger chunks is all done to speed up the flashing process.
Exactly right. 1x is pretty damn slow, and the turnaround per packet is too.
From memory I was writing 128 byte blocks to calibration modules when I first started developing *********** , the calibration modules can be written using small byte blocks ..............minimum block size to write os is approx. 2000 bytes
Part of an email from someone thats already done this but not as an opensource project or with commercially built hardware.

Speaking 1st hand since I have the tool that can flash at 1x speed with 2kb block sizes it's not as slow as you'd think on the 512K pcm. Using speed as a metric to justify something is silly....in 2001 when the 0411 was brand new how fast was the average internet connection? How about desktop cpu speed and the amount of ram? Even the fastest computer in the world in 2001 would be a dinosaur in comparison to modern computers. I remember getting an isdn connection back then and couldn't believe how much faster it was then my normal phone line. Today if my phones less then 10Mbps download I'm trying to figure out whats going on with my service because it's taking forever. I think it's fitting that we still have 2G phone service even though it's no faster then my isdn line was back in 2001......no one will argue that 2G service sucks but even though it's slow as crap it still better then nothing when your lost out in the middle of no where.
160plus
Posts: 90
Joined: Thu Sep 21, 2017 3:00 pm

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

Post by 160plus »

antus wrote:
160plus wrote:Last but not least is why are we still using formats that are hard to decipher.
Do we have a choice? Do you have a different way to write and output m68k code the pcm can run? PC side code is different, there are many options there.
If this...............
FÃË‹Átí #ª6˜²"wÇ9Ê´ÀÄ:0t’[¯E [?ãNÈ1~ÝëÝpiM âPi°áàr1/C4^ÑãšÄC‰,º¯_¬¼R&œ+•HùÂdß\â­CB•›w°P¯ƒñV‡êä°Á¶î™¢ñ*ƒh"|xš0øÒúŒgVÎ5õ—iá´y®$4õ•šóV"e®Ë¤9ÑB™ÿAëðï)jÝíßT(Æy’>vwãªé¤¶Ø«ívƒ(¤SL¾þ‚qWè¸UîDXÂûË¿Qì‰w‚ä4Sñ^ ‰ÿ0ŒFº"мß\ûgsldŽYÒdL¼uHûÃÿ¢íÝ‚¨ªc9>(hVDÛˆ5Ž´{Îîªí–AÖâÍ7Ûtø
Looked like this................
6D 10 F0 36 00 02 00 FF 88 00 32 80 61 00 02 A8 34 11 B4 40 67 0A 57 CC FF F4 34 11 B4 40 66 12
D2 FC 00 02 55 43 66 94 08 87 00 06 08 87 00 07 60 0A 08 C7 00 06 60 04 08 C7 00 07 32 BC F0 F0
32 BC F0 F0 4A 07 66 00 00 BE 4E 75 3A 38 E2 FA 08 C5 00 00 31 C5 E2 FA 3A 3C F9 00 61 00 02 70
3A 38 E1 12 08 05 00 08 66 32 08 C7 00 03 08 87 00 04 60 30 3A 38 E2 FA 08 85 00 00 31 C5 E2 FA
3A 3C F2 00 61 00 02 48 3A 38 E1 12 08 05 00 08 67 0A 08 C7 00 04 08 87 00 03 60 08 08 87 00 03
08 87 00 04 4E 75 42 78 F2 08 42 78 F2 00 31 FC 80 6A F2 0A 31 FC 01 00 F2 0C 31 FC 00 01 F2 0E
31 FC 00 06 F2 30 42 78 F2 10 08 F8 00 05 F2 0C 3A 3C FF 90 61 00 01 F8 08 38 00 07 F2 10 66 04
42 40 60 0A 08 B8 00 07 F2 10 30 38 F2 B0 0C 40 01 99 65 06 0C 40 02 67 63 06 08 C7 00 00 60 04
08 87 00 00 4E 75 08 07 00 00 67 06 10 3C 00 83 60 58 08 07 00 01 67 06 10 3C 00 84 60 4C 08 07
00 02 67 06 10 3C 00 85 60 40 08 07 00 03 67 06 10 3C 00 87 60 34 08 07 00 04 67 06 10 3C 00 88
60 28 08 07 00 05 67 06 10 3C 00 89 60 1C 08 07 00 06 67 06 10 3C 00 F8 60 10 08 07 00 07 67 06
10 3C 00 74 60 04 10 3C 00 AA 11 C0 81 D2 61 06 4E F9 00 FF 82 64 11 FC 00 76 81 D0 42 38 81 D1
11 C0 81 D2 12 3C 00 03 61 56 4E 75 11 FC 00 14 F6 0C 10 3C 00 8C 61 00 00 8A 10 3C 00 FE 61 00
00 7C 10 3C 00 F0 61 00 00 74 11 FC 00 0C F6 0C 10 3C 00 3F 61 6C 61 00 00 96 11 FC 00 14 F6 0C
10 3C 00 6C 61 5C 10 3C 00 FE 61 50 10 3C 00 F1 61 4A 11 FC 00 0C F6 0C 10 3C 00 3F 61 44 4E 75
11 FC 00 14 F6 0C 10 38 81 FA 61 36 10 38 81 F9 61 2A 10 3C 00 10 61 24 61 02 4E 75 22 7C 00 FF
81 D0 10 19 61 16 04 01 00 01 94 DB 76
6D F0 10 76 00 73 42
6C FE F0 3F C7
8C FE F0 3F 2C
Then why couldn't the pcm read it?

I was able to send somewhere around 100 lines of code using just over 40 macros and all i was sending were headers and 2 bit blocks like I posted above. I was recording a log while I was sending the commands with the macros and line for line every thing that I sent received the same response back I was expecting to see. The lines I was sending were exactly the way I had previously read them from other programs. I used 3 different bin files all with different OS's on them and compared the logs to find what changed and what remained the same. Using that method I was able to figure out the headers and what i think would have been the checksum for each line I was sending. It wasn't like sit down, make some macros and run them it was hours and hours looking for patters in the method it was writing and then comparing logs from one tool to another tool looking for patterns again to see if I had the write information.

What I was able to also figure out is the pcm's response was different based on the size of the packet being sent but that the same information was being sent just in a packet further down the list when it was sending smaller packets. This alone reinforced my thoughts that the commands to send each line of "code" are the same across multiple flashing devices and that the "Code" depending more on the bin file being used then what tool was being used.


My point is sending 60 00 FF 0C 42 82 42 83........ can do the same thing as 0x00000 0x0002032 or how ever it's formatted. Since we are also only talking about 1 specific type of pcm and there are only going to be a couple of different OS's that might change the formatting why couldn't a bin converted to work this way? The calibration for the pcm is what... something like 92kb?
160plus
Posts: 90
Joined: Thu Sep 21, 2017 3:00 pm

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

Post by 160plus »

Tazzi wrote:The letter/number pairs your seeing is called Hexadecimal.
A single byte can be a value between 0 to 255, which in hexadecimal is 00 to FF.

The J2534 protocol and J2534 compliant devices are just tools in the scheme of things, they are useless without designing an application (Or macros) to perform actions. Now, its these actions which tend to need some custom work.. which is where the IP code comes into play.

The IP people refer to in GM vehicles for tuning is called the bootloader. The bootloader is custom code that runs on the ECU and allows reading or writing to the flash.. ie.. tuning.
Not all GM modules require one, some have them have a bootloader inbuilt into them, but most of them do require a custom bootloader made up.

This bootloader is custom built by tuning companies. I do believe alot of the tuning companies essentially just copy each other by decompiling the code.. seeing what it does.. and basing their own from that.

Anyways.. back on target... looking at the lines you sent.. what I see is the following:

AT SH 6C FE F0 -Set VPW header.. FE target (Global ID).. F0 sender (Scantool)

Send: 28 00 - Send mode 28 (Tell everything on the comms line to shutup)

AT SH 6C 10 F0 -Set VPW header.. 10 target (ECU).. F0 sender (Scantool)

Send: 27 01 - Send mode 27 (Security), sub function 1 (Request Seed)

AT SH 6C 10 F0 -Set VPW header.. 10 target (ECU).. F0 sender (Scantool)

Send: 27 02 C7 ED - Send mode 27 (Security), sub function 2 (Send key), C7 ED (Key)

AT SH 6C 10 F0 -Set VPW header.. 10 target (ECU).. F0 sender (Scantool)

Send: 34 00 00 0C FF 80 00 -Send mode 34, prepare memory and load at address.

Then the next chunk would be part of the bootloader.
6C F0 10 7F 3C 22 12 89
6C 10 F0 3C 01 8A
6C F0 10 7C 01 00 31 47 41 48 47 18
8A EA 10 B1 01 10 11 14 02 00 89
A8 49 10 01 00 44
8A EB 10 B2 01 11 20 45 46 49 4C CE
8A EB 10 32 01 11 49 56 45 20 46 79
A8 49 10 01 00 44
8A EB 10 B2 01 11 4C 41 53 48 53 B7
8A EB 10 32 01 11 43 41 4E 20 04 A2
8A EA 10 B1 01 10 12 14 02 00 33
A8 49 10 01 00 44
8A EB 10 B2 01 12 20 46 4C 41 53 9D
A8 49 10 01 00 44
8A EB 10 32 01 12 48 20 49 4E 20 EB
8A EB 10 B2 01 12 50 52 4F 47 52 62
8A EB 10 32 01 12 45 53 53 20 04 96
A8 49 10 01 00 44
8A EA 10 B1 01 10 13 14 02 00 AE
A8 49 10 01 00 44
8A EB 10 B2 01 13 20 20 77 77 77 43
8A EB 10 32 01 13 2E 65 66 69 6C 60
8A EB 10 B2 01 13 69 76 65 2E 63 F3
A8 49 10 01 00 44
8A EB 10 32 01 13 6F 6D 20 20 04 EC
6C 10 F0 27 01 B0
6C F0 10 67 01 54 45 8E
A8 49 10 01 00 44
6C 10 F0 27 02 4D F9 61
6C F0 10 67 02 34 4B
6C FE F0 28 00 10
6C F0 10 68 00 9F
6C FE F0 3F C7
8C FE F0 3F 2C
6C FE F0 28 00 10
6C F0 10 68 00 9F
6C FE F0 3F C7
8C FE F0 3F 2C
6C 10 F0 34 00 08 DC FF 82 00 7A
6C F0 10 74 00 44 1E
6D 10 F0 36 00 00 DC FF 8A 00 0C 01 00 01 66 F2 11 FC 00 0C F6 0C 10 11 61 08 4E 75 11 FC 00 04
F6 0C 11 C0 F6 0D 3A 3C 10 00 61 00 00 8A 04 45 00 01 4A 45 67 12 42 80 10 38 F6 0E 02 00 00 03
0C 00 00 03 67 E4 4E 75 4E F9 00 FF 82 46 42 80 61 64 52 00 0C 00 00 03 66 F6 4E 75 42 81 20 7C
00 09 C0 00 22 7C 00 0B 00 00 4A 01 66 02 61 46 06 01 00 01 20 18 0C 80 57 30 35 50 67 16 0C 80
57 30 36 50 67 0E 0C 80 57 30 37 50 67 06 B3 C8 66 D8 60 10 20 10 0C 80 48 54 20 20 66 CC 11 FC
00 AA 81 FB 4E 75 20 28 63 29 32 30 30 35 20 45 46 49 4C 49 56 45 08 78 00 07 D0 06 11 FC 00 55
FA 27 11 FC 00 AA FA 27 4E 75 3A 3C B0 00 61 E6 06 45 00 01 0C 45 FF FF 66 F4 4E 75 4C 53 31 42
5F 76 31 2E 37 43 42 BF 42
6D F0 10 76 00 73 42
6C FE F0 3F C7
8C FE F0 3F 2C
6D 10 F0 36 00 02 00 FF 88 00 32 80 61 00 02 A8 34 11 B4 40 67 0A 57 CC FF F4 34 11 B4 40 66 12
D2 FC 00 02 55 43 66 94 08 87 00 06 08 87 00 07 60 0A 08 C7 00 06 60 04 08 C7 00 07 32 BC F0 F0
32 BC F0 F0 4A 07 66 00 00 BE 4E 75 3A 38 E2 FA 08 C5 00 00 31 C5 E2 FA 3A 3C F9 00 61 00 02 70
3A 38 E1 12 08 05 00 08 66 32 08 C7 00 03 08 87 00 04 60 30 3A 38 E2 FA 08 85 00 00 31 C5 E2 FA
3A 3C F2 00 61 00 02 48 3A 38 E1 12 08 05 00 08 67 0A 08 C7 00 04 08 87 00 03 60 08 08 87 00 03
08 87 00 04 4E 75 42 78 F2 08 42 78 F2 00 31 FC 80 6A F2 0A 31 FC 01 00 F2 0C 31 FC 00 01 F2 0E
31 FC 00 06 F2 30 42 78 F2 10 08 F8 00 05 F2 0C 3A 3C FF 90 61 00 01 F8 08 38 00 07 F2 10 66 04
42 40 60 0A 08 B8 00 07 F2 10 30 38 F2 B0 0C 40 01 99 65 06 0C 40 02 67 63 06 08 C7 00 00 60 04
08 87 00 00 4E 75 08 07 00 00 67 06 10 3C 00 83 60 58 08 07 00 01 67 06 10 3C 00 84 60 4C 08 07
00 02 67 06 10 3C 00 85 60 40 08 07 00 03 67 06 10 3C 00 87 60 34 08 07 00 04 67 06 10 3C 00 88
60 28 08 07 00 05 67 06 10 3C 00 89 60 1C 08 07 00 06 67 06 10 3C 00 F8 60 10 08 07 00 07 67 06
10 3C 00 74 60 04 10 3C 00 AA 11 C0 81 D2 61 06 4E F9 00 FF 82 64 11 FC 00 76 81 D0 42 38 81 D1
11 C0 81 D2 12 3C 00 03 61 56 4E 75 11 FC 00 14 F6 0C 10 3C 00 8C 61 00 00 8A 10 3C 00 FE 61 00
00 7C 10 3C 00 F0 61 00 00 74 11 FC 00 0C F6 0C 10 3C 00 3F 61 6C 61 00 00 96 11 FC 00 14 F6 0C
10 3C 00 6C 61 5C 10 3C 00 FE 61 50 10 3C 00 F1 61 4A 11 FC 00 0C F6 0C 10 3C 00 3F 61 44 4E 75
11 FC 00 14 F6 0C 10 38 81 FA 61 36 10 38 81 F9 61 2A 10 3C 00 10 61 24 61 02 4E 75 22 7C 00 FF
81 D0 10 19 61 16 04 01 00 01 94 DB 76
6D F0 10 76 00 73 42
6C FE F0 3F C7
8C FE F0 3F 2C
6C 10 F0 34 00 08 DC FF 82 00 7A
6C F0 10 74 00 44 1E
6D 10 F0 36 00 00 DC FF 8A 00 0C 01 00 01 66 F2 11 FC 00 0C F6 0C 10 11 61 08 4E 75 11 FC 00 04
F6 0C 11 C0 F6 0D 3A 3C 10 00 61 00 00 8A 04 45 00 01 4A 45 67 12 42 80 10 38 F6 0E 02 00 00 03
0C 00 00 03 67 E4 4E 75 4E F9 00 FF 82 46 42 80 61 64 52 00 0C 00 00 03 66 F6 4E 75 42 81 20 7C
00 09 C0 00 22 7C 00 0B 00 00 4A 01 66 02 61 46 06 01 00 01 20 18 0C 80 57 30 35 50 67 16 0C 80
57 30 36 50 67 0E 0C 80 57 30 37 50 67 06 B3 C8 66 D8 60 10 20 10 0C 80 48 54 20 20 66 CC 11 FC
00 AA 81 FB 4E 75 20 28 63 29 32 30 30 35 20 45 46 49 4C 49 56 45 08 78 00 07 D0 06 11 FC 00 55
FA 27 11 FC 00 AA FA 27 4E 75 3A 3C B0 00 61 E6 06 45 00 01 0C 45 FF FF 66 F4 4E 75 4C 53 31 42
5F 76 31 2E 37 43 42 BF 42
6D F0 10 76 00 73 42
6C FE F0 3F C7
8C FE F0 3F 2C

Same file 2 tools that are TOTALLY different



Now on the boot loader comment, I know very little about this from a formal education standpoint and what I know is based on what I have read by others when it comes to pcm 's and I have an issue believing something like that based on what I know about boot loaders and exploits to gain access to boot loaders on things like cell phones. Unlocked vs rooted vs tethered jail break vs full jail break in the world of cell phones is no different and far more expensive then working with a pcm. After bricking my fair share of phone over the years I feel I have above average knowledge on things like boot loaders in general with what takes place and what can go wrong.

Now if you put a custom boot loader on the pcm I see an issue there. If every manufacture uses their own custom boot loader to be able to load a bin back into the pcm then why does every tool read the same bin file before a pcm if flashed with a custom calibration and why after it has a modified calibration flashed into it will the same tools also read the same file only with what every "custom" changes were made? I also don't see why a custom boot loader is needed when the factory already provided a method to flash the pcm in the 1st place. If I used HP Tuners and set random absurd values the software changes these to safe maximum values before flashing. If I then read the file with Efi Live I would also have the same maxed out out value. About half way back in this thread someone who said they had written flashing software before said the boot loader was already in the pcm and that makes sense. Before each company would go out and create a new bootloader from scratch why wouldn't they simply modify the original boot loader since the pcm can already be flashed. Now going back to my max value thing I would be led to think the bootloader in the pcm has minimum and maximum valves it will accept for each item and thats the reason that you can't flash values outside of a given range. The pcm has no way of knowing whats supposed to be there and what shouldn't be all it would know is absolute values that it can work with.
User avatar
Tazzi
Posts: 3428
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 »

160plus wrote:The STN chips only emulate the Elm for simplicity of commands...they have a hole different set of commands you can also use that go way beyond what the Elms use. Here's a breakdown of the stn chip from product literature I received from them.

https://imgur.com/a/LIikU
Iv been through their documentation. I used their OBDLink for a while until I got sick of the limitation. My previous comment about the single frame receive still applies. :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
Tazzi
Posts: 3428
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 »

Right, so Im seeing your confusion. Most of it is coming from you not understanding the language (The VPW protocol.. or what each mode does.. ect)

All tuning applications will read the same binary file out (tune) on the SAME ecu.

After all.. its the same ecu.. so the same tune is going to be pulled out everytime. It wouldnt make sense if a different tune was pulled out every time?
When you make a change.. that change is SAVED to the ECU. So reading it out with another tuning platform will see that change also.
Changing the 'chunk' size.. still means the same file comes out.. its just read out in smaller chunks.

Again, like said before, some ECUs require a custom bootloader, others do not.

For example:
On ALL Holden LS1 V8's (0411), these require a bootloader sent first. There is no 'magical' command you can send which suddenly gives you the tune and writes the tune. Making this bootloader is the hard part.. what Antus posted was the 'magic' that makes it all work.
When doing a factory update using GMs online system, it sends a custom bootloader FIRST.. and then sends the update file. Its easy to copy this bootloader.. but you are copying their intellectual property. Lots of small companies do it for private use, but no commercial company is stupid enough to do that.

Whereas, on a Holden VZ V6 ECU, these have a bootloader built into them. There IS a magical command which lets you read and write to the ECU without any work. It could be done with a ELM327, although its not advised due to my previous indication of its limitation, which is next to impossible to deal with or get passed. If you do not understand the protocol, or what each 'mode' and response actually means, then its kinda hard for you to probably understand what Im taking about :thumbup:


So.. your ECU may not require a bootloader. We wouldnt know more unless you gave details about what ecu your connected to.
If the ECU has its own inbuilt bootloader.. then yeah it really is that easy. Anyone with a bit of time can get reading/writing done on that.
If you need to create your own bootloader.. then you would need to do what Antus did (The one that apparently doesnt speak American English.. but does speaks fluent Australian and M68 for LS1's...)
Last edited by Tazzi on Sat Oct 21, 2017 3:19 pm, edited 1 time in total.
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: 3428
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 »

Comparing those two raw VPW snippets you posted. The same information is being sent TO the ECU.

6D 10 F0 36 00 00 DC FF 8A 00 blah blah blah

First 4 bytes are important here:
6D = Priority
10 = To the ECU (ECU is hexadecimal 10)
F0 = From the Scantool (Scantools are commonly F0 to F7)
36 = Mode Bulk Send/Receive

Would need to see a full log, and also the tune/update file to actually see if theres a bootloader is even required for your ECU. By the looks of it, Im assuming those snippits are you actually sending a flash file and no bootloader.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
Locked