Pages: 1 ... 6 7 [8]
Author Topic: Logging with KWP-2000 protocol  (Read 90228 times)
Full Member

Karma: +63/-1
Offline Offline

Posts: 235

« Reply #105 on: July 20, 2021, 05:39:14 PM »

def makesegmentsST():
idc.AddSeg(0xE000, 0xE800, 0, 0, 0, idc.scPub)
idc.RenameSeg(0xE000, "XRAM0")
idc.AddSeg(0xF600, 0xFE00, 0, 0, 0, idc.scPub)
idc.RenameSeg(0xF600, "IRAM")
idc.AddSeg(0xFE00, 0x10000, 0, 0, 0, idc.scPub)
idc.RenameSeg(0xFE00, "SFR")
# idc.AddSeg(0x10000, 0xE0000, 0, 0, 0, idc.scPub)
idc.RenameSeg(0x10000, "INTFLASH")
idc.AddSeg(0xE0000, 0x100000, 0, 0, 0, idc.scPub)
idc.RenameSeg(0xE0000, "XRAM1_IND")
idc.AddSeg(0x380000, 0x390000, 0, 0, 0, idc.scPub)
idc.RenameSeg(0x380000, "XRAM1_DIR")
# idc.AddSeg(0x800000, 0x900000, 0, 0, 0, idc.scPub)
idc.RenameSeg(0x800000, "EXTFLASH")

def setdppST():
idc.SetSegDefReg(0x0000, "dpp0", 0x23F)
idc.SetSegDefReg(0x0000, "dpp1", 0x3C)
idc.SetSegDefReg(0x0000, "dpp2", 0xE0)
idc.SetSegDefReg(0x0000, "dpp3", 0x03)

idc.SetSegDefReg(0x10000, "dpp0", 0x23F)
idc.SetSegDefReg(0x10000, "dpp1", 0x3C)
idc.SetSegDefReg(0x10000, "dpp2", 0xE0)
idc.SetSegDefReg(0x10000, "dpp3", 0x03)

idc.SetSegDefReg(0x800000, "dpp0", 0x23F)
idc.SetSegDefReg(0x800000, "dpp1", 0x3C)
idc.SetSegDefReg(0x800000, "dpp2", 0xE0)
idc.SetSegDefReg(0x800000, "dpp3", 0x03)

Thx prj!
Full Member

Karma: +35/-8
Offline Offline

Posts: 193

« Reply #106 on: May 11, 2022, 05:51:21 AM »

Would anyone know the optional numbers XX in the 1086XX command to get faster baud rates?
I spent the day with ida but didnt get very far. I found the baud rates in hex, and the S0BG commands, but cant figure out much else.
Hero Member

Karma: +575/-193
Offline Offline

Posts: 4982

« Reply #107 on: January 16, 2023, 06:28:57 AM »

I have documented the exploit of injecting own service handler into the ECU here:

This is the approach ME7Logger uses as well.
Much more to come shortly.

PM's will not be answered, so don't even try.

Karma: +0/-0
Offline Offline

Posts: 16

« Reply #108 on: January 16, 2023, 07:57:48 PM »

Nice work prj.
I have been using readmemorybyadress to log my me7.3.1, it's not the fastest way but it works.
I don't think that writememorybyadress is supported on this ecu, never tested, so for me, the new service table and handler will need to be hardcoded to use this method.

Enviado do meu M2102J20SG atrav├ęs do Tapatalk

Hero Member

Karma: +575/-193
Offline Offline

Posts: 4982

« Reply #109 on: January 17, 2023, 02:19:53 AM »

Hardcoding is possible too. You can make a new table and edit the place in ASW where the ptr is assigned.
Then take out the init routine, as you don't need it anymore. Also will probably need to change a few EXTS statements when reading the config for the handler.
You will still need some way to write stuff to RAM.

So if you want to hardcode a handler you will still need to make a custom one that has a subservice for that.
« Last Edit: January 17, 2023, 10:03:21 AM by prj » Logged

PM's will not be answered, so don't even try.
Full Member

Karma: +35/-8
Offline Offline

Posts: 193

« Reply #110 on: January 17, 2023, 05:13:18 PM »

Very generous of you to give this info out prj. Thanks!
Full Member

Karma: +35/-8
Offline Offline

Posts: 193

« Reply #111 on: January 24, 2023, 06:01:41 AM »

So r12 always has the pointer to the 'data to send buffer' each time a kwp2000 service is called?

Also, when the custom handler finishes and puts into r4 the number of bytes in the buffer,kpw2000 automatically knows that there is data to send and does it?

The code for the handler is very short compared even to the likes of  ReadMemoryByAddress, which you'd think would be a short one! Nice work prj.
Hero Member

Karma: +575/-193
Offline Offline

Posts: 4982

« Reply #112 on: January 24, 2023, 06:47:43 AM »

Yes, that is correct.
Unfortunately all the receive information does not get passed as parameters or on the stack, but is instead referenced directly to RAM variables.
Also the return code is directly written to a ram variable.

On most newer Bosch ECU's it is much better. They use a pointer to a structure that contains everything - the pointer to the buffer, the length of the received data, the length of the sent data, the maximum allowed length of the buffer and also the return code.
So everything can be done just based on the structure, and then the function itself does not return anything. So your custom handler can be ECU-agnostic and you don't have to do any setup like here.

And yes, the code is super short, and as optimized as possible to reduce CPU load with many variables.

Here's another freebie, all the baud rates and their numbers:
       internal enum KWP2000_VAG_BAUDRATE {
            NONE = 0x00,
            BAUD_10400 = 0x14,
            BAUD_10600 = 0x15,
            BAUD_10800 = 0x16,
            BAUD_11000 = 0x17,
            BAUD_11200 = 0x18,
            BAUD_11400 = 0x19,
            BAUD_11600 = 0x1A,
            BAUD_11800 = 0x1B,
            BAUD_12000 = 0x1C,
            BAUD_12200 = 0x1D,
            BAUD_12400 = 0x1E,
            BAUD_12600 = 0x1F,
            BAUD_12800 = 0x20,
            BAUD_13200 = 0x21,
            BAUD_13600 = 0x22,
            BAUD_14000 = 0x23,
            BAUD_14400 = 0x24,
            BAUD_14800 = 0x25,
            BAUD_15200 = 0x26,
            BAUD_15600 = 0x27,
            BAUD_16000 = 0x28,
            BAUD_16400 = 0x29,
            BAUD_16800 = 0x2A,
            BAUD_17200 = 0x2B,
            BAUD_17600 = 0x2C,
            BAUD_18000 = 0x2D,
            BAUD_18400 = 0x2E,
            BAUD_18800 = 0x2F,
            BAUD_19200 = 0x30,
            BAUD_19600 = 0x31,
            BAUD_20000 = 0x32,
            BAUD_20400 = 0x33,
            BAUD_20800 = 0x34,
            BAUD_21200 = 0x35,
            BAUD_21600 = 0x36,
            BAUD_22000 = 0x37,
            BAUD_22400 = 0x38,
            BAUD_22800 = 0x39,
            BAUD_23200 = 0x3A,
            BAUD_23600 = 0x3B,
            BAUD_24000 = 0x3C,
            BAUD_24400 = 0x3D,
            BAUD_24800 = 0x3E,
            BAUD_25200 = 0x3F,
            BAUD_25600 = 0x40,
            BAUD_26400 = 0x41,
            BAUD_27200 = 0x42,
            BAUD_28000 = 0x43,
            BAUD_28800 = 0x44,
            BAUD_29600 = 0x45,
            BAUD_30400 = 0x46,
            BAUD_31200 = 0x47,
            BAUD_32800 = 0x49,
            BAUD_33600 = 0x4A,
            BAUD_34400 = 0x4B,
            BAUD_35200 = 0x4C,
            BAUD_36000 = 0x4D,
            BAUD_37600 = 0x4F,
            BAUD_38400 = 0x50,
            BAUD_39200 = 0x51,
            BAUD_40000 = 0x52,
            BAUD_41600 = 0x54,
            BAUD_44000 = 0x57,
            BAUD_44800 = 0x58,
            BAUD_45600 = 0x59,
            BAUD_46400 = 0x5A,
            BAUD_47200 = 0x5B,
            BAUD_49600 = 0x5E,
            BAUD_50400 = 0x5F,
            BAUD_52800 = 0x61,
            BAUD_54400 = 0x62,
            BAUD_56000 = 0x63,
            BAUD_57600 = 0x64,
            BAUD_62400 = 0x67,
            BAUD_67200 = 0x6A,
            BAUD_68800 = 0x6B,
            BAUD_70400 = 0x6C,
            BAUD_72000 = 0x6D,
            BAUD_75200 = 0x6F,
            BAUD_83200 = 0x74,
            BAUD_92800 = 0x7A,
            BAUD_94400 = 0x7B,
            BAUD_99200 = 0x7E,
            BAUD_100800 = 0x7F,
            BAUD_105600 = 0x81,
            BAUD_108800 = 0x82,
            BAUD_124800 = 0x87

This is can be specified as the second parameter for StartDiagnosticSession, if there is a positive reply then after that you can communicate on the new baud rate.
56000 is widely supported, also through clusters. 124800 is supported through very few clusters.

But if you want to increase the speed of your logger, I would just do the $2C exploit. The ST10 is a little less sensitive to the CPU load, where it makes no sense to do it with the handler.
For the $2C exploit just define a single dynamic DID with some "unique" memory address and then dump the whole RAM.
Look where in the RAM the table is, then look where in the RAM there is a pointer to this table (iirc length was next to the pointer).
Now just update the length and the pointer to a different spot and write your own custom table with as many variables as you like there. If you are getting high CPU load, just use the next identifier (F0 is the first dynamic one, just use F1, F2 etc).
This works just fine, and it works exactly the same on all ECU's, it just causes higher CPU load because the $2C routine is much less optimized than my handler and you have to more aggressively split the requests (e.g. going over 40-50 variables per one DID at high baud rates and access timings is not the best idea). So on C167 the handler approach gives you notably better performance with lots of variables, especially if you make a super optimized handler.
« Last Edit: January 24, 2023, 06:56:26 AM by prj » Logged

PM's will not be answered, so don't even try.
Pages: 1 ... 6 7 [8]
Jump to:  

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