Good job! DLT logs are pretty standard in the infotainment industry, the format specification is openly available. I recommend you to download DLTViewer from GitHub and open the log files (if they are not encrypted). You may find good stuff there!
You are right. Last year I've got a virus named covid (probably you have heard of it). For a few days I've lost the taste of food. I mostly stopped to eat in such days. Eating food that tasted of nothing was totally unpleasant!
This is not how odometers are scammed. The EEPROM gets rewritten to zero, then you can increment the odometer to your preferred value via OBD/UDS. Please note that you can only increment the odometer without a specialized (authenticated) diagnostic session.
FYI I do not reset odometers, I am on the other side, developing software for instrument clusters.
Deleting the DTCs is really trivial. It's just a standard UDS command. The only way to avoid this kind of scam is buying vehicles that have done the official maintenance/inspection. That will report the odometer to the car maker.
Additionally, the composition of certified products does not lead to a certified product. Even adding an enclosure around a certified board implies the recertification.
Think of the Linux kernel. That's a huge project, organized in an object oriented fashion. Is there a difference between this->method(arg) and method(this, arg)?
> We must not use [...] Qt Creator [...] to build software using Qt LGPL-3.0 or Qt GPL. It doesn’t matter whether these tools are also available under a non-commercial Qt license.
This is the weirdest part of Qt licensing for me. An IDE is an IDE, you should not care what I develop with it. I don't even understand how is that possible, since Qt Creator is GPL3.
OBD is a diagnostic bus. On modern car the access is authenticated on several layers (eg. guest, carmaker, ECU supplier). I would not call that interesting. Accessing a CAN/FlexRay/LIN/Eth bus is better.
It's repair versus buy. If you cut the power cord of your dishwasher, you can buy a new dishwasher from Bosch for 900€, or ask a 3rd party to repair it for 25€. I don't see any "fuck Bosch" logic here.
Actually there still are a lot of Windows ECUs in the wild. I analyzed the update packets of newer cars than mine (equipped with Uconnect) finding even sndrec.exe and the default page of IIS!
Fortunately my company produces Linux-based ECUs, and we use Windows only for Autosar stuff.
I just do not like self promotion. My employer does not care of my posts, they were published before signing my current contract. I have stopped writing posts by myself since I have now access to tons of documents and specifications.
The infotainment of the car maker had some oddities:
* the binaries were signed with a certificate emitted by a big certification company, repacking an update package could be challenging
* the system ran a fork of Windows CE and was co-developed with Microsoft
* the SoC documentation was only available under NDA (I was able to find only a one page datasheet)
For those reasons, instead of trying to repack the software for the original ECU, I started to sniff the CAN traffic and analyzing the binaries contained in the software update packages found online. That allowed me to reimplement the communication with other ECUs on a Linux SBC.
Kudos to the author! I did some research in my car a few years ago. Unfortunately, the update packages were properly signed. So I reversed the CAN traffic and replaced the infotainment ECU with my own reimplementation. I published my work and findings on medium thinking that nobody could notice them... I have got a job in the automotive industry instead.
This old trick is still in use nowadays. However, instead of shipping a tape I have seen a colleague uploading a zip corrupted by hand, just two gain a couple of days of bug fixing.
My 2011 car has ECUs for: engine, brakes, ABS, air bag, air conditioning, alarm. All of those are connected to a gateway, that is another ECU.
Do you want parking sensors? That's another ECU. Multimedia? That's one or two.
Cars of 2000 have not much less ECUs. Consider also that components to build such ECUs are now totally obsolete and out of production.
In my opinion the best way to do kernel development is to just look at device drivers in kernel sources, study what current drivers do and write your own driver.
The kernel supports su much heterogeneous devices and its APIs change continuously that it is practically impossible to write a complete guide on this topic.
I work in the automotive. I think that this is the trend. At the begin, smartphone projection was just calls, music and navigation. Now such systems are interested in signals coming from the car.. guess why!
That's unrealistic. A car contains several ECUs. Each ECU has one or more MCU/CPU. Every core runs its software, 99% of the time documentation is available only under NDA.
Reimplementing the software for just one MCU/CPU is challenging even for who is part of the industry.