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!

Pwn2Own has an automotive category for hacking cars. They decided to tackle the CHARX system because A) the product was very different from other similar products and B) the firmware was easy to obtain. It runs an embedded Linux on 32-bit ARM with SSH enabled for easy access.

Much of the code on the system was compiled Python but they did find the Controller Service Agent that was written in C++. This device communicated between the various CHARX units, managed AC and a vehicle to grid protocol with comms over UDP, TCP and HomePlug Green PHY protocol.

Much of the code on the system was compiled Python but they did find the Controller Service Agent that was written in C++. This device communicated between the various CHARX units, managed AC and a vehicle to grid protocol with comms over UDP, TCP and HomePlug Green PHY protocol.

The first vulnerability they found was a null pointer dereference in the HomePlug Green PHY protocol. The parsing code for the minimal implementation was reading the size of a structure at bytes 4 and 5 instead of 5 and 6. As a result, some parsing goes haywire and eventually leads to a null pointer deref. Off by one strikes again!

The second bug is more interesting. While using GDB, they found that the exit handlers were causing crashes to happen. In the C++ binary, many of the exit handlers are implicitly added by the compiler as static. Since these are global, the exit handlers need to close it out. Additionally, the binary has several signal handlers as well.

The exit handlers for static objects seem to appear in random orders when not specified. The authors give a toy example where the destructor of one object type runs after another object type. Since the ordering is weird in this case, if one objects interactions with the other it can lead to a UAF!

In the Controller Agent code, this exact bug occurs in a more complicated way. A list is already gone but trying to be accessed, leading to a UAF! Since we want this destructor to happen at will, the null pointer deference is a a perfect bug for us. In the second post, they go through the exploitation of this bug.