Pages: [1]
Author Topic: MED17 Logger under progress  (Read 596 times)
de_F
Newbie
*

Karma: +8/-0
Offline Offline

Posts: 12


« on: October 31, 2018, 10:35:09 AM »

These things have been done before by quite a few guys, but as far as I am aware, none shared until now.

I decided to try to a MED17.5 DataLogger using information and knowledge gained from NefMoto.
I just want to make clear that this is an ongoing project that does not yet work. I am not a programmer, this is only based on what I learned on the go here at Nefmoto and with some guidance aswel.
I am just sharing my progress so others might one day use it aswel if I get it to work.

First I went into the Keyword Protocol 2000 book that can be found here on NefMoto and looked for which services can be used to log data from an ECU.
By reading some NefMoto threads I found multiple ways which have been used to log by the guru's.

page14 in the KWP book (SSF 14230-3) gives a table with all the possible service identifier hex values, which I placed in brackets :

- read data by local identifier (21) ,
- read memory by address (23)
- Request upload (35)
-...

so first things first, we need to get communication between our ECU and our OBD tool. I did this on the bench, by reading the KWP and by checking how other tools did this. I found the following :

Tx 200 7 01 C0 00 10 00 03 01  / our tool (Tx) uses ID200, message of 7 bytes, asking the ECU to use CAN ID 300 (as seen in red)
Rx 201 7 00 D0 00 03 40 07 01  / reply from the ECU (Rx) acknowledging this with a 7 byte response asking the OBD tool to use CAN ID 740 (also red)

Ok we now have communication. Now we set packet & timing parameters. I just copied these.

Tx 740 6 A0 0F 8A FF 32 FF  /set parameters
Rx 300 6 A1 0F 8A FF 4A FF  /acknowledge parameters

in order to make service requests and log data, we need to open a session. Using the same table as before I found that there were a few options that allowed to use service 21 , but in order to use service 23 or 35, I needed to open either a Development session or a Programming session. The second would not be very useful as a datalogger for obvious reasons.

The request for a development session is made by sending the query 10 (start diagnostic session) followed by 86 (development session)


Tx 740 5 15 0 2 10 86  / we send a request, that is 2 bytes long, requesting to start (10) a development session (86)
Rx 300 1 B6 
Rx 300 6 1A 0 3 7F 10 33 / we get a 3bytes reply 7F Negative response (yellow) to 10 start the session (red) because of 33 Security Access denied.

Ok that is a bit of a pickle. But again, using some info found on Nefmoto, we work on passing the security access (service 27) in order to get into a development session.

Using a combination of seeds and positive responses to the seeds, we calculate the required key to unlock this service. On MED17.5 it turned out to be rather easy, just add 0x16248h to the seed and you will get a positive reply on level 03.

Tx 740 5 15 00 02 27 03  / 2bytes long request to access security level 03
Rx 300 1 B6 
Rx 300 8 2A 00 06 67 03 83 07 0F  /a positive reply adds 40h to the requested service (so 27+40=67, this is a positive reply) for level 03 and the SEED 83 07 0F 1F
Rx 300 2 1B 1F 
Tx 740 1 BC 
Tx 740 8 26 00 06 27 04 83 08 71  / our reply for service 27, on (03+1=04), adding SEED + Key as mentioned above.
Tx 740 2 17 67 
Rx 300 1 B8 
Rx 300 6 1C 00 03 67 04 34  / positive reply (27+40=67) on (03+1=04) , 34 means security access allowed.

ok so after passing the security, lets try to open a development session again.

Tx 740 5 18 00 02 10 86  / we send a request, that is 2 bytes long, requesting to start (10) a development session (86)
Rx 300 1 B9 
Rx 300 5 1D 00 02 50 86 / we get a reply that is 2 bytes long, positive reply 10+40=50 (red) and acknowledges a development session (86) (green)

Ok we are in the development session now. lets carry on, we want to log data so we first try with service 23, just read memory by address directly, that would be easy...

Tx 740 8 19 00 05 23 00 00 00 10  / we send a 5byte long request, as per KWP protocol for service 23, to set the pointer at address0x00 00 00 and read 0x10h bytes
Rx 300 1 BA 
Rx 300 6 1E 00 03 7F 23 11 / our reply is not what we hoped for. 3bytes long 7F NEGATIVE, service 23, because 11 Service not supported...

ok next, lets try using service 21, read data by local identifier. while we are still in the diagnostic session. We look up the KWP command to read a local identifier and I picked 02 just to try.

Tx 740 5 19 00 02 21 02  / we send a 2 byte command for session 21 , trying to read local identifier 02
Rx 300 1 BA 
Rx 300 8 2E 00 1A 61 02 01 C8 00  / we get a positive reply from the ECU (21+40=61) confirming local identifier 02 and the data
Rx 300 8 2F 21 85 75 16 FF 00 19 
Rx 300 8 20 FF FF 25 00 00 25 01 
Rx 300 8 11 78 25 02 79 25 00 00 

Great, this seems to work. Now we need to define our own DDLI in order to put the pointer towards the variables we want to log. Lets give it a try. Using the KWP book, we find that we need to use service 2C to make a DDLI table that points to our variables, then we just need service 21 (which we just proved works) to read our table and done ! or so I thought...

Tx 740 8 29 00 08 2C F0 03 01 FF  / here we send a request, as per KWP protocol for service 2C, put in DDLI F0, FF bytes from location 0x7FAB00
Tx 740 4 1A 7F AB 00   / not the most useful request on MED17, but good enough to test the response.
Rx 300 1 BB 
Rx 300 6 1E 00 03 7F 2C 11 / not the expected response sadly … again that dreaded 7F NEGATIVE, service 2C, 11 Service not supported …

dead end at least in development session (86) ...

ok, so lets move to our next option, lets upload the data via session 35 RequestUpload. looking it up in the KWP protocol, we find how to send the request for this :

Tx 740 8 29 00 08 35 04 00 00 00  / 8bytes request for service 35, read from 0x40000h using 00 no compression or encryption, read 40h bytes
Tx 740 4 1A 00 00 40 
Rx 300 1 BB 
Rx 300 5 1E 00 02 75 FF  / we get a 2 byte positive reply (35+40=75) with a maximum data length of FF (hex)
Tx 740 1 BF 
Tx 740 4 1B 00 01 36  / good news so lets send the 1 byte request to upload it (36)
Rx 300 1 BC 
Rx 300 8 2F 00 41 76 60 00 00 00  / 0x41h byte long positive response (36+40=76), which counts as the first byte and the requested 0x40h data
Rx 300 8 20 00 00 04 00 00 00 00 
Rx 300 8 21 00 FC FF 07 80 00 00 
Rx 300 8 22 00 00 00 00 00 00 00 
Rx 300 8 23 00 31 30 33 37 35 32 
Rx 300 8 24 30 38 32 35 AF AF AF 
Rx 300 8 25 AF AF AF AF AF 02 00 
Rx 300 8 26 00 00 17 61 E6 E6 60 
Rx 300 8 27 04 00 00 00 00 04 80 
Rx 300 5 18 FB FF 7 80 

So we just found we are able to read the data from the MED17.5 Ecu without encryption or compression at location 0x40000h (which is where our OBD read files start)


Hope you enjoyed the read. When I find time I'll keep on working to get some progress towards this next step.
« Last Edit: November 03, 2018, 12:57:29 PM by de_F » Logged
SB_GLI
Hero Member
*****

Karma: +83/-6
Offline Offline

Posts: 1005


« Reply #1 on: October 31, 2018, 06:34:30 PM »

Thank you for the walk-through on all of this.   Very descriptive, and I believe that I could follow this step for step to get to the same point as you.   Perhaps I will do that and try to lend a hand.
Logged
H2Deetoo
Full Member
***

Karma: +9/-0
Offline Offline

Posts: 153


« Reply #2 on: December 05, 2018, 07:26:26 AM »

Basically this is pretty generic to read data from any KWP compatible module.
The problem is often what addresses are allowed to read and what data is stored there.
Very often you want to read the flash (or important parts of flash) and the eeprom. These are often blocked ...
Logged
de_F
Newbie
*

Karma: +8/-0
Offline Offline

Posts: 12


« Reply #3 on: December 05, 2018, 08:48:44 AM »

Yes it is generic to KWP indeed. While I gave it a try, I wanted to share my trials and errors and make a small guide on how to get started with these things, so others could follow and perhaps one day make their own tools.
Logged
360trev
Full Member
***

Karma: +19/-1
Offline Offline

Posts: 121


« Reply #4 on: December 06, 2018, 03:20:12 AM »

I don't have an MED17.5 ECU to play with but perhaps I could get a used cheap one from Ebay and help you guys out a bit...

Using the information here I could easily write the code in C which does this in a couple of hours...

Trev
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.019 seconds with 16 queries. (Pretty URLs adds 0.001s, 0q)