- Launching GitHub Desktop
- Launching GitHub Desktop
- Launching Xcode
- Launching Visual Studio Code
- Latest commit
- Git stats
- Receiving data from Serial Port
- 1 Answer 1
- Router Analysis Part 1: UART Discovery and SPI Flash Extraction
- Dumping the SPI flash
- Finding firmware online
- Looking For Serial
- UWAT? What is a UART?
- Analyzing the FS Image / SPI Dump
- Next Steps
- Image References
Use Git or checkout with SVN using the web URL.
Work fast with our official CLI. Learn more.
Launching GitHub Desktop
If nothing happens, download GitHub Desktop and try again.
Launching GitHub Desktop
If nothing happens, download GitHub Desktop and try again.
If nothing happens, download Xcode and try again.
Launching Visual Studio Code
Your codespace will open once ready.
There was a problem preparing your codespace, please try again.
Failed to load latest commit information.
Linux Serial Test Application
This is a very simple program — there are several ways to compile it on Linux:
directly using GCC
gcc -o linux-serial-test linux-serial-test.c
Stress test a connection
This will send full bandwidth data with a counting pattern on the TX signal. On any data received on RX, the program will look for a counting pattern and report any missing data in the pattern. This test can be done using a loopback cable.
Test flow control
This enables RTS/CTS flow control and sends a counting pattern on the TX signal. Reads are delayed by 250ms between reads, which will cause the buffer to fill up and start using flow control. As before any missing data in the pattern is reported, and if flow control is working correctly there should be none.
This test can be done using a loopback cable, or by running the program on both ends of the connection. For a two-port solution invoke the following command on the receiver side:
and on the transmitter side:
Stress test that can be used in a script
This transmits for five seconds and receives for seven seconds, after which it will exit. The exit code will be zero if the number of received bytes matched the number of transmitted bytes and the received pattern was correct, so this can be used as part of an automated test script.
Output a pattern where you can easily verify baud rate with scope:
This outputs 10 bits that are easy to measure, and then multiply by 10 in your head to get baud rate.
Receiving data from Serial Port
I want to receive data from RS232 Serial port to my terminal and with a directive to a file. It should be pretty straight forward.
Before that I’ve configured the parameters to match that of the device’s(Biochemistry Analyzer).
- Baud Rate — 9600
- Parity — None
- Bits — 8 bit
- Stop Bits — 2
But I don’t receive anything on the terminal.It’s just blank. What is the problem?
1 Answer 1
Try Minicom first and see what your serial port returns. Install it with sudo apt-get install minicom
You start it as follows (for ttyS0):
You can set the communication parameters from within Minicom (using ctrl-A P ), so you’re sure that they are correct.
If your device uses a specific protocol, it might need a command to start its communication. So have a look at the user manual.
Maybe your device is set up to use hardware handshaking. If possible, turn it off (at least to start with).
If you can’t turn it off, then you will have to set that up as well on your side. In Minicom this is under ctrl-A O and then serial port setup .
I’ve used Minicom often to debug serial communications and I find it works best.
I’ve received some more information from the OP:
The laboratory instrument(Cobas C311) uses ASTM protocol. There in the interface , we just need to click «Send to Host» and it sends a bunch of ASTM records. I just need to receive them in a file. Is there any other setting? What is the command to start acquiring data. and how to save the data in a file?
Chosen the right paramters. Minicom is showing 9600 8N2. Hope it’s alright. But receiving nothing — not a single bit. The analyser says, «The instrument transmitted ENQ as a send request,but the Host did not return ACK or NAK within 15 seconds.(Link Timeout)»
The device uses the ASTM Protocol. The device sends the character as a signal that it is ready to start sending data.
This is not something you will be able to receive using minicom or any other terminal program. You will need proper application software that supports this protocol.
You definitely have to read your user manual and check the installation disk (if any) and the manufacturer’s website for an application that supports this protocol.
I would be surprised if they don’t have application support for this device. If they offer something it is likely to be a Windows application or some example code plus a library.
It is possible to write something yourself, but it won’t be easy. There is some Python support for ASTM and there is a Perl script that you could try.
SO also has a post with some information about ASTM..
Router Analysis Part 1: UART Discovery and SPI Flash Extraction
In previous posts, we’ve gone over how to tear down Arcade cabinets containing SPI Flash as well as how to dissect the data that was extracted from the Rom. With this next series of posts, I’d like to take the concepts we talked about on those platforms and demonstrate them on a more popular platform
With this post our goal will be to extract the firmware from the platform and locate and type of debugging if possible (UART,JTAG,etc). We will explore multiple ways of attempting to extract the filesystem and outline the steps taken for each method.
Disclaimer: I’ve done my best to not research this router on the Internet, so I apologize if this is old information for those who look at these platforms.
Below is a picture of the PCB after removing it from the case:
You can see the various SoCs highlighted in red/yellow/green and the SRAM highlighted in blue, otherwise this is a very straightforward board.
The CPU is highlighted in yellow, it has the part number: QCA9563-AL3A, this is going to be the main CPU that we interact with.
The chip highlighted in red has the part number QCA9880, a quick Google search returns the following wiki page
The SoC highlighted in green has the part number QCA8337N which is described in it’s data sheet as “highly integrated seven-port Gigabit Ethernet switch”
On the underside of the board there is a serial EEPROM which looks strikingly similar to those that we extracted on the Arcade cabinets in the previous posts. The EEPROM is the small black 8 pin chip in the center of the board.
Dumping the SPI flash
As in previous posts, this platform contains a Winbond SPI chip. Knowing what we learned about flashrom, we can hook up a buspirate and attempt get a dump of the flash. The flash chip in question is the Winbond W25Q16Fw, the data sheet can be found here
Using the pin-out from the diagram, we wire up a TSOP8 clip and connect it to the buspirate, and below are the results:
It looks like we’re having some issues doing this in circuit, looking at the lines with a scope, it appears that the BusPirate can not drive the lines appropriately. After further investigation I found that the Chip Select line was not being pulled low enough, after trying a few various pull-down resistors I decided to move on from reading it in circuit. This is a common issue with trying to do any kind of in circuit reads, in order to mitigate this one can look for a reset line for the main CPU, or attempt to get the CPU into a state where it is still powering the chip but not attempting to communicate. But – since I’m a little lazy, let’s just remove it with hot air and dump it, see the pictures below and the output of binwalk on the flash image
Now that we have removed the EEPROM, we see more positive results with flashrom, which is to be expected.
Running binwalk on the resulting image produces the following:
This looks promising, the SPI flash contains two U-Boot images, a Linux Kernel as well as a SquashFS filesystem, this is all fairly standard when looking at platform like this so at this point we can assume we’ve successfully dumped the flash, but as most of you probably know, these firmware images are typically obtainable online which we will discuss next.
Finding firmware online
When looking at routers such as this, it’s often very easy to find firmware online. I wanted to attempt to extract the SPI flash because that’s more in my wheelhouse being an embedded systems guy. However — the simpler path would be to go to the following link where we can find an update image! However, the ability to re-write the SPI flash can be useful in case we manage to brick the platform in the future.
Sure enough, googling the router name takes us to the following link where the firmware can be downloaded
One should note however, that these firmware images contain the root filesystem of the target and not the bootloader, which is something we would be interested in if we were to attempt to port another OS or image to this platform potentially, so there is some validation for dumping the SPI flash.
Looking For Serial
When looking at an embedded system of this class for the first time one of the first things you want to look for is a serial port, these can lead to additional debug information and in some cases even terminal access. Debug ports are often exposed via a UART and typically consist of a transmit (Tx) and receive (Rx) line.
Of course some systems only give access to Tx and other have no access at all, but it’s still a good first step to try to hunt these down when assessing an embedded system. Methods of discovery for serial terminals can vary based on the system but there are a few things that can lead to quick wins:
- Debug headers or vias
- Silk screen labeling
- Unused pads / jumpers on the PCB
So what do headers look like? What are vias? Below are some example images of what they typically look like and after looking at these you’ll notice something very similar on our board
Looking at our board we can see some headers that look very similar, now we need to inspect them, but first it might help to learn a little more about what a UART actually is
UWAT? What is a UART?
UART stands for Universal Asynchronous Receiver Transmitter, this can be used for many things on an embedded system including communicating with other processors, sensor communications and of course what we’re interested in — debug access. One of the features of using a UART over something like SPI or I2C is that since it is asynchronous, there is no clock to synchronize the signals being sent between the two. In place of using a clock the transmit line utilizes start and stop bits to outline a data packet. This means that both the transmit and receive line must know the rate at which to read bits off of the wire as they come across, this is referred to as the baud rate. This is essentially the speed of the data being transferred which is typically measured in bits per second.
So if we were to look at a UART packet, we would have the following
|0:1||Start bit||Used to signify the start of a packet|
|1:9||Data bits (this can also be configured to be any value really, but is commonly 8)||The data to be send / read, note that data is typically sent with the least significant bit first|
|9:10||Parity bit||This bit determines if data has been changed as it went over the wire|
|10:12||Stop bits||This signifies that the packet has ended|
This is all great information, but in practice what does it mean for us reverse engineers? Well depending on the logic level that the UART is using, we can probe the circuit board with a multimeter and look for fluctuations in the voltage, this might lead us to a debug console that is spewing log messages, or it may just be another bus being used for sensor communications. Let’s start taking a look at the headers we outlined below and measure the voltages at each pad after the router has booted.
The Tx line is typically held high in most reference designs by whoever is driving it, AKA transmitting. We have 2 possible candidates for Tx. Pins 1-3. There is a good chance that one of these is our 3.3V VCC line, we can determine that by noticing the pin’s behavior when the platform is powered down. If it is a fast drop to 0V we can assume that it is a GPIO line of some sort, if it slowly drops down to 0V, it is likely the VCC line because that slow drop is caused by capacitors that are often present on power rails! After looking at these pins on shutdown we can assume that pin 1 is VCC, as it slowly drops from 3.3V to 0V over the course of
5 seconds. This leaves two candidates for Tx/Rx, pins 3 and 4.
Also note that we talked about how it’s often up to the transmitter to drive the line high, which would mean that the Rx line (which we would Transmit to) is likely pin 3 because it’s 0V and not connected to ground!
When we look at this under the scope — there is no traffic or fluctuation whatsoever. However, take a second look at the photo and notice the pads labeled R24 these pads indicate that a SMD resistor was here at some point in time and removed pre-production. Often times when looking at things like serial ports or JTAG connectors, there will be signs of resistors or other components being removed as these features are no longer needed once the device is in production. Let’s probe the left side of that pad and see what it looks like with the logic analyzer.
As you can see from the output of the serial analyzer, we see the string U-Boot , meaning we’ve found our Tx line. After hooking this up to an FTDI we determine that this is a serial terminal that drops us to a root shell, we could not have asked for more in this scenario. Let’s take a look at the full serial dump:
In order to make this a more usable shell, I applied a solder blob bridging the two pads of the R24 connector. Note that some times in this scenario that one of the pads may be pulling the serial line up to the proper voltage, but since our voltage levels look normal on the multimeter and on the logic analyzer we can just use a solder blob. Now the header contains a functioning serial port
Using this serial port, we can insert a flash drive and take an image of the filesystem using dd:
dd if=/dev/mtdblockX of=/mnt/usbdisk/mtdblockX.bin
You could also just copy the files off with cp whatever you’d prefer
Analyzing the FS Image / SPI Dump
I showed before the binwalk output of the SPI dump. This showed us that on the SPI flash we have the UBoot image (Stage 2 bootloader) the kernel and the rootfs. This is everything we need to start poking around at the files running on the platform.
As we can see from the binwalk output, the image contains 3 uImages, two of which are actual U-Boot bootloader images, while the third is the compressed kernel image. After the compressed kernel uImage we have a SquashFS filesystem, this is what will hold most of the data that we are interested in. We can extract it from the image with dd as shown below:
Now we can use binwalk to extract the SquashFS image, we could also mount this as a loopback device to get the same result
Through this initial hardware analysis we’ve found 3 ways to get an image of the flash used on the platform:
1.) Researching the platform online (obviously the best place to start in this scenario)
2.) Extracting the SPI Flash
3.) Copying files via the debug console
Hopefully by outlining some of these steps, you’ll have the knowledge to hunt for serial ports and find/enable consoles on platforms you are analyzing
Now that we have the filesystem image and an active console we can focus on setting up a debug environment and hunting for any potential issues that may be present on the platform
Blog Updates (as of 2022):
Future blog posts and entries can be found here.
If you are interested in learning more about reverse engineering check out my 5 day hardware hacking course, public and private offerings are available upon request
Never want to miss an update or blog post? Check out my mailing list for a quarterly newsletter about reverse engineering embedded devices