WebRoot PHP Ultimate Web Hacking Tool
Odina Conkright
This IoT device had already been lightly delved into by the guy's over at Hong's Electronics. I wanted to try it out for myself as there's more than one way to skin a cat. Additionally, I've been wanting to dive further into hardware/embedded reverse engineering so this medical IoT device provided me the opportunity to do exactly that. I knew from the moment I saw laid eyes on the tweet introducing the product that it would be a ton of fun to hack and write a blog about.
This product is really just a fancy camera (DVR). At its core, it's a video-based testing system capable of measuring "motile sperm concentration (MSC)", which is essentially concentration (number of sperm/mL) and motility (% of moving sperm). It uses its built-in camera and light source along with a mini-microscope attachment to accomplish this. Additionally, this product was approved by the FDA in 2017 so it's been on the market now for a while.
This is the basic rundown. You ejaculate in the cup and pour the "Liquefying Powder" in with the sperm. Then you gently stir for 30 seconds then you wait for 10 minutes. After the 10 minutes you pipette your cum onto the testing slide, shove it into the machine and then you wait 5 minutes.
I started searching for the Serial Flash chip's information and quickly found it's datasheet from the vendor. This gave me a better understanding of the various GPIO pins on the chip with the full schematic.
The Bus Pirate (BP) is a universal bus interface device designed for programming, debugging, and analyzing microcontrollers and other ICs. We've got enough information here to do what we want. We'll connect the two using standard low-end jumper wires. The relays will be mapped according to the picture below.
Everything looks fine we can see the serial COM of the BusPirate. In theory we should be able to use flashrom which is a utility for identifying, reading, writing, verifying, and erasing flash chips to dump the firmware.
However, after looking at the flashrom source I discovered our chip, the MX25L12833F was only added in the most recent commit to flashchips.c but it seems to just be an alias for an existing entry. So an older version of flashrom should have worked. Regardless, it should've found something and it didn't. There is also an open issue regarding this which can be viewed here.
With all the dependency issues this project has these days I wasn't able to build it from the source either. At this point, the BusPirate was the only hardware I had. I had ordered a Shikra and an Attify badge but it wasn't going to arrive for another 3 months. I gave the board a better look and it turns out that we might have UART (debug serial port) available to use. As seen in the image below there are TX/RX/GND marking on the PCB.
UART is used for asynchronous serial communications to send and receive data from devices for purposes such as updating firmware manually, debugging tests, or interfacing with the underlying system (kind of like opening a new terminal in Ubuntu). UART works by communicating through two wires (a transmitter wire and a receiver wire) to talk to the micro-controller or system on a chip (basically the brains of the device) directly.
So, you may be wondering - why the fuck are we doing this. Since we can't dump the firmware of a device through its flash chip, we'll have to access it or dump its firmware through UART instead. Although this is a shit predicament. This is actually an issue we may occasionally encounter when trying to dump an SPI flash chip is providing too much power to the device through the VCC connection, thereby subsequently forcing the flash chip to be in use by the SoC (system on a chip) and preventing us from dumping the firmware. This could be what's happening in our case as well but I'm willing to bet it has more to do with our hardware and the flashrom libraries.
Now if you're better than me one of the solutions could simply be to de-solder the flash chip and try again, but the tip to my iron is fat and this is simply not something I wanna do. In any case, even if you are successful, you may find you just dumped an encrypted firmware that now you have to decrypt as well.
So, by using UART, we can talk to a device directly while the firmware is unencrypted in memory and running live, allowing us to dump it without having to de-solder a flash chip or non-trivially decrypt an encrypted firmware. In addition, we can also view how the system changes in real-time as we attempt to access it and find vulnerabilities.
Unfortunately, as seen in the previous picture, we may have identified a potential UART interface, but the connections are not clearly labeled. We know RX, TX but we don't know VCC or GND. But we can be identified using our multimeter!
Using a multimeter we first test the pins to determine if it's a VCC or the GND (ground). Ground pins usually come with marking as GND or sometimes no marking and to be honest this is quite pointless because it more-or-less has to be ground. Regardless, I'm not taking any chances.
To test for GND set the multimeter to continuity testing (resistance) and touch one probe to the grounded shielding and use the other probe to touch each pin one at a time. When a ground pin is probed the multimeter will beep and indicate that the two have electrical continuity.
To identify the transmit pin (TX) put the multimeter to the DC voltage mode (less than 20v DC) and connect the suspected pin to the voltage probe (RED lead) of the multimeter and the common probe (BLACK lead) to the ground pin which we identified in the above step. The voltage should fluctuate from a few millivolts to VCC at the time of boot up indicating the device is sending/transmitting some messages on its serial monitor. Remember TX = sending and RX = reading. Therefore, do the same shit for the receiver pin (RX) once probed with your multimeter it shouldn't do shit because you're not sending anything. That's how you figure that out.
Just out of curiosity before testing this out with the Bus Pirate I have a DSD TECH SH-U09C5 USB to TTL UART Converter Cable with FTDI Chip lying around so let's just see if we can get a shell with that first. Once it's all connected it looks a like this.
Note, when connecting to a UART, the question of choosing the baudrate arises. They say that it can be determined using a logic analyzer, but it's just always faster to find the desired value by brute force. In our case, it's 115200.
m is the mode on which to work. When a particular mode is set, the mode LED of the bus pirate lights up. We chose mode 3 = UART. In the baud rate, 9 = 11520 detection is selected so that the output terminal comes in a readable format. The rest are all default options.
Once you see UART> that means that we are in the macro menu. We're going to set a transparent bridge that is going to take us to the shell of the Yo's Sperm system sometimes even without any user name password. To do this, as seen in the image above we are going to run (1) and then enter y. Once you do this you will see a blank putty session. Then and only then we'll provide power to the Yo's Sperm system and interrupt the autoboot sequence as seen below.
Again, our goal here is to recover the firmware. The number of commands supported in U-Boot varies from device to device, but most low-cost DVRs (Digital video recorders) will have a fairly comprehensive list. Unfortunately (for us), U-boot is mostly concerned with copying data onto the SPI flash, whereas we want to copy data from the SPI flash.
We'll attempt to dump the memory over TFTP. Here's how we'll do it: Since U-boot stores it's settings in something called "environment variables". If you run printenv you'll get its contents, which are as follows.
What we're looking for here is ipaddr (the YO's Sperm machines IP) and serverip (the IP of the TFTP server). These will generally have default values. You can either change the IP of the machine hosting the server, or you can modify the environment variables. We can actually change them by running the following:
Then we need to copy the flash into RAM. A suitable address in RAM is nearly always 0x82000000. The following command copies 0x1000000 bytes from address 0x0 of the flash into RAM. sf read 0x82000000 0x0 0x1000000
Okay. For some unknown reason, this isn't working. There seems to be an issue with DNS / the routing / perhaps the REALTEK 8188FTW card is responsible for WiFi shenanigans. How to resolve it is absolutely beyond me. No matter how I setup the FTP server or what network configs in the U-Boot system cant ping out nor can it perform anything TFTP-related.
I thought that maybe it was a Windows issue, so I decided to setup a RasberryPi and try my luck over there on UNIX hardware "locally". Unfortunately, my Pi's HDMI interface is broken so I can't use it. To make matters worse I just re-flashed the system so ssh isn't enabled from startup... Let's try a VM.
Desperate times call for desperate measures. Let's try to dump the memory over serial. Fuck. The main idea here is that we will "display" the memory to the screen and save it to a file, we'll transform that capture into a viable firmware flash.
We'll want to store the output to a file using minicom run minicom -s and select 'Filenames and paths' and press 'F' (Logging options). By default, this will be saved as 'minicom.log', but change it to whatever you like with the 'A' key. Press 'Enter' to save the changes.
In theory, modifying init on what is essentially a Linux OS boot parameters, it is possible to change the standard boot order (launching /sbin/init will more or less launch/bin/sh but with all the extra bullshit). By launching /bin/sh as init and then "normal booting" the system with this new config we get a shell in a running Linux system (the main functionality of the camera has not yet started working at that moment). We'll do exactly that as seen below.
As a result, the OS started up and made it possible to execute any Linux commands. By reading the device /dev/mtd0, the contents of the flash memory can be read. The easiest way is to write the contents of flash memory is to a microSD card with dd or nandump.
7fc3f7cf58