On APKs, RATs and Security Vulnerabilities - HondaHack

I've recently been looking into the capabilities of embedded Android Devices in-vehicle dashboards. A lot of these are fairly expansive and well-integrated solutions that offer consumers a reasonable experience, given that a good portion of these tends to be underpowered Android tablets.

Looking around for what sort of apps and rooting techniques exist for these devices, I ran across a thread on XDA, that listed instructions for how to enable developer mode on new model Honda Civics. The thread also linked APKs that allowed the user access to additional features. My curiosity motivated me to figure out how this worked. Did they have access to native libraries that allowed access to the driver's HUD in addition to the Dash? How did they gain access to systems like climate control?

Some exploratory work was in order. I fired up d2j and jd and decided to a peek inside.

The first thing I noticed was the curious package naming. com.tencent suggests some origins in China. While this is not a red flag by itself. It lends a clue into some of the history of the application.

However, what stood out, even more, were the existence of the TxAppEntry and TxReceiver classes.

Looking at the TxAppEntry class, this block of code sticks out,

It seems that it allocates some disk space and loads a few native libraries, particularly libshella.so, libshellb.so and libshellc.so. I had not heard about these previously, so I spent a bit of time looking these up, and what I found was a blog post by someone far more knowledgeable than I am on the subject matter. I highly recommend reading the entire post. The author goes into a lot of detail on how the Remote Access Tool (RAT) actually works.

The TL;DR is that this allows for remote code execution by unarchiving and loading a remote/hidden DEX file.

There has been some discussion about this with the HondaHacks author, I defer to the thread for more information.

However, I think this merits some consideration from the perspective of the users and the OEMs. From the user's perspective, being given access to what is effectively a fully operational android device was probably a good chunk of the value proposition for the vehicle. With that in mind providing a safe sandbox for user customization and experimentation could have been an interesting angle to take. One that builds an ecosystem around developing automotive apps for their brand. The good news is that there is some discussion around this on the inevitability of the Tesla app store. I think it says a lot and is a missed opportunity for vehicle OEMs, in this case, Honda, considering that their products do have Wifi connectivity and the same infotainment dash has been in a family of products running for at least 3 years. If a chunk of your users resort to installing untrusted software they find on the internet to customize their product, it should merit at least some consideration and experimentation to allow them to do this safely. Perhaps the next Android Auto iteration is a step in this direction.

In conclusion, and I think this goes without saying. Installing random software from an untrusted source on the internet is almost always a bad idea. Especially one off of a random message board. In this particular scenario, HondaHack is not software I recommend anyone install - at least not the version that I tinkered with. This is because of the glaring security issues, the fact that it is not open source to allow for an audit, and there is no trusted way of distributing binaries and versions that do not require that the user open a huge backdoor on their device. I understand the need to make money off of one's work, however, there are other ways to securely distribute software especially within a fairly technical audience.