Initial Teardown

Removing End Cap

Small, sharp utensils (ex. pocket knife) were used to remove some of the glue from the end seam on the cap. Then, a heat gun was used to further melt the glue on the end seam. Finally, the pump was clamped in a vice, a flathead screwdriver was placed in the small gap in the end seam, and the screwdriver was hammered into the seam until the end cap came loose. Then, the ribbon cable from the end cap was removed and the PCBs were removed from inside the pump with pliers. Finally, the PCBs were separated and analyzed.

Chip Analysis

Two notable chips were identified, all on the front of PCB 2. The lowest chip on the board is a Cypress 48-pin FBGA static RAM chip. The highest chip on the board is a Hitachi H8/3067 series CPU. By searching in the data sheet for information regarding exploitable protocols (UART, JTag, etc.), we discovered that this chip utilizes UART.

Chip Exploitation: CPU

Since the 48-pin FBGA chip requires chip-off analysis with a custom tool for its form factor, exploitation began with the Hitachi CPU. The chip analysis indicated that this chip had two sets of pins (pins 12-15) that use UART, which is potentially exploitable. Since the power source for the device has been removed, the device must be powered using alternate methods. Before attempting to use a DC power source, the chip must be tested for functionality. By using a VR table to make connections to the individual pins, soldering can be avoided.

Four of the arms on the VR table were attached to four pins: VCC (Pin 1), VSS (Pin 11), Tx (Pin 13), and Rx (Pin 15). A camera aimed at the CPU and connected to a monitor was used to get a close-up of the pins and make the connections properly.

Once the pins were connected, the four arms of the VR table could be used to connect the chip to an Attify Badge. The ground pin on the CPU was connected to a ground pin on the Badge, the voltage pin on the CPU was connected to a 5V pin on the Badge, and the Tx and Rx pins on the CPU were connected to the Rx and Tx pins on the badge, respectively. The Badge was then connected to a Kali Linux laptop. The following commands allowed us to see the connected Badge and test for data flow:

ls /dev sudo screen /dev/ttyUSB0 115200

In the screen command, "ttyUSB0" is the name of the USB as found using the first command, and 115200 is a random bit rate. After a few moments of the screen command being active, data appeared. It was illegible, indicating that the bit rate was incorrect, but it verifies that data is flowing and the chip is powered.

The next step was to perform a logic capture to visualize the data flow with a Saleae Logic Analyzer. The ground cable connecting the VR table to the Attify Badge was removed, as were the Tx and Rx cables. One ground cable on the Saleae was connected to the VR table where the chip's ground pin was, and another was connected to the Attify Badge's ground pin. Two non-ground cables on the Saleae were connected to the VR table where the Tx and Rx pins were. The voltage cable was left on the Attify Badge, and the Badge was unplugged from the Kali laptop. We downloaded Saleae's Logic 2 application onto a separate Windows laptop and opened it, then selected the Saleae device and started a logic capture before plugging the Badge back into the Kali laptop to power it again. Once it was powered, the logic analyzer showed data and voltage movement.

Chip Exploitation: Static RAM Chip

The goal with the Cypress Static RAM chip is to attempt to read data from it. The data sheet provided for this chip states that in order to read from the chip, the Chip Enable (CE) and Output Enable (OE) pins must be set to LOW, and the Write Enable (WE) pin must be set to HIGH. Then, the Byte Low Enable (BLE) pin can be set to LOW. Once these actions are performed, a memory address can be specified on one of the address (A) pins and the data at that address will be outputted to one of the Input/Output (I/O) pins. These instructions from the data sheet can be seen below:

These pins can be identified using the diagram provided in the data sheet, as seen below:

Initial Read Testing

In order to read from this chip without soldering it, the chip was connected to a VR table. This device has articulated arms with pins on the end of each that can be moved to connect to the pins on the chip. These arms are then wired to connect to pins at the base of the table that can be wired to other devices. This usage was previously discussed in the methodology for this device's testing.

The pin's numbers are usually determined by a small dot in one of the corners on the top of the chip indicating which pin is the first. Once that dot was located, the chip was oriented on the VR table according to the diagrams provided by the data sheet that indicate the pin positioning when the chip is being viewed from the top and from the bottom.

This flips the pin order shown in the previous diagram.

The chip set up on the VR table is seen below:

INSERT PHOTO HERE

In addition to the pins mentioned in the data sheet, ground (Vss) and voltage (Vcc) also had to be connected to the VR table so the chip could be powered properly. The data sheet specifies that the chip has a voltage range of 1.65V to 2.25V, and the VR table has a built-in power option of 1.8V, so I could connect the voltage pin to power directly through the VR table.

The pins on the chip correspond to the ports on the VR table as follows:

Address Pin (A2): L5

Chip Enable (CE): L4

Input/Output Pin (I/O0): L3

Write Enable(WE): L2

Output Enable (OE): R5

Byte Low Enable (BLE): R4

Ground (Vss): R3

Voltage (Vcc): connected directly to the 1.8V port on the VR table.

In order to test that none of the pins connected to the VR table arms were touching, I used an AstroAI AM33D multimeter to test for crossover. Two cords were connected to the multimeter, each with pins on the end. Then, I held those pins to two of the plugs at the end of the cords connected to the pins on the VR table (the black and red cords seen in the earlier image). If the pins on the VR table connected to those cords were touching, the multimeter would make a sound. I repeated this process for each pair of pins that were closely situated on the chip, and none were touching.

The next step was to connect the VR table to a breadboard, then connect the breadboard to an Arduino Mega 2560 microcontroller, as well as a Saleae logic analyzer. The cord for the VR pin attached to Voltage (Vcc) was plugged directly into the VR table's 1.8V port, and the VR table was connected to power. Then, the pins at the bottom of the VR table that corresponded to the utilized ports (ex. L5) were connected to separate horizontal lines on the breadboard. A breadboard's horizontal lines on either side of the vertical line separating its two sides run the same connection, so it can be used to string multiple connections together. Therefore, additional slots in the horizontal lines were used to connect the VR table lines to the Arduino's digital ports. Ground was connected to the GND port, Write Enable was connected to port 43, Input/Output was connected to port 45, Chip Enable was connected to port 47, the Address pin was connected to port 49, and Byte Low Enable was connected to port 53. Connections were then run from the lines on the breadboard connected to Ground and Write Enable to the Logic Analyzer, which was connected to a laptop running the Saleae Logic 2 application. The image below shows the full setup:

[INSERT IMAGE HERE]

The logic analyzer allowed easy troubleshooting of the Arduino program written for this chip, since it displays the movement of data in its raw form. For Write Enable, Chip Enable, and Byte Low Enable, a modified version of the program found here was run to ensure that the pins were actually being set from HIGH to LOW as directed in the program. The modified version of the program simply commented out the for loop calling the send_address function and the declaration of the send_address function, since that function didn't involve any of the pins currently being tested. The results in the Logic 2 application were as seen below: a steady switching from high to low.

This confirmed that all three pins were functioning as intended with the program. Next, the address pin was connected to the logic analyzer to test the flow of data through the address pin. The send_address function was uncommented and it was called in the loop function, but without the for loop to run through multiple addresses.

First, the address 0x01 was tested, and the results were as seen below:

Then, the data flow of the Input/Output pin was tested with the same program running:

Next, the memory address was changed to 0x32 and the data flow of the Input/Output pin was tested again. This verified that the data coming from the Input/Output pin was changing based on the memory address, which is a good sign:

Finally, the full program was tested and the data flow of the Input/Output pin was recorded for ten seconds and saved to a .bin file:

That file was opened in 010 Editor to get a quick view of the contents, confirming that there was actual data flowing.

In order to capture the firmware on the static RAM chip using a logic analyzer, we decided to wire the chip to the board and power the CPU with a DC power supply. This would allow the static RAM chip to boot normally so the firmware could be captured. In order to know what CPU pins to connect to for the logic analyzer, the connections between the pins that connected the static RAM chip's Input/Output pins to the PCB and the CPU pins were tested. This was achieved by connecting one wire of a multimeter in continuity mode to the Input/Output pins for the static RAM chip on the board and touching the other wire of the multimeter to various pins on the CPU. When the multimeter beeped, it indicated a connection between those two pins. Through this testing, it was determined that the Input/Output pins (denoted by I/Ox) matched to the Dx pins on the CPU, which can be seen on the chip diagram below:

Reassembling the Device

In order to boot the device as if it were still fully functional, it had to be reassembled. This means that the static RAM chip had to be soldered back onto the board and the four PCBs had to be reconnected. In addition, the CPU had to be soldered to in order to perform our man-in-the-middle attack to capture the data between the static RAM chip and the CPU.

First, we soldered wires to the CPU. We soldered to the pins previously identified as the pins connected to the static RAM chip's Input/Output pins, which were the Dx pins on the CPU. There were sixteen of these pins. We also soldered to a Vcc (voltage) and a Vss (ground) pin.

These wires had to be soldered to avoid the connector above (or in the provided picture, to the left of) the chip, since that connector is used to link PCBs. Next, the static RAM chip was resoldered on. First, it was "reballed". This entailed covering the chip with flux and attaching small, uniform amounts of lead solder to each pin. Since the chip has been cleaned and soldered to, it needed fresh solder to reattach to the PCB.

IMG_1311

Once the chip was reballed, the rest of the PCB was covered with heat-resistant tape to prevent other chips from being affected. Then, the spot where the static RAM chip was originally was covered with flux and heated with a hot air gun. Then, the chip was reset onto that spot and heated with the hot air gun until it had set completely.

Finally, the device was reassembled. Each PCB had connectors to the other boards, and those connectors were snapped back together.

How To:

Remove a Chip

Step 1: Place PCB on frame above hot plate and secure in place. The PCB should not be able to move around during this process.

Step 2: Turn on the hot plate and preheat it to 200-300 degrees Celsius. Wait for the plate to heat up completely before continuing.

Step 3: Apply flux liberally to the chip being removed.

Step 4: Turn on the hot air gun and heat it to 300-500 degrees Celsius. Take the hot air gun and circle it slowly around the chip, pointing it at the sides. Do this for several minutes.

Step 5: Take tweezers and attempt to move the chip. If it's ready to come off, it will move easily. Once the chip has started moving, remove it immediately to avoid it resoldering to the board in the wrong position. If the chip does not move, continue heating it with the hot air gun and applying flux. Retry every few minutes.

Solder

Step 1: Gather equipment necessary. This includes protective equipment (gloves, goggles, respirator), fume extractor, flux, lead solder, wires, isopropyl, brush, solder wick, and the chip.

Step 2: Prep the station. Equip protective gear. Stick the chip to the table with double-sided tape. Position microscope over chip. Bring fume extractor close and turn on. Turn on soldering iron. Apply flux liberally to the chip. Cut appropriate length of wire.

Step 3: Solder. Remove soldering iron and gently touch to the end of the lead solder, gathering a small amount on the tip of the iron. Position the wire in one hand and the iron in the other close to the pin being soldered, then look through the microscope. Hold the tip of the wire to the pin, then bring the iron with the lead solder down to press the wire to the pin. Keep tapping and adjusting as necessary until the tip of the wire is fully attached to the pin and does not touch any other pins. The wire should be able to withstand being pulled from the other end without disconnecting from the chip. Apply more flux if needed. If soldering multiple pins, start with the pin highest up on the chip and furthest away from the hand holding the soldering iron.

Step 5: Cleanup. Tape all attached wires down to the table. Take the solder wick and press a clean length of it to the points on the chip where solder needs to be removed. Press the soldering iron against the wick and move both the iron and the wick together across the chip slowly, until no resistance is felt. Douse the chip in isopropyl alcohol, and gently use the brush to get rid of any remaining flux.