An important part of security activities carried out at Emaze involves testing from a security point of view the hardware of embedded devices like routers, access points, or even more security-sensitive devices. The focus of this kind of analysis is to find out how to access the internals of the device under analysis, interact with the underline system, modify its behavior and extract data in ways not intended by its normal functionality.
This can become a critical point if the device contains highly sensitive data which should not be available to the user (even if this is normally a sign there is something wrong in the design of the system, protocol or application!).
Most of these devices include a fairly powerful CPU (typically ARM or MIPS processor) with a discrete amount of RAM and flash and they typically a Linux kernel which opens them to being hacked. We want to share here some basic information on how to proceed and which tools can be used in this process.
Inspect and open the case
So the first step is to inspect the device and find a way to gain access to internal board for analysis.
Before doing this inspect the case and carefully watch if there are interesting external interfaces like a serial port or test points which are accessible without opening the device. In the latter case you can try to apply the same techniques used after having gained access to the board.
Usually the case is held together with screws or a snap-in mechanism, so it can be easily opened using common tools like a screwdriver. A snap-in case instead can be opened using a knife or a sharp screwdriver (the snap tabs can be located normally in the middle and near the corners).
It can happen sometimes that you find "exotic" screws (they are called "security" screws and have some strange shape) that are used as a antitamper mechanism. If you don't have the related screwdriver available (search on google first!) a brute force approach can be used, especially if you don't need to return back the device intact (which usually applies for this kind of activity). In this case you can just drill or cut the case.
It is less common on this devices to find tamper detection mechanisms (micro-switches or other sensors) which are meant not only to determine if a device has been tampered with but in some cases also to react. This is sometimes applied to avoid an attacker access sensitive data (like encryption keys) by erasing them or render the device non operational. One example is the famous IBM cryptographic coprocessor card: the key material is stored in a battery-backed RAM so that trying to gain access to the memory will result in power cut and data loss.
If you suspect (read the device documentation or warranty card, sometimes statements about tamper protection can be found) there is a protection mechanism in place a good route (unless you have more information available) is to have access to two devices. Sacrifice one and study the tamper protection to attack the second. Anyway unless the device you are dealing with contains particularly sensitive data (like the above crypto card) it's really hard that the protection mechanism is particularly sophisticated.
Board inspection
Now that you have access to the board you can start the inspection task to understand its structure, chips used, found and identify "communication" interfaces. The objective is not to get a full schematic of the circuit (i.e., the exact interconnection between all components) but just to identify most components and determine their functionality to target further analysis.
Unless removed (to counteract reverse engineering the device) chips have a marking with the part number, vendor logo and/or name. Some devices (mostly CPUs) can have an heatsink glued (remove it gently with a sharp screwdriver) or bolted to the PCB (in this case trying to desolder it is not suggested to avoid breaking circuit board, better try to cut bolts with a grinding tool). With this information at hand we can search for datasheet on vendor site (or just google for it). It can happen that there are epoxy protected areas (a clear indication of a particularly sensitive device) which are not easy to inspect. One way is to try to heat the epoxy and then carefully remove it using a sharp tool (avoiding to damage underlying parts).
PCB with marked parts (CPU, flash, RAM)
Sometimes chip datasheet is not available unless you sign an NDA and buy out big stocks (in terms of millions of parts probably!), and only a brief description on vendor site can be obtained. This gives at least some information about part functionality.
For the devices mentioned in the introduction we expect to find at least the following parts:
CPU
RAM
Flash (parallel and/or serial)
and since our interest is to interact with the system and inspect firmware to search for vulnerabilities or modify it we are going to search for signs of interfaces that can give us this kind of access. The most common and useful for our goal are serial ports and JTAG interfaces.
Inspecting the board we search for PCB headers or header mounting holes; these are commonly where interface signals are brought out to the outer world. You can also find (expecially if no header or header mounting hole is found) test points which are PCB pads (sometimes gold plated or tinned) used during the testing phase and programming at production factory.
Test pads
Header (serial port)
To ease subsequent steps it is a good idea to identify ground and power supply signals. To do this disconnect power supply, identify ground on the PCB (for example metal shield of USB connector, PSU connector ground, etc) and use a multimeter to find pins connected to ground.
Do the same for power suppy: identify VDD pin (power supply) of an easy to probe chip for which you have the datasheet and trace using the multimeter.
Having analyzed the board and gained some information from the components datasheet or information found on the Internet, we now try to find where interface signals are located.
If datasheet are available, we can trace part pins as done for ground and power supply following these steps:
Identify pins for the interface (serial port or jtag) from part datasheet
Locate them on chip package
Put the multimeter probe on one pin
Probe all identified points
This is doable if the part package has accessible pin (TQFP is an example) which is nowadays becoming a less common case. Most CPUs now are in BGA packages which means that connections from the die are below the package rendering them not easy to access. This kind of package has small solder spheres in a grid layout which are melted during soldering phase to connect to below PCB copper pads.
In this case we can use this technique for tracing signals: since the copper pad can be a via (a through hole path going to other PCB side) we can map the pins to the bottom side of the board and trace from there. If vias are protected with solder resist, they have to be gently scratched with a knife. A good lens is required during this process!
Another option which is applicable only to outer (respect to the package grid) signals is to build a probe with nichrome wire (used to build electric heating elements; a piece can be obtained from a non working hair dryer for example): tape a small piece of wire on multimeter probe and use it like a whisker pushing it below package. This is not easy of course and is prone to errors (since you will probably short circuit two solder balls) but with some trial it can be useful.
Of course it is not always required to performed this step (even if it will help in particularly difficult cases); as we see below for example a serial console can be identified in other ways.
Serial console
Serial port is commonly used in embedded systems as a communication interface to interact and control the device and since we are speaking of Linux based devices it is normally used as a system console. The console is also used by the bootloader (which initializes the system, loads the kernel from flash memory and boots it) so connecting to it will not only give system boot messages (and hopefully a system shell!) but also a way to interact with the boot process and possibly download/upload flash images.
Beware that in some systems the serial port is not initialized by the bootloader (to avoid this kind of hacks) typically by checking a value stored in flash or other condition: at production factory the port is used for device testing and programming, after this phase the value is changed to disable output on the port. This makes impossible to find and interact with the system unless the condition is changed which requires first reversing the bootloader (which can be obtained by reading the flash as explained below) to understand how to enable the serial console.
The serial port is directly connected to the CPU UART pins so it doesn't have any RS232 level (i.e., the electrical levels used to represent 0 and 1's) but uses cpu logic levels (near ground for 0, near VDD for 1 to simplify), so a level converter will be required. There are a lot around, be sure to select one that can work at you device VDD value. You can also find USB serial adapters which can be used (they just do not have the usual TTL to RS232 level conversion chip) or some cheap USB phone cable might be used (one example is Nokia CA-42 cable, clones are really cheap).
Using the previously gathered information, if UART pins were already traced, we can connect our level converter and using a terminal we can test different speed rates (common ones are 115200 and 9600) until we get something consistent. Power off and on the device in this process since normally the bootloader will start to spit out characters during boot.
If no pins have been traced one can try the same method by probing pins (before having controlled voltage levels to avoid damaging your serial adapter) but this can be a long process and prone to errors. The way is to probe pins with an oscilloscope (or a logic analyzer) and observe signal until a train of pulses which resembles a serial async signal is found. With a digital storage oscilloscope you can also measure pulse length and determine baud rate from it (e.g., 9600 baud has circa 1mS bit duration).
Missing the oscilloscope (it doesn't make sense to buy one just for one time search of a serial port) an Arduino board come to the rescue. Arduino is an easy to use and very cheap prototyping platform bases on AVR microcontroller which can be programmed just using the USB port. There are a lot of boards available (the design is open source and there are clones available) from different places. Since the microcontroller has an analog to digital converter, it can be used as a simple oscilloscope using the code and related PC application from xoscillo project. The speed of serial port signals is low enough to be sampled with this setup.
Once TXD (serial output signal from the CPU) is found permanently connect it and step to RXD. This is a little bit more tricky, the idea here is to send out characters (now that we have determined baud rate and can watch system output) and watch system behavior. In most cases echo is active so one will see the character sent back. To avoid damaging other input we suggest to put a resistor (1kohm can be fine) in series with the line (TXD from the adapter).
JTAG interface
JTAG is an industry standard interface which was designed to test circuit boards during production by providing a mean to probe non accessible connections. Given this characteristic it is used also for debugging system CPU (or other controllers) and to program flash devices. These are exactly the features that we want to have access for our purposes.
The JTAG interface uses a serial protocol with 4 wires: TCK - clock, TDO - data out, TDI - data in, TMS - test mode state (changes JTAG state machine). If more than one part has JTAG interface they can be daisy-chained cascading TDO and TDI (first chip TDO to second chip TDI for example). An adapter is required and there are a lot out there. We suggest to select one that can work with different logic levels, has protected lines and works with Urjtag (an open source jtag software) and OpenOCD.
If our CPU has a JTAG interface (which is highly probable), you can get access to debugging features of the processor itself, that we can leverage to alter firmware behavior (e.g., bypassing some security checks) and access the flash memory to read its contents (dump the firmware image for later analysis) or update them (upload a modified firmware image). As for the serial port case if JTAG signals information has been obtained we have mapped its pins and can connect the adapter to continue our work.
If the system has more than one chip with JTAG (it is common to have devices with FPGA on board and normally datasheets for FPGAs are available) it is also possible that they are daisy chained so we can have traced at least TCK, TMS and TDO or TDI so with some try and error we can find the missing signal and detect devices on the chain.
If there aren't any other options, we can try using standard pinout for JTAG headers. In this way one can map at least GND and VDD to the header and then compare with known pinouts. If a matching is found we can try to connect our JTAG adapter and try to detect chips on the chain.
If this fails or no evident header is on the board there is a nice tool called JTAGEnum which tries to identify JTAG pins from a bunch of signals. It is an Arduino based (no surprise! Arduino is really an handly platform for hardware hacking) platform which exploting some characteristics of the JTAG interface tries to do the mapping trying possible pins combination. Remember to select an Arduino board that is compatible with you board logic levels (or interpose a level shifting adapter). After JTAGEnum has mapped JTAG signals wire you adapter and use JTAG software to continue your work.
It can happen that this process fails: take into account that some CPUs have ways to disable JTAG interface (like with fuse bits which are programmed once after factory testing/programming) or to disable debug functionality.
Conclusions
Hardware security and hacking is somehow a broad topic and requires knowledge of electronics, familiarity with hardware tools (soldering iron included) and embedded systems. This is just an introduction meant to give some ideas. Working on a well known device is a good starting point to get familiar with these topics.
Source - http://blog.emaze.net/2011/12/embedded-hardware-analysis-primer.html
No comments:
Post a Comment