Ok, why all this Win32 nonsense. I'm totally happy coding on Linux as it is, so why learn all aforementioned stuff? First, I'm gonna tell you a riddle: What's the difference between sardine can and Sardine CAN?
¨
On the right you can see John West sardine can. The sardines are submersed in a delicious tomato sauce and deliver 164kcal per 100g of energy. Good for recuperating from the flu.
And then on the left there's Sardine CAN by Olaf's Hacking Volvo labs. Included currently is a firmware version 01.00, offering part of SAE J2534-1 functionality and a bit of J2534-2.
So, what are these useful for? The SAE J2534 is an industry standard that defines how third-party software can be used to communicate with automobile ECUs in a hardware independent way. Buy any (expensive) J2534 flash/diagnostic tools and what you get is their proprietary software for diagnostics, supplemented with a standard J2534 API (Win32 DLL) that uses the hardware supplied to communicate with the car via its OBD port. The API offers various protocols (ISO9141, CAN, ISO 15765, J1850 and so on) and thus lets third party applications to send and receive messages without having to know anything about what happens between the API and the communication stack of ECU - it's all transparent.
Now, what is interesting is that some car manufacturers (including Volvo) have in their diagnostic software a possibility to use communication tools other than the one supplied. First they parse the Windows registry for entries related to J2534 devices. Usually they offer the user a list of available devices, then load the DLL associated with the device and start using its services. VIDA (Vehicle Information and Diagnostics application) from Volvo is one of these applications, and its J2534 support enables us to use it without the related hardware, the DiCE (Diagnostic Communication Equipment). With VIDA, you can browse all the ECUs in the car (including CPM, the module responsible for the parking heater!) and send diagnostic commands to test their functionality. And the logical conclusion would be, of course, that if these commands could be intercepted, then the command for turning on the parking heater might be found :)
There are plethora of J2534 devices, most of them quite expensive (1000+ euros). There are also some cheap chinese copies selling for 100-200 euros, but there's no guarantee of them working out of the box, and I wouldn't like the idea of spending my free weekend diagnosing the diagnostic tool. There are absolutely no open source or freeware solutions available, so my last option would be to tackle this beast on my own. I got ahold of J2534-1 and J2534-2 standards documents and started hacking. And after few days full of dizzy coding sessions with viral headache enhanced with nausea from Hungarian notation, this is the result:
VIDA can now recognize the Sardine CAN tool and send VIN (Vehicle information number) query via CAN bus :) Actually the command seen in the first picture is one of the messages sent by Vida. However I haven't yet been able to access the diagnostics part of Vida, since it seems to require proper response from ECU in order to function correctly. I've implemented most of the CAN bus related stuff on J2534 (including sending periodic messages), as well as some of the ISO 15765 flow control in order for VIDA to receive long CAN messages, where payload length>8 (such as the VIN), but lower level pass/block filtering is yet to be done. So connecting Sardine CAN to car in its current form would flood the VIDA with unrelated messages. There's still quite a lot to do, but sending and receiving messages using Drewtech's free J2534 tool already works though, so I'm confident that after few days of tinkering I might able to give this monster a shot at the car itself.
BTW. I'm releasing the software as open source after I get this reasonably stable and functioning. This still needs quite a bit of work to be useful to anybody and frankly, I'm little bit embarrassed at the Win32 specific portions of the software (related to my few days worth of programming experience on the platform), so I'm not yet ready to open this to the world. But anyway, if you're interested in alpha testing and have reasonable debugging skills, I might make an exception and let you test this tool before it hits SourceForge.
Sardine power!
Hi Olaf,
ReplyDeletewhat has become of this project? I'm interested in communicating with a J2534 Pass-Thru interface from iOS and/or macOS, so the Win32-DLL is completely uninteresting for me as well. Did you publish any source code yet? Would love to try with my ScanDoc Compact device.
Also interested in where you landed with all of this. Do you have any tips for keeping the DIM alive while bench testing? It wants to go to "sleep" after sending 127 messages. I've tried sending messages that appeared to mimic CEM messages, but no dice! (get it?)
ReplyDeleteHi, I am working on the powerup of the DIM on the bench as well. I am not as far as you but would like to be. Could you share how you powered your DIM? Mine does not power on with just a power source. It is from an 07 s60.
DeleteThanks a bunch!
This comment has been removed by the author.
ReplyDeletehttps://www.hackerone.com/for-hackers/how-to-start-hacking Join the world’s largest community of ethical hackers and start hacking today! Be challenged and earn rewarding bounties. Learn more!
ReplyDelete