$A0 just requests the status of interfaces for transition TO high speed IF you where to send $A1.. I believe.
You need to send the $A1 for them to actually switch.
I'm not 100% sure on this though.
$A0 just requests the status of interfaces for transition TO high speed IF you where to send $A1.. I believe.
You need to send the $A1 for them to actually switch.
I'm not 100% sure on this though.
We got this guy Not Sure, ...
The autotap V2 interface doesn't auto go into high speed mode from looking at the docs, you need to send it mode $26
You send: $01 $01 $26 $00 $28
You get (if successful): $01 $01 $A6 $00 $A8
We got this guy Not Sure, ...
exactly. but when? after you send the mode $A1 but before the reply is recieved? or after the reply? Or even before you send the mode $A1? Confused yet? BTW i have tried all combo's and none seem to work for me.Originally Posted by Magnus
I count sheep in hex...
Hmm... try switching all the devices into high speed, then manually switch the V2 device.. then try to communicate to the PCM in high speed mode?
We got this guy Not Sure, ...
Don't forget the spec. is within 5 seconds after issuing a mode $a1 request you have to send a request for a supported mode ( $34) otherwise the module will return to low speed.
One thing that comes to mind, is if you can read $5000-$8000 without the security key/seed... and your vin is at 6020, your seed/key would be at 6000... so would you be able to read it prior to unlocking?
I will test this... and find out.
We got this guy Not Sure, ...
nevermind, you still need to send the key to read.
We got this guy Not Sure, ...
This is an area of differnce between the PCMs we are working on i believe. In my PCM the VIN is at $40xx. The limits will not allow you to read this information. I think these two small banks $4000-$6000 and $6000-$8000 are used differently depending on the application.
I doubt if you could read/write any of this info without unlocking the PCM and using your own loader. The limit checking code looks like this in the mode $35 processing routine.
ROM:0003CFAE cmpi.b #$35,d4 ; '5'
ROM:0003CFB2 bne.s loc_3CFC4
ROM:0003CFB4 cmpi.l #$5000,d3
ROM:0003CFBA bcs.s loc_3CFC4
ROM:0003CFBC cmpi.l #$6000,d0
ROM:0003CFC2 bcs.s loc_3CFAA
ROM:0003CFC4
ROM:0003CFC4 loc_3CFC4: ; CODE XREF: ROM:0003CFB2j
ROM:0003CFC4 ; ROM:0003CFBAj
ROM:0003CFC4 cmpi.l #$7000,d3
ROM:0003CFCA bcs.s loc_3CFD4
ROM:0003CFCC cmpi.l #$8000,d0
ROM:0003CFD2 bcs.s loc_3CFAA
I count sheep in hex...
Any updates on this?? Thanks
you definitely need your own loader to read/write the important parts of the PCM. You need to write these yourself (it's not that hard if you know assembler). Your PCM should be unlocked and prefferably in 4x mode (modes $27 and $a0/a1) to send your loader routine.
send your loader using a mode $34 request download (to the RAM area), using mode $36 block transfers. Remember that the last block you send should set submode $80 so that the PCM will jump to the address you send in the last block (hence the last block you send should be the entry address of your routine). Once your loader is in, you can do whatever your loader allows.
At a minimum your loaders must do the following:
Read (easy)
- have a mode $35 request upload servicing routine. All this does is send the data the mode $35 requests using mode $36 block transfers.
- you have a little latitude with reading since it's almost impossible to break anything
Write (a bit harder)
- need to have routines that service modes $34 and $36. Mode $36 is actually sending the data to be written to the PCM.
- obviously the routine must write the data to the flash as well
- features for robustness and handling of comms failures would be a very good idea too :Remember once your PCM loses power or is reset it is not running your loader anymore and must have valid checksums or you could be in trouble.
- the GM routine that accepts your loader is a good place to start for ideas on receive handlers and there are some places in the PCM code that actually write the flash that might give you some ideas as well.
Of course once your loader is in, you don't actually have to stick to the script in terms of protocol. However, there are a lot of other devices on the bus if your PCM is actually in the car, so it might be a good idea to stick to the spec to avoid any accidents!!
Naturally you need to know your seed and more importantly the key to do any of this. There are 2 ways to get the key (one easy way, one not so easy way involving soldering gear)
I count sheep in hex...
The loader has to be written in assembler for the motorola processor?
It takes control of the PCM and it has built in the complete routine to download the data to the PCM right???
all the 6,6c,f1,10,xx,xx etc commands to make the pcm dump and write... Those commands cannot be sent one by one or make a program outside the pcm that sends them one by one when the correct confirmation is sent? It would be slower but it would be easier in a way.. I think, but dont know if it is possible ...
yes
you also have to write some PC software to talk to your loader and send the loader in the first place.It takes control of the PCM and it has built in the complete routine to download the data to the PCM right???
yes these comands are sent by your PC but there is nowhere in the standard PCM code that will allow you to read out your entire PCM or allow you to write to the OS or cal areas. Hence the need for your own loader.all the 6,6c,f1,10,xx,xx etc commands to make the pcm dump and write... Those commands cannot be sent one by one or make a program outside the pcm that sends them one by one when the correct confirmation is sent? It would be slower but it would be easier in a way.. I think, but dont know if it is possible ...
I count sheep in hex...
How can you read the cal area without using a loader? Or is it that the loader is needed to just WRITE to the 0-7ffff area?yes these comands are sent by your PC but there is nowhere in the standard PCM code that will allow you to read out your entire PCM or allow you to write to the OS or cal areas. Hence the need for your own loader.
What do you have to have in your loader to make the PCM respond?? a standard OS for the motorola Processor? that boots etc so I can read and write the ROM?
What I am confused about and what I thought was that the loader was just a simple "autoexec.bat" or similar file that the PCM dumps to your converter and waits for confirmation before sending the next set?
but as I see the log files for writing the pcm it looks like a code that is "built in" the pcm or at least extreemely similar in the way of communicates for just sending a VIN (that is part of the calibration)
Do you have to unlock the PCM First before sending the loader?? to where in the PCM do you send the loader?
i suggest you read this thread and a few others in this area. All the answers are here.
Again:
"loader" = 68xxx code you send to the PCM and execute
"PC s/w" - software you have written on your PC to send/recv commands via the serial port
you can't read or write the cal without a loader. The cal is located 0x8000-0x1ffff.
PCM must be unlocked to do any of this.
I count sheep in hex...
Yeah, I re-read... But thanks for clarifying this.. I will find out the seed and key stuff very soon.
Gameover.. you say there is an easy way and a hard way to get the seed and key.. what is the easy way? Care to share?
The seed is easy, just send a $27 $01 request to your PCM. The key can be found by using a port sniffer as some have previously posted in this thread.
I count sheep in hex...
In this post I describe my failed attempt to unlock a GM Saturn PCM.
The PCM is from a 1999 Saturn SW-2 with an automatic transmission.
The Saturn OBD-II PCMs for 1995 to 1999 are based upon dual Motorola
MC69HC11F processors, an Intel AN28F010 flash memory, a Motorola
MC68HC58 Data Link Controller, an Allegro UDK-2547EB protected quad
power driver (rebadged as a 9727-736) and various other chips
including a large programmable gate array chip. The PCM was removed
from a wreck and powered by an old PC power supply. The PCM is
accessed by a personal computer through a Multiplex Engineering
RS-232 to J1850 VPW adapter. The numbers shown in the "Command
word" and "Response" are in hexidecimal. The unusual checksums
are a consequence of the Multiplex adapter. The following PCM
command sequence were created by my own C language program running
under DOS.
Command word: 20 02 05 6c fe f1 28 00 00 00 00 00 00 00 8a
J1850 VPW message of 2 packets.
Response 0: 40 82 6c f1 10 68 00 02 00 00 00 00 00 59
Response 1: 40 82 6c f1 18 68 00 0e 00 00 00 00 00 6d
The above responses are for node 0x10 (the engine) and 0x18
(the transmission). The PID "0x3f 0xe1" shown by Gameover in
the PCM Hacking forum does not work on a Saturn and only
produces the 0x7f error message.
Command word: 20 02 05 6c 10 f1 27 01 00 00 00 00 00 00 9c
J1850 VPW message of 1 packets.
Response 0: 40 82 6c f1 10 67 01 60 95 dc 00 00 00 28
The above response is ambiguous concerning the seed because
three bytes are shown. The seed is probably 0x6095. However
it's possible the 0x60 is a status byte and 0x95dc is the seed.
Command word: 20 02 07 6c 10 f1 27 02 60 95 00 00 00 00 94
J1850 VPW message of 1 packets.
Response 0: 40 82 6c f1 10 67 02 35 3c 00 00 00 00 c9
[Invalid key]
The above response shows the PCM rejecting the incorrect key
of 0x6095 (actually the seed). Does anybody know what the key
is for seed 0x6095?
Command word: 20 02 07 6c 10 f1 27 02 10 20 00 00 00 00 cf
J1850 VPW message of 1 packets.
Response 0: 40 82 6c f1 10 67 02 33 72 00 00 00 00 fd
[Security access denied]
The above response shows the PCM rejecting the incorrect key
of 0x1020. Notice that the rejection code is 0x33 "Security
access denied".
Command word: 20 02 07 6c 10 f1 27 02 30 40 00 00 00 00 0f
J1850 VPW message of 1 packets.
Response 0: 40 82 6c f1 10 67 02 33 72 00 00 00 00 fd
[Security access denied]
The above response shows the PCM rejecting the incorrect key
of 0x3040. Again the rejection code is 0x33 "Security
access denied".
Below are the command sequences where I try to outfox the
PCM by immediately requesting a new seed.
Command word: 20 02 05 6c fe f1 28 00 00 00 00 00 00 00 8a
J1850 VPW message of 2 packets.
Response 0: 40 82 6c f1 10 68 00 02 60 00 00 00 00 b9
Response 1: 40 82 6c f1 18 68 00 0e 60 00 00 00 00 cd
Command word: 20 02 05 6c 10 f1 27 01 00 00 00 00 00 00 9c
J1850 VPW message of 1 packets.
Response 0: 40 82 6c f1 10 67 01 60 95 dc 00 00 00 28
Command word: 20 02 07 6c 10 f1 27 02 60 95 00 00 00 00 94
J1850 VPW message of 1 packets.
Response 0: 40 82 6c f1 10 67 02 36 1b 00 00 00 00 a9
[Exceed number of attempts]
Command word: 20 02 07 6c 10 f1 27 02 10 20 00 00 00 00 cf
J1850 VPW message of 1 packets.
Response 0: 40 82 6c f1 10 67 02 37 06 00 00 00 00 95
[Required time delay not expired]
Command word: 20 02 07 6c 10 f1 27 02 30 40 00 00 00 00 0f
J1850 VPW message of 1 packets.
Response 0: 40 82 6c f1 10 67 02 37 06 00 00 00 00 95
[Required time delay not expired]
The PCM has obviously gone into time delay mode because of the
original failed attempt to unlock it. The time delay is about
20 seconds.
Saturn's engineers have earned their pay. The security logic
in this PCM works. Again, does anyone know the key for the
seeds 0x6095 or 0x95dc ? Thanks!
Gary
Try FDED or 0DED
Let me know
Dear Highlander:
Thank you very much for providing those two keys!
Unfortunately both keys were unsuccessful. The following
PCM communication log shows my failed attempts:
Command word: 20 02 05 6c fe f1 28 00 00 00 00 00 00 00 8a
J1850 VPW message of 2 packets.
Packet 0: 40 82 6c f1 10 68 00 02 00 00 00 00 00 59
Packet 1: 40 82 6c f1 18 68 00 0e 00 00 00 00 00 6d
Command word: 20 02 05 6c 10 f1 27 01 00 00 00 00 00 00 9c
J1850 VPW message of 1 packets.
Packet 0: 40 82 6c f1 10 67 01 60 95 dc 00 00 00 28
As shown in my original post, the above seed is probably 0x6095.
However it's possible the 0x60 is a status byte and 0x95dc is
the seed.
Below is the first access attempt with Highlander's key 0xFDED ;
Command word: 20 02 07 6c 10 f1 27 02 fd ed 00 00 00 00 89
J1850 VPW message of 1 packets.
Packet 0: 40 82 6c f1 10 67 02 35 3c 00 00 00 00 c9
[Invalid key]
Command word: 20 02 05 6c fe f1 28 00 00 00 00 00 00 00 8a
J1850 VPW message of 2 packets.
Packet 0: 40 82 6c f1 10 68 00 02 00 00 00 00 00 59
Packet 1: 40 82 6c f1 18 68 00 0e 00 00 00 00 00 6d
Command word: 20 02 05 6c 10 f1 27 01 00 00 00 00 00 00 9c
J1850 VPW message of 1 packets.
Packet 0: 40 82 6c f1 10 67 01 60 95 dc 00 00 00 28
Second access attempt with key 0xFDED without PCM lock-out delay ;
Command word: 20 02 07 6c 10 f1 27 02 fd ed 00 00 00 00 89
J1850 VPW message of 1 packets.
Packet 0: 40 82 6c f1 10 67 02 36 1b 00 00 00 00 a9
[Exceed number of attempts]
Command word: 20 02 05 6c fe f1 28 00 00 00 00 00 00 00 8a
J1850 VPW message of 2 packets.
Packet 0: 40 82 6c f1 10 68 00 02 00 00 00 00 00 59
Packet 1: 40 82 6c f1 18 68 00 0e 00 00 00 00 00 6d
Command word: 20 02 05 6c 10 f1 27 01 00 00 00 00 00 00 9c
J1850 VPW message of 1 packets.
Packet 0: 40 82 6c f1 10 67 01 60 95 dc 00 00 00 28
First access attempt with key 0x0DED after PCM lock-out delay ;
Command word: 20 02 07 6c 10 f1 27 02 0d ed 00 00 00 00 99
J1850 VPW message of 1 packets.
Packet 0: 40 82 6c f1 10 67 02 35 3c 00 00 00 00 c9
[Invalid key]
Command word: 20 02 05 6c fe f1 28 00 00 00 00 00 00 00 8a
J1850 VPW message of 2 packets.
Packet 0: 40 82 6c f1 10 68 00 02 00 00 00 00 00 59
Packet 1: 40 82 6c f1 18 68 00 0e 00 00 00 00 00 6d
Command word: 20 02 05 6c 10 f1 27 01 00 00 00 00 00 00 9c
J1850 VPW message of 1 packets.
Packet 0: 40 82 6c f1 10 67 01 60 95 dc 00 00 00 28
Second access attempt with key 0x0DED without PCM lock-out delay ;
Command word: 20 02 07 6c 10 f1 27 02 0d ed 00 00 00 00 99
J1850 VPW message of 1 packets.
Packet 0: 40 82 6c f1 10 67 02 36 1b 00 00 00 00 a9
[Exceed number of attempts]
I also attemped PCM access through the same method using byte
swapped keys without success, i.e. 0xEDFD, 0xED0D
I do not know how Highlander acquired these keys. Assuming Highlander
acquired them by sniffing the data stream between a Tech-2
and a PCM, it maybe necessary to trick the Tech-2 into
thinking it is talking to my PCM. I pulled the PCM
from a junk yard 1999 Saturn SW-2 (station wagon with an
automatic transmission and dual overhead cam). When my code
askes the PCM for a VIN number and PCM number it gets:
VIN number: 1G8ZK8279WZ152531
PCM number: 21008768
It is possible(?) the Tech-2 generates its key based upon
the seed --AND-- either the car model, VIN number or PCM number.
It is also possible that the seed was byte swapped or entered
incorrectly.
Thanks in advance for any help concerning this!
Gary
Reply With Quote