The goal and target

BroadLink RM Pro Smart Remote Control

The target device is the BroadLink RM Pro universal remote control designed for home convenience and automation.

This smart remote control can be used to control multiple home appliances through its application. It also allows users to create scenarios whereby multiple actions can be programmed and activated simultaneously. Device setup and functionality is accessed through the BroadLink e-Control application. This application must be running on a device connected to the same Wi-Fi network as the smart remote and the appliance you want to control.

BroadLink e-Control application

For the purpose of this challenge, setting up the device is required. In a real scenario, the device would likely already be set up.

Start by connecting the smart remote to a Wi-Fi network and entering the Wi-Fi SSID and Passphrase within the e-Controls application. The application then subsequently tries to locate the device within the network and once it is found, a connection is established.

Now that the smart remote is functional, an attacker who has physical access to the device may attempt to extract configuration or sensitive information loaded in memory. Successfully replicating this attack scenario is the main goal of this challenge.

Taking a look inside

The first step is to investigate the internal components of the device, starting by carefully taking apart the unit. There are three easily removable housing screws situated on the underside of the device.

Once opened, we can then identify different points of interest within the device. These can be internal or external ports, the board’s chips, components, model and serial numbers. Identifying the chip’s model and serial number is essential and will provide us with the information we need in latter stages.

Inside BroadLink RM Pro Smart remote

Looking for ways to communicate with the device is another key step. When working with embedded architectures, the presence of debug interfaces such as UART and JTAG is a common method used to establish serial connectivity to the device.

JTAG

Joint Test Action Group or more simply JTAG, is a standardised type of serial communication commonly used by engineers and developers to perform on-board testing or diagnostics of embedded devices, also known as boundary scanning. Another functionality of JTAG, which is seemingly more used today, is CPU level debugging allowing read-write access to registers and memory.

The JTAG interface uses four connection points also known as Test Access Port or TAP. These connection points correspond to four signals:

• TDI – Test Data In; this signal represents input data sent to the device
• TDO – Test Data Out, which represents output data from the device
• TCK – Test Clock, used to synchronise data from the TMS and TDI (rising edge of Test Clock) and TDO (falling edge of Test Clock)
• TMS – Test Mode Select; this signal is used to control the state of the TAP controller
• TRST – Test Reset; this is an optional signal used for resetting the TAP controller

Identifying JTAG pinouts

The implementation of JTAG is non-standardised, which means that the signal pinouts you may encounter will vary between devices. Aside from the standalone JTAG connection points, commonly seen JTAG interfaces may be a part of a 10 pin, 14 pin, 16 or 20 pin header.

JTAG pinouts

Looking closely at the device, the five connection points on the corner of the board is the JTAG interface. Using the JTAG’s debugging functionality should enable us to read and write data stored in memory.

Note: Some devices will have JTAG present but their connections will have been disabled before being released into production.

There are various tools available which can be used to identify JTAG signal pinouts, all of which vary in available features and pricing. Common examples are JTAGenum (for Arduino), JTAGulator and Hydrabus to name a few. For the purpose of this challenge, a JTAGulator is used. The JTAGulator supports a number of functionalities, including both the identification of UART and JTAG pinouts.

The JTAGulator

Connecting the JTAGulator

The JTAGulator is connected to the smart remote starting from the lowest number of channels/pins on the board (CH0-CH4). The lowest numbered pinouts are used due to the brute-force method used by the JTAGulator to identify the signal value for each pinout. Using the lowest pin number decreases the number of permutation to iterate through and ultimately speeds up the identification process.

JTAGulator connected to the device’s JTAG pins

Once connected, you can control using the JTAGulator via USB connection, which will appear as a serial interface. A number of terminal emulators such as PuTTY, Hyperterminal or Minicom can be used to interface with the JTAGulator. In this instance, we will use ‘screen’ utility, which is installed by default on many Linux distributions. It can be used to establish a serial connection to the JTAGulator via the default ttyUSB0 device in Linux machines. The JTAGulator’s baudrate of 115200 should also be provided like so:

$ sudo screen /dev/ttyUSB0 115200

Once a serial connection to the JTAGulator is established, pressing the ‘h’ key shows a list of JTAG commands available. The first step is to set the target voltage to 3.3V, which pertains to the voltage required by the microprocessor. 3.3V is commonly used by most chips; however, accurate information regarding the operational voltage can be found by looking through the chip’s specification sheet. Setting the correct voltage is important as an incorrect voltage could damage or destroy the device. After setting the voltage, the “Identify JTAG pinout (IDCODE Scan) can be used to identify JTAG pins, which works by reading the device IDs – specifically, TDO, TMS and TCK signals. To identify the TDI pin, the BYPASS scan is used.

When running the scans, enter the number of channels to use as five; this will allow the JTAGulator to use the connections made channels CH0 to CH4. The scans should complete fairly quickly as there are only five pins exposed in the board, resulting in a lower number of permutations to be made. If the JTAG implementation appears alongside multiple pinouts, this can increase the number of permutations, thus increasing the duration of the scan.

Identifying JTAG pinouts (BYPASS scan)

The result of the BYPASS scan show us the location of the signal pinouts on the JTAGulator, which corresponds to the signal pinouts on the smart remote.

You can skip this step entirely if the JTAG pinouts are labelled on the silkscreen print on the board, so do not forget to check both sides of the PCB, as it may save valuable time.

JTAG signal pinouts printed underneath the board

The Shikra

In order for us to get debug access on the smart remote, an interface and some form of OCD (On Chip Debugger) is required. Many devices on the market allow interfacing with JTAG to facilitate on chip debugging, such as Bus Pirate, Shikra and HydraBus. For this scenario, the Shikra and OpenOCD software are used.

The Shikra is an FT232H USB device sometimes referred to as the “Swiss army knife of hardware hacking”; this device allows us to connect to a number of data interfaces, including UART, JTAG and SPI. A Shikra can be purchased from Xipiter: https://int3.cc/products/the-shikra.

The Shikra

The following diagram shows the Shikra pinouts for JTAG, which will be used to connect to the board’s corresponding JTAG pinouts. Ensure that the ground (GND) pin is also connected to a ground point on the board.

Shikra JTAG connections http://www.xipiter.com/uploads/2/4/4/8/24485815/shikra_documentation.pdf

The Shikra giving serial to USB connectivity

OpenOCD

OpenOCD allows us to perform on-chip debugging of the smart remote via JTAG using GDB. In Linux-based systems, you can install the OpenOCD package by running the following command:

$ sudo apt-get install openocd

In order for us to use OpenOCD, a configuration file for the interface (Shikra) and the target (Smart remote) are required. OpenOCD comes with a number of pre-installed interface and target configuration files; however, the one required does not come in the pre-installed list. The configuration file for the adapter can be found in Xipiter’s getting started guide for the Shikra.

Shikra OpenOCD configuration file:

#shikra.cfg
interface ftdi
ftdi_vid_pid 0x0403 0x6014

ftdi_layout_init 0x0c08 0x0f1b
adapter_khz 2000
#end shikra.cfg

Obtaining the configuration file for the target was not as straight forward. The configuration file required was not available within the pre-installed configuration files and attempting to use any of them results in compatibility errors with the device.

The approach taken in identifying the appropriate target configuration file involved looking up the microprocessor’s make and model. Using a magnifying glass or a good enough camera, the specific chip printings can be determined. The chip in question is a Marvell 88MC200 and a simple Google search of this chip and the keyword OpenOCD returns the target configuration needed.

#
# Marvell's Wireless Microcontroller Platform (88MC200)
#
# https://origin-www.marvell.com/microcontrollers/wi-fi-microcontroller-platform/
#

#source [find interface/ftdi/mc200.cfg]

if " [info exists CHIPNAME] " "
   set  _CHIPNAME $CHIPNAME
" else "
   set  _CHIPNAME mc200
"

set  _ENDIAN little

# Work-area is a space in RAM used for flash programming
# By default use 16kB
if " [info exists WORKAREASIZE] " "
   set  _WORKAREASIZE $WORKAREASIZE
" else "
   set  _WORKAREASIZE 0x4000
"

# JTAG scan chain
if " [info exists CPUTAPID ] " "
   set _CPUTAPID $CPUTAPID
" else "
   set _CPUTAPID 0x4ba00477
"

jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID

set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME cortex_m -endian $_ENDIAN -chain-position $_TARGETNAME
$_TARGETNAME configure -work-area-phys 0x2001C000 -work-area-size $_WORKAREASIZE -work-area-backup 0

# Flash bank
set _FLASHNAME $_CHIPNAME.flash
flash bank $_FLASHNAME mrvlqspi 0x0 0 0 0 $_TARGETNAME 0x46010000

# JTAG speed should be <= F_CPU/6. F_CPU after reset is 32MHz
# so use F_JTAG = 3MHz
adapter_khz 3000
adapter_nsrst_delay 100
if "[using_jtag]" "
 jtag_ntrst_delay 100
"

if "![using_hla]" "
   # if srst is not fitted use SYSRESETREQ to
   # perform a soft reset
   cortex_m reset_config sysresetreq
"

The above configuration file was pointing to an interface path (line 7) which in our case was not required and therefore has been commented out. The interface configuration file previously downloaded will be used instead and the file location specified as a command line argument in OpenOCD.

Once both target and interface configuration files are saved locally, run the following OpenOCD command:

$ openocd -f /usr/share/openocd/scripts/interface/shikra.cfg -f /usr/share/openocd/scripts/target/mc200.cfg

The file path points to shikra.cfg file, which contains the interface configuration and mc200.cfg contains the target board configuration.

The on-chip debugger should now be running as a server and will open local port 4444 on your system. You can then simply connect to this port with Telnet:

$ telnet localhost 4444

Dumping the device memory

Once connected, debug access to the board is now possible and allows control of registers and memory address.

Before the registers can be accessed, sending a halt request is required to send the target into a debugging state. After sending the halt request, the reg command is used to view all of the available registers and its values on the device’s CPU. The full list of useful commands is available in the OpenOCD documentation.

Registers values shown in OpenOCD

Highlighted in the above image is the Stack Pointer (SP) register. Discussing how computer addressing works is beyond the scope of this blog (it is not a simple subject!). For now, it is enough to understand that the location of the Stack Pointer contains the last value pushed onto the stack of things in memory (RAM), serving as the starting address from where user space memory can be accessed.

Going back to the original goal of extracting sensitive information from the device, the “dump_image” command can be used to dump memory content (in hex). To successfully dump as much information as possible, a trial and error approach to identify the boundaries of user space memory can be taken.

The dump_image command can be used as follows:

$ dump_image img_out2 0x20002898 120000

The img_out2 argument is the output filename; the next argument is the Stack Pointer address and finally the amount of memory to dump in bytes.

Dumping memory to a file

The image above shows that initial attempts at dumping memory may fail if a larger amount of bytes than what is available is specified.

After successfully dumping the contents of memory in hex, an analysis of the file can be performed to identify any information that might be of interest.

Wi-Fi passphrase next to the SSID

A hex editor of your choice can be used to navigate around the contents of the file and in the example above, we have used Ghex. Looking around the file and by performing a quick search, we can see the SSID name the device is connected to. 18 bytes after it, the passphrase was also shown.

If we had purchased this device second-hand, then we could potentially use it to access someone’s home network and launch further attacks.

Conclusion

Cyber attacks on smart home devices should now be recognised by home consumers, as well as the risks posed should these devices be sold or stolen. On the other hand, manufacturers should consider methods for securing the hardware aspect – the very foundation of these devices – to ensure the security and privacy of its users.

Cisco’s hardware hacking challenges gives us the opportunity to learn different methods to tamper or attack a device, therefore promoting a greater understanding of the security risks and controls they present. This post has presented a simple proof-of-concept attack on a consumer smart device, whereby a user’s Wi-Fi passphrase can be extracted and therefore allow an attacker to achieve persistent access to a victim’s network. This type of attack can be prevented by disabling – or more effectively – removing the JTAG ports completely from production devices, thereby minimising its attack surface.

The post JTAG on-chip debugging: Extracting passwords from memory appeared first on Portcullis Labs.

Various researchers have documented attacks against vehicle sensors and cyber-physical systems resulting in the vehicle performing unwanted actions, such as falsifying alerts, malfunction and even causing the vehicle to crash. The very same sensors which are used to improve driver efficiency have been proven vulnerable to both spoofing and signal jamming attacks. In this blog entry, we will be focusing on the reliability of a vehicle’s underlying systems, it’s susceptibility to spoofing attacks, and in particular the vulnerabilities in the front-facing camera, to ascertain how these problems may be addressed.

The problem

Multiple cameras can be found in today’s vehicles, some of which provide a full 360 view of their surroundings. One of the most common uses for these cameras is for road traffic sign detection. The traffic sign is picked up by the vehicle’s camera and displayed at eye level within the instrument cluster for the driver’s convenience. This is designed to reduce the potential consequences of a driver failing to recognise a traffic sign.

Professors from Zhejiang University and the University of South Carolina recently presented a whitepaper detailing the countless attack scenarios against vehicle sensors and front-facing cameras. With regards to vehicle cameras, their experiment focused on blinding the camera using multiple easily obtained light sources, which proved to be successful.

Our experiment, on the other hand, looked into fooling the vehicle’s camera in order to present false information to the driver.

We started off by printing different highway speed signs on plain paper, some of which contained arbitrary values, such as null bytes (%00) and letters. The print-outs were then held up by hand as our test vehicle closely drove past. As expected, the camera detected our improvised road signs and displayed the value to the driver. Spoofing speed values of up to 130 mph was possible, despite being way beyond the nation’s speed limit. Does this mean we can now exceed the speed limit? Naturally, abiding by the highway code still comes first, but it does beg the question of why something this farcical can still occur.

Although one could argue that the camera has done its job and detected what appears to be a valid road sign, there are no additional checks being performed to distinguish whether the detected sign is legitimate or even sensible.

Other scenarios to consider involve the use of intelligent speed limiters which are now present in some vehicles. Both the front-facing camera and built in speed limiter are used to limit your driving speed to the speed sign recognised by the camera, preventing you from exceeding the limit even if you were to floor the accelerator. In a car with that functionality, what would happen if a 20 mph sign was spoofed onto the camera while driving on a 70 mph limit motorway? We are yet to test this specific scenario, but a potentially dangerous outcome is easy to imagine.

What could be done to mitigate this problem?

We need some form of validation against sensory input. If we review and compare the advancements in securing biometrics, specifically fingerprint authentication devices, we can see that these devices are constantly bettered by incorporating new features, such as “life detection”, which detects the subtle conductivity a finger possesses thus preventing spoofing and finger cloning attacks. Could we implement a similar approach to securing vehicle sensors? Proper validation of the authenticity of each detected road sign would enable us to prevent spoofing attacks from occurring, but of course it is easier said than done.

What about introducing boundary detection? UK drivers know that 70mph is the absolute speed limit within the country, therefore the detection of speeds higher that this should be flagged as an error. A fixed boundary detection could, of course, prove unhelpful when driving in Europe, for example, where the speed limits are different, but this is easily fixed using GPS data or functionality enabling the driver to manually set the location as opposed to a global speed limit.

Independent researchers have even suggested novel ways to improve road sign detection systems using neural networks in order to learn and distinguish properties of legitimate road signs.

Conclusion

We have demonstrated that front-facing vehicle cameras used for traffic sign detection can easily be fooled into recording a false speed limit. While cameras do have an essential place in autonomous vehicles, their integrity and availability properties present a great deal of room for improvement. Even simple features and configuration changes, such as boundary detection, could be applied to increase the accuracy and efficiency of these systems. Further research into securing vehicle cameras needs to be conducted to ensure that spoofing attacks cannot be carried out as trivially as is currently possible.

The post Is your sign signed? appeared first on Portcullis Labs.