Last updated at Thu, 21 Oct 2021 14:11:39 GMT
This year, Rapid7 participated at the IoT Village during DefCon29 by running a hands-on hardware hacking exercise, with the goal of exposing attendees to concepts and methods for IoT hacking. Over the years, these exercises have covered several different embedded device topics, including how to use a Logic Analyzer, extracting firmware, and gaining root access to an embedded IoT device.
This year's exercise focused on the latter and covered the following aspects:
- Interaction with Universal Asynchronous Receiver Transmitter (UART)
- Escaping the boot process to gain access to a U-Boot console
- Modification of U-Boot environment variables
- Monitoring system console during boot process for information
- Accessing failsafe (single-user mode)
- Mounting UBIFS partitions
- Modifying file system for root access
While at DefCon, we had many IoT Village attendees request a copy of our exercise manual, so I decided to create a series of in-depth write-ups about the exercise we ran there, with better explanation of several of these key topic areas. Over the course of four posts, we'll detail the exercise and add some expanded context to answer several questions and expand on the discussion we had with attendees at this year's DefCon IoT Village.
The device we used in our exercise was a Luma Mesh WiFi device. The only change I made to the Luma devices for the exercise was to modify the U-Boot environment variables and add console=off to the bootargs variable to disable the console. I did this to add more complexity to the exercise and show a state that is often encountered.
Identify UART
One of the first steps in gaining root access to an IoT device is to identify possible entry points, such as a UART connection. In the case of our exercise, we performed this ahead of time by locating the UART connection and soldering a 2.54 mm header onto the board. This helped streamline the exercise, so attendees could complete it in a reasonable timeframe. However, the typical method to do this is to examine the device's circuit board looking for an empty header, as in the example shown in Figure 1:
This example shows 4 port headers. Although 4 port headers are common for UART, it is not always the rule. UART connections can be included in larger port headers or may not even have an exposed header. So, when you find a header that you believe to be UART, you'll need to validate it.
To do this, we first recommend soldering male pins into the exposed socket. This will allow easier connectivity of test equipment. An example of this is shown in Figure 2:
Once you've installed a header, I recommend using a logic analyzer to examine the connection for UART data. There are many different logic analyzers available on the market, which range in value from $12 or $15 to hundreds of dollars. In my case, I prefer using a Saleae logic analyzer.
The next step is to identify if any of the header pins are ground. To do this, first make sure the device is powered off. Then, you can use a multimeter set on continuity check and attach the ground lead “Black" to one of the metal shields covering various components on the circuit board, or one of the screws used to hold the circuit board in the cases — both often are found to be electrical ground.
Next, touch each pin in the header with the positive lead “Red" until the multimeter makes a ringing noise. This will indicate which pin is electrically ground. Once you've identified ground, you can attach the Logic Analyzer ground to that header pin and then connect the logic channel leads to the remaining pins, as shown in Figure 3:
Once hooked up, make sure the appropriate analyzer software is installed and running. In my case, I used Saleae's Logic2. You can then power on the device and capture data on this header to analyze and identify:
- Whether or not this header is UART
- What the baud rate is
- Which pin is transmit
- Which pin is receive
As shown in the capture example in Figure 4, I captured 30 seconds of data during power-up of the device for channel 0 and 1. Here, we can see that data is shown on pin 1, which in this case indicates that channel 1, if determined to be UART, is most likely connected to the transmit pin. Since we are not sending any data to the device, channel 0 should show nothing, indicating it is most likely the receive pin.
The next step is to make a final determination as to whether this is a UART header? If so, what is the baud rate?
We'll cover this and the subsequent steps in our next post. Check back next week for more!
