Decyphering iMiEV and iON CAR-CAN message data
- Thread starter garygid
- Start date
Help Support Mitsubishi i-MiEV Forum:
KommyKT said:
Hi KommyKT Thanks very much for this information. Cheers David
This is like peeling an onion. May be old news for some folks, but it's new to me.
It appears that "anko" from the mitsubishi Outlander PHEV forum has figured out a method to send a query request to the BMU to access the BMU Data Items List which is mentioned in the FSM when using the MUT tool.
This seems to be a different approach than that of Canion and other apps which read CAN PIDs over the OBDII port.
anko shared his findings with zzcoopej from Australia, who developed the EvBatMon app which is available for the phev and miev on his website at evpositive (.com).
i could see the value of being able to send a query request to some of the various ecus for troubleshooting, to read DTCs and stored values, etc.
more layers to peel...
It appears that "anko" from the mitsubishi Outlander PHEV forum has figured out a method to send a query request to the BMU to access the BMU Data Items List which is mentioned in the FSM when using the MUT tool.
This seems to be a different approach than that of Canion and other apps which read CAN PIDs over the OBDII port.
anko shared his findings with zzcoopej from Australia, who developed the EvBatMon app which is available for the phev and miev on his website at evpositive (.com).
i could see the value of being able to send a query request to some of the various ecus for troubleshooting, to read DTCs and stored values, etc.
more layers to peel...
A new i-miev owner, technically get the old car this Wednesday.
Been reading up on what I had assumed be a fairly straight forward project
Some sort of remote heater activation via can bus. I have a volvo s60r and just assumed a similar level of hackery as been done on the s60 platform
If my reading thus far is correct..
No one has gotten this to work.
People have cracked the suspected PID and format for heat/cool controls.
It is not known how to write to the canbus, so it is simply untested to to send such PID+data combos onto the canbus.
Someone referenced a few times a 'risk of break assistance' being affected if you try to write to the canbus? Did they mean brake assist (ABS)? I couldn't find any thread where this fear was first explained.
I've ordered an OVMS that with any luck will arrive tomorrow. If nothing else having the remote visibility of charge state/location is quite nice.
Is it true no one has documented how to write to the canbus?
Can MUT III actuate the heater? It must be able to write to the canbus then? Any ability to decode that?
If I were to buy the remote-ecu + antenna + remote control, is it known if the 20111 model has the connections needed? Any one emulate the radio signal from within the car instead - letting you do it over internet instead of within range of the remote ?
Appreciate any tips, plan to start my own tinkering with the car.
Been reading up on what I had assumed be a fairly straight forward project
Some sort of remote heater activation via can bus. I have a volvo s60r and just assumed a similar level of hackery as been done on the s60 platform If my reading thus far is correct..
No one has gotten this to work.
People have cracked the suspected PID and format for heat/cool controls.
It is not known how to write to the canbus, so it is simply untested to to send such PID+data combos onto the canbus.
Someone referenced a few times a 'risk of break assistance' being affected if you try to write to the canbus? Did they mean brake assist (ABS)? I couldn't find any thread where this fear was first explained.
I've ordered an OVMS that with any luck will arrive tomorrow. If nothing else having the remote visibility of charge state/location is quite nice.
Is it true no one has documented how to write to the canbus?
Can MUT III actuate the heater? It must be able to write to the canbus then? Any ability to decode that?
If I were to buy the remote-ecu + antenna + remote control, is it known if the 20111 model has the connections needed? Any one emulate the radio signal from within the car instead - letting you do it over internet instead of within range of the remote ?
Appreciate any tips, plan to start my own tinkering with the car.
Hello,
I've made a small additional gauge for my c-zero. It connects to the OBDII plug, the CAN-bus is processed by a MCP2515 and an arduino.
It shows the cells voltage and the battery power in/out.
Some details here (I should complete it soon):
https://pierremuth.wordpress.com/2022/07/24/electric-car-battery-dashboard-gauge/
I've made a small additional gauge for my c-zero. It connects to the OBDII plug, the CAN-bus is processed by a MCP2515 and an arduino.
It shows the cells voltage and the battery power in/out.
Some details here (I should complete it soon):
https://pierremuth.wordpress.com/2022/07/24/electric-car-battery-dashboard-gauge/
very cool @muth . If you have any of your pids documented i'd love to see them; I believe the OVMS project uses it and this repo is the best 'single' source I've found.
https://github.com/KommyKT/i-miev-obd2
I am still trying to do lossless captures on my i-miev. When using the ovms, I get 50% discards capturing the entire canbus. I've ordered a CL2000 hoping this will give me the ability to do full captures lossless. While also trying to improve the ovms performance.
I am new to can and 'this level' of development, triage. If I am following though, we know the PID which the HVAC announces it's status (on/off, heat, location, etc). Sending 0x3A4 will not turn on the climate control, as it's the unit just announcing it status. Right?
But the PID which turns on the HVAC is unknown, and unfortunately no one with a factory remote has ever done a capture -- If anyone has the remote control and can do a capture, i'd even be happy to pay for a device to do the capture.
An Idea I've had - Has anyone captured during a chademo session? When doing chademo the car turns on the A/C and controls the vents. Is there any chance that PID is possible to be 'the one' that we'd want to spoof -- albeit different bits to control the vents towards the cabin? Perhaps it is the right pid, but different data bits? -- Chademo turns on A/C temp, but remote sets heat? Would this be logical? Has anyone already explored this theory?
https://github.com/KommyKT/i-miev-obd2
I am still trying to do lossless captures on my i-miev. When using the ovms, I get 50% discards capturing the entire canbus. I've ordered a CL2000 hoping this will give me the ability to do full captures lossless. While also trying to improve the ovms performance.
I am new to can and 'this level' of development, triage. If I am following though, we know the PID which the HVAC announces it's status (on/off, heat, location, etc). Sending 0x3A4 will not turn on the climate control, as it's the unit just announcing it status. Right?
But the PID which turns on the HVAC is unknown, and unfortunately no one with a factory remote has ever done a capture
-- If anyone has the remote control and can do a capture, i'd even be happy to pay for a device to do the capture. An Idea I've had - Has anyone captured during a chademo session? When doing chademo the car turns on the A/C and controls the vents. Is there any chance that PID is possible to be 'the one' that we'd want to spoof -- albeit different bits to control the vents towards the cabin? Perhaps it is the right pid, but different data bits? -- Chademo turns on A/C temp, but remote sets heat? Would this be logical? Has anyone already explored this theory?
Thanks a lot Dopey, KommyKT repo is really great !
I used only known PID. The four battery cell voltage: 6E1 6E2 6E3 6E4. And the 373 for the total voltage and amp. Plus the min and max of the cells voltages, also in 373, I think it is not mentioned on KommyKT repo but I've found it in the OBDZero source code, D0 and D1 :
I used only known PID. The four battery cell voltage: 6E1 6E2 6E3 6E4. And the 373 for the total voltage and amp. Plus the min and max of the cells voltages, also in 373, I think it is not mentioned on KommyKT repo but I've found it in the OBDZero source code, D0 and D1 :
Code:
case "373":
b_BatVmax.dbl = (aPID.intPID[0] + 210) / 100.0;
b_BatVmin.dbl = (aPID.intPID[1] + 210) / 100.0;
b_Amps.dbl = (aPID.intPID[2] * 256 + aPID.intPID[3] - 32768) / 100.0;
c_Amps.dbl = -b_Amps.dbl;
c_AmpsCal.dbl = -(b_Amps.dbl + 0.66);
if (aPID.intPID[4] > 9)
b_Volts.dbl = (aPID.intPID[4] * 256 + aPID.intPID[5]) / 10.0;
b_Watts.dbl = c_AmpsCal.dbl * b_Volts.dbl;
break;I've yet to find anything useful, but sharing some collection i've done thus far. My goal is to turn the heater on remotely in winter -- but at this point i'd be happy to trigger any sort of command on the car
I've been recording from the OBD using usbcan, and yesterday tapped into the AC ECU under the back seat -- pins 3 +4 using canusb. Looking at the docs it appears we have a CAN1, CAN2 with the ETACS ecu acting as gateway towards the diagnostic port. I had hoped by listening on the canH/L on the A/C ECU that i'd find commands to control the A/C unit.
Additionally had the idea to sniff both OBD2 and the ac-ecu when starting chademo since it triggers the A/C + vents during those sessions. Even if that is the 'wrong' command, being able to control the A/C at all be a huge win.
Sadly, I believe i'm seeing less PIDs sniff the AC ECU than from OBD2. I was expecting the opposite.
Here is a high level summary from the following. This is a very simple script that counts the pids in the candump file.
[*] The pid then the # of occurence in the file
[/list]
This is my first time digging into canbus, my thinking was to try and divide and find uncommon/unique pids either from actions (clicking on/off A/C), or from location i'm sniffing. So take away the known 'noise', and try to find new things.
From OBD2 port - Driving from home *to* chademo station. Starting with key out of ignition.
*note* I accidentally took a wrong turn so the length of this capture was a good deal longer, but the car was never stopped, put in reverse, etc just driven forward longer.
From ACECU terminal 3+4: Driving from Chademo station back home.
When I first arrived I started a new candump log, started chademo, waiting a bit, then cancelled the session. This from OBD2 connector:
I then connected to the A/C ECU terminal 3+4, started a chademo, waiting, then cancelled. I was better to not leave a door 'open' during this, hence less noise on the 424/other pids I think.
I'm just starting to go through this(Just got home with the logs). I was expecting to find new interesting PIDs from sniffing the A/C ECU as I *thought* I was on CAN2 and seeing traffic obscured from the OBD2 connector. At a glance, that does not seem to be the case.
A really really dumb question -- Any theories why we seemingly cannot issue a canbus command/reply anything we see on the bus? When locking doors I see 424, 412, and 408. Replaying these never cause the locks to change. Even tho seemingly D3 changing from 00 to 40 is the switch, with the other bits seeming to change over time. I'm new to this, but thought the general approach for canbus was finding the 'right' pid and replaying it. Whether Windows, locks, etc. Is there some sort of calculation happening/expected on the other Bytes? Is it a timing/order of multiple pids to trigger an event? Is it 424 may be the 'status' of the lock but another unknown PID is the 'command' to unlock the door?
The most i've been able to do is make the dashboard look like a christmas tree playing with the 424 pid -- by sending the same data on 424 twice in quick succession i can get both turn signals to 'blink' like they do when unlocking the car, but never anything actually meaningful
By sending I mean doing something like:
Or using replay in savvycan.
Is it true no one has managed to 'send' a command via canbus? The only way has been a canbus bridge -- which feels dangerous as if the bridge dies the traffic dies and the car will go out of Ready? Any theories why this car is so resistant?
I've been recording from the OBD using usbcan, and yesterday tapped into the AC ECU under the back seat -- pins 3 +4 using canusb. Looking at the docs it appears we have a CAN1, CAN2 with the ETACS ecu acting as gateway towards the diagnostic port. I had hoped by listening on the canH/L on the A/C ECU that i'd find commands to control the A/C unit.
Additionally had the idea to sniff both OBD2 and the ac-ecu when starting chademo since it triggers the A/C + vents during those sessions. Even if that is the 'wrong' command, being able to control the A/C at all be a huge win.
Sadly, I believe i'm seeing less PIDs sniff the AC ECU than from OBD2. I was expecting the opposite.
Here is a high level summary from the following. This is a very simple script that counts the pids in the candump file.
- percentage of known vs unknown
- 'Known Pids(count) - I consider a pid 'known' from the README.md having a description/formula for the pid. I started to incorporate the formula in my python script so they are listed as 'known'.
- 'Uknown' Pids(count) are one that I have not seen defined what they do/for/mean or a formula.
- 'Known but not configured(count):' Are in the readme but I havent' implemented the formula.
[*] The pid then the # of occurence in the file
[/list]
This is my first time digging into canbus, my thinking was to try and divide and find uncommon/unique pids either from actions (clicking on/off A/C), or from location i'm sniffing. So take away the known 'noise', and try to find new things.
From OBD2 port - Driving from home *to* chademo station. Starting with key out of ignition.
Code:
[dopey@dopey-desktop triage-imiev]$ python dopeyParse.py rawLogs/obd2/310722-home-mcdonalds-d-b-d-38.log
Known 43.01104006596152, Unknown 56.98895993403848, Failed 0.0
Total Pids(55):
Known Pids(15):
101 12204
149 60609
200 60608
208 60608
210 60999
215 60608
231 60607
236 121210
285 121998
298 12200
346 60998
373 122097
374 12210
384 12113
412 12264
Unknown Pids(40):
100 1
110 1
111 1
119 60607
156 60609
212 60999
288 121991
2F2 12120
300 60607
308 60998
325 61506
375 12210
385 12113
408 12264
564 24399
565 24399
5A1 24420
695 12200
6D0 24400
6D1 24400
6D2 24400
6D3 24399
6D4 24400
6D5 24400
6D6 24400
6DA 24399
6FA 12200
75A 12199
75B 12199
Known but not configured(11):
286 12200
696 12200
6E3 30524
697 12199
6E4 30524
29A 12200
6E2 30524
6E1 30524
424 30754
418 61000
3A4 12113
Failed Pids(0):
[dopey@dopey-desktop triage-imiev]$*note* I accidentally took a wrong turn so the length of this capture was a good deal longer, but the car was never stopped, put in reverse, etc just driven forward longer.
From ACECU terminal 3+4: Driving from Chademo station back home.
Code:
[dopey@dopey-desktop triage-imiev]$ python dopeyParse.py rawLogs/acecu/3102722-ac-ecu-kungmcd-home-d-b-keyoff-removed.log
Known 35.89669122775868, Unknown 64.10330877224132, Failed 0.0
Total Pids(47):
Known Pids(12):
101 7453
200 3309
208 1542
210 36962
215 583
231 28318
285 72043
298 5994
346 40032
373 73628
374 5986
412 7199
Unknown Pids(35):
100 1
119 169
212 34647
288 65481
2F2 7301
300 1047
308 36370
325 714
375 7442
408 7650
564 12057
565 13064
5A1 14646
695 8035
6D0 17067
6D1 17012
6D2 16603
6D3 16922
6D4 15784
6D5 15146
6D6 15542
6DA 15694
6FA 7893
75A 6279
75B 7275
Known but not configured(10):
418 34023
424 266
697 7996
6E1 19877
29A 6075
286 8532
6E3 20724
6E4 20230
6E2 19493
696 8404
Failed Pids(0):
[dopey@dopey-desktop triage-imiev]$When I first arrived I started a new candump log, started chademo, waiting a bit, then cancelled the session. This from OBD2 connector:
Code:
[dopey@dopey-desktop triage-imiev]$ python dopeyParse.py rawLogs/obd2/310722-chademo-start-end-obd2.log
Known 29.951199674664498, Unknown 70.0488003253355, Failed 0.0
Total Pids(42):
Known Pids(9):
101 451
210 2251
285 4505
298 451
346 2251
373 4562
374 457
384 424
412 851
Unknown Pids(33):
212 2251
288 4503
308 2251
325 4260
375 457
385 425
408 851
564 901
565 901
5A1 912
695 451
6D0 901
6D1 901
6D2 901
6D3 900
6D4 901
6D5 901
6D6 901
6DA 900
6FA 451
75A 451
75B 451
Known but not configured(11):
696 451
418 2251
6E4 1141
6E1 1141
29A 451
6E2 1141
3A4 425
286 451
424 2130
697 450
6E3 1141
Failed Pids(0):
[dopey@dopey-desktop triage-imiev]$I then connected to the A/C ECU terminal 3+4, started a chademo, waiting, then cancelled. I was better to not leave a door 'open' during this, hence less noise on the 424/other pids I think.
Code:
[dopey@dopey-desktop triage-imiev]$ python dopeyParse.py rawLogs/acecu/310722-ac-ecu-chademo-start-end-door-open-close.log
Known 31.327193932827736, Unknown 68.67280606717226, Failed 0.0
Total Pids(42):
Known Pids(9):
101 1522
210 7564
285 15222
298 1510
346 7583
373 15209
374 1527
384 328
412 1582
Unknown Pids(33):
212 7567
288 15132
308 7556
325 8227
375 1528
385 108
408 1575
564 3031
565 2969
5A1 2903
695 1522
6D0 2935
6D1 3042
6D2 3042
6D3 3039
6D4 3041
6D5 3042
6D6 3042
6DA 3036
6FA 1522
75A 1515
75B 1502
Known but not configured(11):
6E1 3820
697 1522
286 1458
3A4 482
29A 1495
6E2 3819
418 7566
424 4018
6E3 3751
696 1522
6E4 3764
Failed Pids(0):
[dopey@dopey-desktop triage-imiev]$I'm just starting to go through this(Just got home with the logs). I was expecting to find new interesting PIDs from sniffing the A/C ECU as I *thought* I was on CAN2 and seeing traffic obscured from the OBD2 connector. At a glance, that does not seem to be the case.
A really really dumb question -- Any theories why we seemingly cannot issue a canbus command/reply anything we see on the bus? When locking doors I see 424, 412, and 408. Replaying these never cause the locks to change. Even tho seemingly D3 changing from 00 to 40 is the switch, with the other bits seeming to change over time. I'm new to this, but thought the general approach for canbus was finding the 'right' pid and replaying it. Whether Windows, locks, etc. Is there some sort of calculation happening/expected on the other Bytes? Is it a timing/order of multiple pids to trigger an event? Is it 424 may be the 'status' of the lock but another unknown PID is the 'command' to unlock the door?
The most i've been able to do is make the dashboard look like a christmas tree playing with the 424 pid -- by sending the same data on 424 twice in quick succession i can get both turn signals to 'blink' like they do when unlocking the car, but never anything actually meaningful
By sending I mean doing something like:
Code:
cansend slcan0 424#C0004000A70501FFOr using replay in savvycan.
Is it true no one has managed to 'send' a command via canbus? The only way has been a canbus bridge -- which feels dangerous as if the bridge dies the traffic dies and the car will go out of Ready? Any theories why this car is so resistant?
What about the checksum/CRC? How is that created and sent along with your packet?
It seems like most of the PID lists and tables leave out the CRC, but they are necessary for every message.
It seems like most of the PID lists and tables leave out the CRC, but they are necessary for every message.
dopey said:
That would be awesome, I spent quite some time to find used [antenna - EV remote-ECU - remote], on broken iMiev/ion/czero. No luck so far I only found one car, and it did not have the remote option.
I notice someone has a c-zero as well in my village, I should talk to the guy and see if he has the remote option and could record the canbus...
kiev said:What about the checksum/CRC? How is that created and sent along with your packet?
It seems like most of the PID lists and tables leave out the CRC, but they are necessary for every message.
That is one part I am confused about as a novice
The arbitration field and CRC portion in general.That image confuses me, as it seems to imply the Data is 8 Bytes, and CRC is 15 bytes? But when reading I think some of those sections are bits and others bytes? Like 11 for Arbitrateion field is 11 bits of data, but the data portion is 8 bytes?
Regardless anytime I do captures with candump, I end up with this:
Code:
(1659216600.182236) slcan0 424#C7600C00B8D203FF(epochts) interface pid#data
Or if I listen in savvycan and save the log it is a csv like:
Code:
[dopey@dopey-desktop triage-imiev]$ grep "0000424" rawLogs/unsorted/unlock-driver-manual.csv | head
3335525,00000424,false,Rx,0,8,C1,00,08,00,A1,47,01,FF,Neither dump, to my eyes, show the arbitration (such as priority?) or CRC data? I've tried googling for alternative flags on candump but can't seem to find it.
Is the CRC field auto generated due to one of the bytes in the data field? Like D4-D7? When looking at data, such a PID 0x424 I see a clear counter behavior happening on D4 onward. Is this a checksum which then creates the CRC in your frame?
I've also tried to reverse looking at Nissan Leaf on OVMS to see how they send commands;
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master/vehicle/OVMS.V3/components/vehicle_nissanleaf/src/vehicle_nissanleaf.cpp
There is a crc table there which if I am reading correct is used to populate D7 when sending pid 0x1db . Which is what made me think that the CRC is part of D0-D7 and not it's own data beyond D7 in your cansend payload? Ofcourse a complete mystery to me how one figured out the crc table they have
I will be receiving a CL2000, as well Canedge 2 units this week along with various cables. Not expecting them to solve my issue, but it seems collecting in multiple locations in parallel can bring some clues of messages I otherwise do not see, or confirm if my send messages are making -- a gateway isn't blocking. Additionally I have an s60r volvo which I plan to do some canbus monitoring+actions to control the in dash navigation screen connected to an rpi -- fortunately the volvo canbus is allot more decoded given the massive community compared to imiev
For those(everyone) smarter than I on this topic, if my new equipment can be useful to further the imiev ovms or other projects I am happy to be a guinea pig. Meanwhile I'll keep bashing my head until I hopefully make the car do something on command
@kiev I noticed in your remote-defrost csv, you had the CRC and ACK. How did you do your captures? For the life of me I cannot make candump give me anything beyond D0-D7
coulomb
Well-known member
Those fields should be sorted out by your hardware, as long as you have all the registers in the CAN chip set up correctly.dopey said:That is one part I am confused about as a novice
Those are bits. CAN bus data can be from zero to eight bytes (set in the DLC, Data Length Control field); in this example, DLC = 1 and there is only 1 byte of data. Most CAN packets have 8 bytes of data.
Again, these are automatically handled; arbitration and CRC are not part of the "user" data.
The CRC depends on many fields, but is hardware generated and checked.
That D4 counter thing is nothing to do with the CRC. It's a common thing that cars have, and you just have to give it what it's looking for there.
That seems to be a different CRC to the one in the CAN data stream. Don't confuse the two.
@dopey, All the CAN traffic is binary data, just ones and zeroes; the CAN protocol determines how you group, read and interpret the bits.
The arbitration field is 11 bits and contains the Parameter ID, aka the PID; so 7FF is the highest PID in hexadecimal, 11111111111 in binary.
The CRC is the Cyclic Redundancy Check used to detect accidental data errors. See wikipedia for a good overview.
i used an arduino with a CAN reading sketch code to capture the data for triggering the defroster using the big fat remote. i've never tried to send commands, but i'm sure a CRC would be needed with every message frame. Send me an email if you need the sketch but it is from Colin Kidder's github.
The arbitration field is 11 bits and contains the Parameter ID, aka the PID; so 7FF is the highest PID in hexadecimal, 11111111111 in binary.
The CRC is the Cyclic Redundancy Check used to detect accidental data errors. See wikipedia for a good overview.
i used an arduino with a CAN reading sketch code to capture the data for triggering the defroster using the big fat remote. i've never tried to send commands, but i'm sure a CRC would be needed with every message frame. Send me an email if you need the sketch but it is from Colin Kidder's github.
Thank you both of you --- your historical posts have been very useful as I try to get up to speed. Your tip on .net decompiling specifically was great @coulomb. I had been digging through the .js of the older version hoping to crack how MUT was able to send commands -- but it all lead back to some combiled binaries doing the actuall calls. As well digging through the MSSQL databases directly trying to build my own joins and dump out something useful. Your .net was a nice lead to try and look at the later version binaries for clues. So far, nothing interesting/useful tho
Appreciate taking time to help me keep this straight. If I follow, When you say CRC Kiev you are not meaning that is automatic via correctly configured hardware. But the bits within the DATA portion that changes -- whether auto increment or a calculated bit from other data.
For example; I can see 0x424 increments+1 after 1500 frames D4(iirc). That's an example of a simple counter increasing which you'd need to handle if you were spoofing that PID traffic. The Leaf per Dala's video has a few different methods it uses for this, from simple (incremental counters) to complex calculations based on some common standards -- Which I am assuming is what that Leaf table is from/for.
Am I wrong in assuming a key challenge is the lack of any 'command' PIDs being discovered aka can send once and trigger the locks to unlock (Which seems is what others have found for other cars on OVMS?). Only status/repeating type messages -- Which would require a MITM type bridge to manipulate in route.
Appreciate taking time to help me keep this straight. If I follow, When you say CRC Kiev you are not meaning that is automatic via correctly configured hardware. But the bits within the DATA portion that changes -- whether auto increment or a calculated bit from other data.
For example; I can see 0x424 increments+1 after 1500 frames D4(iirc). That's an example of a simple counter increasing which you'd need to handle if you were spoofing that PID traffic. The Leaf per Dala's video has a few different methods it uses for this, from simple (incremental counters) to complex calculations based on some common standards -- Which I am assuming is what that Leaf table is from/for.
Am I wrong in assuming a key challenge is the lack of any 'command' PIDs being discovered aka can send once and trigger the locks to unlock (Which seems is what others have found for other cars on OVMS?). Only status/repeating type messages -- Which would require a MITM type bridge to manipulate in route.
It may be that the CRC is, or can be, automagically calculated and appended in the frame by properly configured hardware, but when you are manually reading or writing frames to the CAN buss using an Arduino, then this is not automatic. You would need a subroutine to do the division of the data bits using the correct polynomial and insert this in the frame at the correct location.
As far as the PIDs go, there are folks who know the PID meanings and the methods to send messages/commands, etc but unlike the leaf and other cars, they are not sharing their knowledge or helping to develop a ".DBC" for the miev. i'm sure they wouldn't hesitate to use all the schematics and information that i have freely shared for troubleshooting and repair of OBC, DCDC, MCU faults.
As far as the PIDs go, there are folks who know the PID meanings and the methods to send messages/commands, etc but unlike the leaf and other cars, they are not sharing their knowledge or helping to develop a ".DBC" for the miev. i'm sure they wouldn't hesitate to use all the schematics and information that i have freely shared for troubleshooting and repair of OBC, DCDC, MCU faults.
That's very unfortunate :-/
I find myself going at this in multiple ways, perhaps best to share and get feedback if any have been done before or otherwise futile.
1.) Capture, capture, capture. Try to capture from as many spots as possible in parallel(OBD, AC-ECU, EV-ECU, etc). Hope one of them exposes PIDs not already known which can control functions. Specifically capturing CAN traffic.
2.) Try to reverse engineer the MSSQL databases provided with MUT - This is assuming the actual pids, important bytes, etc are stored in that database and the code merely calls the right joins, views to create the respective query. vkey, receiveId, sendID, and definitely a few tables that really really sound interesting/potential to convert into an actual PID+Data string to be sent.
3.) Try to reverse engineer the .js for the 'older' version of MUT. The older MUT appears to be javascript with activex controls based. There is a few binaries which are loaded and called. As well some local file based databases leveraged. The javascript is not obfuscated and completely readable. Have found miev in comments on some, and can skip over vci error messages to atleast navigate mut further.
4.) Use dotpeek on the newer .net version -- tho i'm not sure what one would gain here. Or atleast i'm not experienced in decompiling, so while I can find interesting sounding classes and methods.. I don't see any meangingful way to take this back to something usable on the car.
5.) Buy a MUT adapter and sniff MUT traffic itself -- specifically thinking the actuator test? That must be sending a PID to start things? I have a Volvo DICE clone today, but even with vxdiag and passthrough MUT does not work. It seems I either need to buy a mut clone or potentially pay for that driver floating around -- problem is I use all this on a VM.
6.) Try to decompile the .ocx files but i've yet to succeed. On the older version of MUT this appears to be the binaries which do the actual comms to the HW -- just assuming within there is where the actual 'magic' is done.
7.) Try to sniff the Local communication between AC-ECU and Heater Controller, like here: http://mmc-manuals.ru/manuals/i-miev/online/Service_Manual/img/55/AC902570AB00ENG.png . Though I have no idea 'how' one does that
8.) Go digging for *other* Mitsubishi vehicles that have solved sending commands and try their approach on miev-- phev being one, but perhaps other more popular gas cars. Is it common for car makers to use same pids across different models? or maybe same 'approach' ? Like send vs receive pid always being +1 or +10 or whatever?
I've been doing all of these on/off past few weeks and recognize I should probably hone in one for a sustained effort. Have any of these been pursued before? Any gut feeling which may yield the best path of success?
My goal is to trigger functions on the car - heating be ideal but even unlocking a door or rolling down a window be a success
If I do manage to find something new, is the git repo I shared before the best place to update -- that fork specifically?
I find myself going at this in multiple ways, perhaps best to share and get feedback if any have been done before or otherwise futile.
1.) Capture, capture, capture. Try to capture from as many spots as possible in parallel(OBD, AC-ECU, EV-ECU, etc). Hope one of them exposes PIDs not already known which can control functions. Specifically capturing CAN traffic.
2.) Try to reverse engineer the MSSQL databases provided with MUT - This is assuming the actual pids, important bytes, etc are stored in that database and the code merely calls the right joins, views to create the respective query. vkey, receiveId, sendID, and definitely a few tables that really really sound interesting/potential to convert into an actual PID+Data string to be sent.
3.) Try to reverse engineer the .js for the 'older' version of MUT. The older MUT appears to be javascript with activex controls based. There is a few binaries which are loaded and called. As well some local file based databases leveraged. The javascript is not obfuscated and completely readable. Have found miev in comments on some, and can skip over vci error messages to atleast navigate mut further.
4.) Use dotpeek on the newer .net version -- tho i'm not sure what one would gain here. Or atleast i'm not experienced in decompiling, so while I can find interesting sounding classes and methods.. I don't see any meangingful way to take this back to something usable on the car.
5.) Buy a MUT adapter and sniff MUT traffic itself -- specifically thinking the actuator test? That must be sending a PID to start things? I have a Volvo DICE clone today, but even with vxdiag and passthrough MUT does not work. It seems I either need to buy a mut clone or potentially pay for that driver floating around -- problem is I use all this on a VM.
6.) Try to decompile the .ocx files but i've yet to succeed. On the older version of MUT this appears to be the binaries which do the actual comms to the HW -- just assuming within there is where the actual 'magic' is done.
7.) Try to sniff the Local communication between AC-ECU and Heater Controller, like here: http://mmc-manuals.ru/manuals/i-miev/online/Service_Manual/img/55/AC902570AB00ENG.png . Though I have no idea 'how' one does that
8.) Go digging for *other* Mitsubishi vehicles that have solved sending commands and try their approach on miev-- phev being one, but perhaps other more popular gas cars. Is it common for car makers to use same pids across different models? or maybe same 'approach' ? Like send vs receive pid always being +1 or +10 or whatever?
I've been doing all of these on/off past few weeks and recognize I should probably hone in one for a sustained effort. Have any of these been pursued before? Any gut feeling which may yield the best path of success?
My goal is to trigger functions on the car - heating be ideal but even unlocking a door or rolling down a window be a success
If I do manage to find something new, is the git repo I shared before the best place to update -- that fork specifically?
coulomb
Well-known member
That seems to have promise. What is this "older" version of MUT? I have 2016, 17, 18. I wasn't thinking Javascript; usually that's server side.dopey said:
Most of the binaries, in .CFF files, seem to be (with one exception, the CMU firmware) encrypted. To me, that's where the gold is. It might be possible to discover how to decrypt the binaries by reading the JS.
[ Mentioned .CFF files; BMU → CMU ]
Not sure..I think the iso was PRE21061_00.iso forget now where I got it, think a link to a forum from here.
When it installed it did both MUT and MUTSE. MUT opens effectively in IE, can even hit f12 for development tools. It has a similar looking interface/landing page.
Database wise there two clusters of databases created. It' snot clear to me if one is for MUTSE and one for MUT, both for one, or both for both. CAESAR is one group of Database, only 2. The other is about 20 different databases many with same table structure but a few with variations. Lots of empty tables.
On the install, on C:\ do you have MUTSW or MUTSW_SE or both? The javascript is under MUTSW/MUT3/MENU/SCRIPTS
The .ocx binaries that are loaded as activex controls are under SYSTEM --- I think these be the crown jewels to crack open or fool into a debug mode to spit out all the details
There is also various .mdb databases opened.
A sampling of the file types(Just top few by count)
What I can gather is the javascript is the entire GUI that you navigate. It can load a half dozen different activex controls which are .ocx binaries which I have not found a way to decompile.
I have not found any instance where the javascript is compiling the actual DATA hex to be sent. The javascript does more like:
MutCanDiag1.InitCarInfo(g_CanBusID) and process the response as success/failure.
It can also ask to read some of the local file based databases (.mdb) for information such as based on vin lookup. To get things like canbusID, constitutionnumber, etc. Looking at the MSSQL databases these references are also there.
I have been able to load for example the Miev Diagnostic page, you can add returns to the ErrMsg functions that are gernically called on comm errors to VCI. Unfortunately I have yet to find a way to get it ti spit out the actual data/command being issued to the car. So i'm only seeing the GUI screen progression :-/
Is it possible MUT is using the K-Line to actuate things? Or even the folks that have 'solved' this without sharing? K-Line is available on the OBD port but i've not found anyone that has explored it? I am not even sure how to monitor it The Canedge2 I am receiving can monitor LIN bus but it's not clear to me if K-Line / LIN is interchangeable or just very similar protocols?
Another idea came last night, @kiev your icarsoft i909. The screens look very very similar to MUT on diag pages, etc. Can you trigger any actuations with it? That may be the easiest route is to buy one of those use a Y adapter and sniff it's traffic? Am I off that monitoring any sort of diagnostic device actuating something on the car be potentially repeatable/breakthrough? Was considering to order one of the Max iCarsoft which states it covers Mitsubishi, just to have for our vehicles in general -- so if it gives me a potential chance to sniff/reverse engineer i'll order it today
When it installed it did both MUT and MUTSE. MUT opens effectively in IE, can even hit f12 for development tools. It has a similar looking interface/landing page.
Database wise there two clusters of databases created. It' snot clear to me if one is for MUTSE and one for MUT, both for one, or both for both. CAESAR is one group of Database, only 2. The other is about 20 different databases many with same table structure but a few with variations. Lots of empty tables.
On the install, on C:\ do you have MUTSW or MUTSW_SE or both? The javascript is under MUTSW/MUT3/MENU/SCRIPTS
The .ocx binaries that are loaded as activex controls are under SYSTEM --- I think these be the crown jewels to crack open or fool into a debug mode to spit out all the details
There is also various .mdb databases opened.
A sampling of the file types(Just top few by count)
Code:
count extension
1377 css
2213 msg
2494 js
4205 htm
7952 csv
12070 png
23425 vdbWhat I can gather is the javascript is the entire GUI that you navigate. It can load a half dozen different activex controls which are .ocx binaries which I have not found a way to decompile.
I have not found any instance where the javascript is compiling the actual DATA hex to be sent. The javascript does more like:
MutCanDiag1.InitCarInfo(g_CanBusID) and process the response as success/failure.
It can also ask to read some of the local file based databases (.mdb) for information such as based on vin lookup. To get things like canbusID, constitutionnumber, etc. Looking at the MSSQL databases these references are also there.
I have been able to load for example the Miev Diagnostic page, you can add returns to the ErrMsg functions that are gernically called on comm errors to VCI. Unfortunately I have yet to find a way to get it ti spit out the actual data/command being issued to the car. So i'm only seeing the GUI screen progression :-/
Is it possible MUT is using the K-Line to actuate things? Or even the folks that have 'solved' this without sharing? K-Line is available on the OBD port but i've not found anyone that has explored it? I am not even sure how to monitor it
The Canedge2 I am receiving can monitor LIN bus but it's not clear to me if K-Line / LIN is interchangeable or just very similar protocols? Another idea came last night, @kiev your icarsoft i909. The screens look very very similar to MUT on diag pages, etc. Can you trigger any actuations with it? That may be the easiest route is to buy one of those use a Y adapter and sniff it's traffic? Am I off that monitoring any sort of diagnostic device actuating something on the car be potentially repeatable/breakthrough? Was considering to order one of the Max iCarsoft which states it covers Mitsubishi, just to have for our vehicles in general -- so if it gives me a potential chance to sniff/reverse engineer i'll order it today
i think the i909 would have to send commands to read ecu Data Items, and to do a Clear of the DTC faults.
It is slow and clunky in that you have to page thru the list of available Data Items, 4 or 5 items per page, selecting the ones you want to see; then hit return and the selected list values are displayed. If you want to add or change to another DI, then you have to start over.
It is slow and clunky in that you have to page thru the list of available Data Items, 4 or 5 items per page, selecting the ones you want to see; then hit return and the selected list values are displayed. If you want to add or change to another DI, then you have to start over.
