How to easily obtain vehicle speed?

[hackers365]

I want to obtain speed, gear and other information through the car headunit instead of obd2 hardware. Is there an easy way?

[librick]

Hey! Thanks for the question.

I'm not sure. I know I was able to determine whether the car was in reverse or not by looking at the status of a specific GPIO pin. You can read the status of GPIO pins by reading "files" at /sys/class/gpio.

I always intended to do more reverse engineering to see if I could write a small native library for getting vehicle speed/gear/etc (broadly called telematics) from the CAN bus.

If I had access to a list of CAN IDs for the 2021 Civic, I could probably look through the native libraries using a tool like Ghidra to see what native libraries reference which CAN IDs, and from there figure out how to write new software to read from the CAN bus. But I never got that far. Feel free to take a crack at it though! Thanks for your interest in the repo.

[librick]

Also, this chip is on board somewhere https://github.com/librick/ic1101/blob/main/datasheets/a3g4250d-MEMS-motion-sensor-3-axis-digital-output-gyroscope.pdf I'm not sure exactly if/how it interfaces with Android, but if it's just I2C and you're familiar with Android I2C programming you might be able to talk to it

[hackers365]

Hey! Thanks for the question.

I'm not sure. I know I was able to determine whether the car was in reverse or not by looking at the status of a specific GPIO pin. You can read the status of GPIO pins by reading "files" at /sys/class/gpio.

I always intended to do more reverse engineering to see if I could write a small native library for getting vehicle speed/gear/etc (broadly called telematics) from the CAN bus.

If I had access to a list of CAN IDs for the 2021 Civic, I could probably look through the native libraries using a tool like Ghidra to see what native libraries reference which CAN IDs, and from there figure out how to write new software to read from the CAN bus. But I never got that far. Feel free to take a crack at it though! Thanks for your interest in the repo.

My original goal was to use an ESP32 round screen with an OBD2 device to create a speedometer and information display.

By chance, I discovered that the 'Honda Hack' app can unlock the Honda head unit and retrieve data such as speed, gear position, voltage, and coolant temperature, projecting it onto the dashboard. This made me wonder if it’s possible to obtain this data directly from the head unit without needing OBD2 hardware. Using JADX, I reverse-engineered the HondaHack-7.0.1-release.apk ('http://www.autohack.cn/app/HondaHack-7.0.1-release.apk') and found that it uses Android bound services to retrieve this data.

bind service

a("com.mitsubishielectric.ada.appservice.avapservice.IAvApService"); a("com.mitsubishielectric.ada.appservice.vehicleinfomanager.IVehicleInfoManagerApService"); a("com.mitsubishielectric.ada.appservice.camera.ICameraAPService"); a("com.mitsubishielectric.ada.appservice.videomanager.IVideoManagerApService");

However, I don’t have Android development experience, so I can't delve further into the research.

[librick]

Ah, very cool. And thanks for the link! Feel free to make a PR to link to the app from this repo, it'd probably be useful for others.

Yea, there are several Android services that start with that prefix, com.mitsubishielectric.ada.appservice. Those are defined in APKs that are on the headunit within the Android filesystem. I forget exactly where; I think by convention they're in /vendor/app/.

I have a list of those APKs here: https://github.com/librick/ic1101/blob/main/docs/apk-hashes.md. I have the original files too but I haven't uploaded them for copyright reasons. Maybe they'll end up as a torrent sometime but I'm not condoning piracy in any way blah blah blah

Take com.mitsubishielectric.ada.appservice.vehicleinfomanager.IVehicleInfoManagerApService as an example. I think this is defined by the VehicleInfoManager.apk. By using apktool to extract it, I see this manifest:

<?xml version="1.0" encoding="utf-8" standalone="no"?><manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.mitsubishielectric.ada.appservice.vehicleinfomanager">
    <uses-permission android:name="com.mitsubishielectric.ada.permission.VEHICLE_RW"/>
    <application android:label="@string/app_name" android:persistent="true">
        <uses-library android:name="com.mitsubishielectric.ada.appservice.powermanager.lib"/>
        <uses-library android:name="com.mitsubishielectric.ada.appservice.vehicleinfomanager.lib"/>
        <uses-library android:name="com.mitsubishielectric.ada.appservice.unitinfomanager.lib"/>
        <uses-library android:name="com.mitsubishielectric.ada.framework.cpucomservice.lib"/>
        <uses-library android:name="com.mitsubishielectric.ada.framework.vehicledbmanager.lib"/>
        <uses-library android:name="com.mitsubishielectric.ada.util.explog.lib"/>
        <uses-library android:name="com.mitsubishielectric.ada.util.constext.lib"/>
        <service android:name="com.mitsubishielectric.ada.appservice.vehicleinfomanager.VehicleInfoManagerApService">
            <intent-filter>
                <action android:name="com.mitsubishielectric.ada.appservice.vehicleinfomanager.IVehicleInfoManagerApService"/>
                <category android:name="android.intent.category.DEFAULT"/>
            </intent-filter>
        </service>
    </application>
</manifest>

There aren't any views or UI elements here, it's just a persistent service. Also note all of the uses-library calls. These are native libraries (i.e., written in C, C++ and compiled for the ARM7 architecture of the Tegra 3 SoC). I think by convention they're in /vendor/lib/.

So basically, most of the telematics code is written in C or C++ as native libraries, then Android services act as thin wrappers on top of those native libraries, and then Android apps can use those services to get information about the car.

It would definitely be cool to map out what public methods those services expose so developers could write apps on top of them.

[librick]

I should probably add a doc at some point with tips on reverse engineering the Mitsubishi-developed native libraries using a tool like Ghidra. I've found the following:

• A lot of methods in the code includes calls to logger functions which sometimes include the original method name and arguments
• You can cross-reference a lot with the Android kernel source code for Android 4.2.2 to get an idea of which syscalls a given library makes

I think it'd be great to have something like a decompilation project for Honda cars at some point, similar to what we've seen with video games. In my mind it'd really open up headunit hacking

[librick]

Check out https://raw.githubusercontent.com/librick/ic1101/refs/heads/main/docs/native-libs.md

[librick]

libcpu_com_service_jni.so is probably the most interesting. It's exposed via an Android service com.mitsubishielectric.ada.framework.cpucomservice, which has this manifest:

<?xml version="1.0" encoding="utf-8" standalone="no"?><manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.mitsubishielectric.ada.framework.cpucomservice">
    <application android:label="@string/app_name" android:persistent="true">
        <uses-library android:name="com.mitsubishielectric.ada.util.explog.lib"/>
        <uses-library android:name="com.mitsubishielectric.ada.util.constext.lib"/>
        <uses-library android:name="com.mitsubishielectric.ada.framework.cpucomservice.lib"/>
        <service android:exported="true" android:label="@string/app_name" android:name="com.mitsubishielectric.ada.framework.cpucomservice.CpuComService" android:permission="com.mitsubishielectric.ada.permission.VEHICLE_RW">
            <intent-filter>
                <action android:name="com.mitsubishielectric.ada.framework.cpucomservice.ICpuComService"/>
            </intent-filter>
        </service>
    </application>
    <uses-permission android:name="com.mitsubishielectric.ada.permission.VEHICLE_RW"/>
</manifest>

And the underlying library com.mitsubishielectric.ada.framework.cpucomservice exposes a few methods that look very useful:

• Java_com_mitsubishielectric_ada_framework_cpucomservice_CpuComService_doRequestBcanReceiveData
• Java_com_mitsubishielectric_ada_framework_cpucomservice_CpuComService_doRequestFcanReceiveData
• Java_com_mitsubishielectric_ada_framework_cpucomservice_CpuComService_doRequestVehicleSpeedInfo