Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

This is just a bunch of slides but a ton can still be learned from it. The target is an In-Vehicle Entertainment system that has things like Amazon Alexa and things built into it. The first part of the process was getting the code off of it to reverse engineer and getting a debuggable environment.

The flash chip was a BGA eMMC chip. So, they used a hot air reworking station to remove the chip, popped it into an adapter and got the firmware off of it. To get a debuggable environment, they reverse engineered a bunch of settings for a secret debug menu and added a missing 0-ohm resistor but were shut out by a good password they couldn't crack.

Eventually, they just live patched the running memory of the chip to change /etc/shadow to get a shell. They also tried reprogramming the chip but bricked one of their devices trying to do this.

The device had an insecure HTTPs certificate handling on a request to api.sports.gracenote.com. By hosting a malicious DHCP server with attacker controlled DNS, they could interact with this service. On this server, there was a directory traversal arbitrary write vulnerability that allowed for writing arbitrary files.

Most of the system contained a read-only filesystem. Many of the mounts were even noexec. They found that the file pkcs11.txt allowed for the configuration of shared objects with a file path. Additionally, there was a mounted USB that was missing the noexec flag.

Using this configuration file, it was possible to load arbitrary .so/code> libraries. Of course, they could write this library to the USB. The only problem was that this wasn't changed right away; it was set at boot time of the device. Eventually, they found that by writing to /usr/local/bin/Media in a particular way the device would reboot. To go to root, they used an n-day kernel exploit.