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

Karma: +13/-0
Offline Offline

Posts: 22


« 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: +115/-10
Offline Offline

Posts: 1022


« 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
Sr. Member
****

Karma: +26/-1
Offline Offline

Posts: 255


« 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: +13/-0
Offline Offline

Posts: 22


« 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: +66/-2
Offline Offline

Posts: 235


« 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
AngelPowy
Full Member
***

Karma: +1/-0
Offline Offline

Posts: 55


« Reply #5 on: December 16, 2019, 01:15:46 PM »

Well i’m going this way too. i suceed go open channel with the ecu and i managed to open a 0x89 session. My tool wasn*t finished and I didn’t do anything else soningot dc by the ecu 5 sec after. Maybe you wasn’t at the right session for ddli ? Did you make any progress?
Logged
prj
Hero Member
*****

Karma: +903/-420
Offline Offline

Posts: 5787


« Reply #6 on: May 27, 2021, 09:14:56 AM »

I implemented this in my logger.

RequestUpload, TransferData etc is way too slow. You need to send 3 commands for every ram cell.
This means you get reasonable rate with like 6-7 ram addresses, after that it's too slow to be useful.

I patched the stack and implemented my own service, that gets reasonable speed.
Unfortunately without patching the speed is horrible on MED17 TP2.0. UDS supports $23 which is 1 command per ram cell so you can get around 20 variables before it starts to get really slow. Or again, it is possible to patch the stack to get more speed.
Logged

PM's will not be answered, so don't even try.
Log your car properly.
terminator
Sr. Member
****

Karma: +15/-4
Offline Offline

Posts: 425


« Reply #7 on: June 11, 2021, 02:23:28 PM »

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 

But what if I need to read 0xDxxxxxxx address? As I understand 0x40000h is actually 0x80040000.
Logged
kuebk
Jr. Member
**

Karma: +3/-0
Offline Offline

Posts: 44



« Reply #8 on: June 11, 2021, 04:00:12 PM »

Then you need to find out how the 0xD0000000 is mapped.
Logged
prj
Hero Member
*****

Karma: +903/-420
Offline Offline

Posts: 5787


« Reply #9 on: June 12, 2021, 12:07:11 AM »

Don't bother trying to read memory with $35, it is way too slow.
Logged

PM's will not be answered, so don't even try.
Log your car properly.
terminator
Sr. Member
****

Karma: +15/-4
Offline Offline

Posts: 425


« Reply #10 on: June 12, 2021, 03:07:44 AM »

Thanks but how can I read it too slow since there are only 3 bytes for address?)
Logged
rdrage
Jr. Member
**

Karma: +13/-1
Offline Offline

Posts: 29


« Reply #11 on: April 02, 2022, 03:57:41 AM »

any progress on the MED17 logger ?


I was thinking of adding this logger to my program, same as I did with the Me7Logger.
Logged
prj
Hero Member
*****

Karma: +903/-420
Offline Offline

Posts: 5787


« Reply #12 on: April 02, 2022, 05:56:47 AM »

My commercial tool logs MED17 both UDS and TP2.0, and has full RAM definitions for the majority of ECU's.
You are looking at a 100 EUR initial investment or 50 EUR if you have an active subscription... This gives you perpetual license for one car for full ram logging using a custom stack on both TP2.0 and UDS, so you get over ten times faster speed.
It also works with almost any J2534 device, so if you have e.g. PCMFlash already then you don't need to buy anything extra beyond just the license.

Considering the price point, and the amount of effort involved in making a workable tool (comms stack patching, A2L finding or ram cell finding etc), then I think unless you want to do this for a commercial reason, it is a giant waste of time. It took me years to get to this point.
Yes, what I provide is not free, but I don't think it ever will be, since the newer ECU's are so different and there are so many different types, that you can't easily make a ME7Info type of program to dump a (limited) set of variables directly from the bin. It's literally a full time job maintaining and expanding a such tool.
And if you need to sit in IDA and find them (because you do not have a matching A2L), then most likely it's easier to just pay 50 EUR and get to tuning, instead of wasting your time.

Sorry if it reads like an ad, but I literally made this whole thing because there did not exist any reasonable option, and besides my tool there still doesn't.
Link: https://docs.vehical.net/logger_getting_started
Logged

PM's will not be answered, so don't even try.
Log your car properly.
rdrage
Jr. Member
**

Karma: +13/-1
Offline Offline

Posts: 29


« Reply #13 on: April 02, 2022, 01:49:46 PM »

Wow, your website and everything looks pretty professional Smiley

a)
As I can see, you log to a csv file. I ll guess your flush the records for each logged row/line in the file ?

b)
Do you have an example csv file that I can just look att ?

c)
Can you run your logger with the immo on ?


I have no clue how to reads data from an ECU, thats why im using the Me7logger as an input source to my program (Windows) for showing the variables LIVE on the screen. Or even do playback.

Logged
prj
Hero Member
*****

Karma: +903/-420
Offline Offline

Posts: 5787


« Reply #14 on: April 03, 2022, 05:40:47 AM »

a)
As I can see, you log to a csv file. I ll guess your flush the records for each logged row/line in the file ?
Yes, it is flushed in real time every row, and the file is not hard locked.
This was done specifically so that if someone wants to make some kind of UI, they can do that.
Quote
b)
Do you have an example csv file that I can just look att ?
Sure, I attached. But it is possible to customize the header order and format in the options of the program.
Quote
c)
Can you run your logger with the immo on ?
Of course, immo is completely irrelevant.
Logged

PM's will not be answered, so don't even try.
Log your car properly.
Pages: [1] 2
  Print  
 
Jump to:  

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