Hacking Hardware Password Managers: Royal Vault Password Keeper

TL;DR: Taking three hardware password managers I used them to:

• Learn the basics of hardware hacking
• Practice disassembling
• Perform chipset research
• Understand pinouts and protocols
• Read data off each device

The royal password vault boards looked to be reused from a previous hardware device with space for a speaker, an audio chip and microphone. The device also didn’t use SPI or I2c flash storage for the passwords like the devices in part 1 & 2 of this series. Instead it uses a CMOS flash chip which required more complicated equipment to read the data. The data was found to be encoded, which I was able to crack using some cryptoanalysis techniques with a pattern that looks to be duplicated across all devices, allowing decoding of all passwords.

Introduction

The first two parts of this blog series looked at the RecZone https://www.pentestpartners.com/security-blog/hacking-hardware-password-managers-the-reczone/ and PasswordFast https://www.pentestpartners.com/security-blog/hacking-hardware-password-managers-passwordsfast/ devices. These two devices store the passwords using SPI and I2c flash memory. The RecZone was found to store the passwords in plain text, whilst the PasswordFast device had encrypted the data.

The third and final device is the Vault Password Keeper made by a company called Royal. This blog will go through the steps that are undertaken during a hardware test to find out how this device measures up against the previous two.

Device Set Up

As the first step of all hardware jobs, various data was added to the device. As with the other two devices, a master password had to be set before entering in any website usernames and passwords.  It’s important to add a range of data including all characters and repeating characters to assist with trying to decode data if required later.

This device contained two different boards, one on the main unit and the other for the keyboard. The boards were connected via a ribbon cable.

Initial Inspection

The front of the boards showed similar connections for the keyboards, it also included a microphone and a space in the board, which I assume was for a speaker on a previous usage of the board.

There were also a row of test pads, these could be JTAG or similar which might allow debugging of the device. Although if the device has followed good security practises the ports will have been disabled after testing.

The back of the board was much busier than the previous two devices.

Three chips can potentially be SPI or I2C flash chips. There are four blob on boards, one of which is likely to be the main MCU.

There are then spaces for components which haven’t been connected, as well as a 48pin CMOS flash chip at the bottom of the board behind the keyboard.

Chipsets

Due to my newfound familiarity with them, I looked at the 8 pin chips first. One of these was a voltage regulator, the other was an audio driver. Neither of these were of any use in hacking a password vault.

The third chip, nearest the top of the board was of more use.

The code for the chip is 25, which means that it is SPI flash which was confirmed with the datasheet https://html.alldatasheet.net/html-pdf/207047/AMICC/A25L16PUM-F/314/2/A25L16PUM-F.html.

As SPI chips have consistent pinouts across all makes, I was able to wire the chip up to my raspberry pi and dump the data off the chip in the same way as with the RecZone https://www.pentestpartners.com/security-blog/hacking-hardware-password-managers-the-reczone/. Unfortunately, the chip was empty, it contained no data at all.

I assume that this chip was used in conjunction with the audio driver and microphone due to its location on the board.

The final chip to investigate was the 48-pin chip on the secondary board.

The datasheet as well as the 29 in the product code confirmed that this was CMOS flash.

As with the previous chips the datasheet provides the pinouts, this time more complicated due to the number of pins.

Due to the number of pins and complexity of the chip, it is not readable by the raspberry pi. However, it is possible to read the chip, although two barriers are present. Firstly, a universal programmer is required to read the chip and secondly to put the chip into the universal programmer, it can’t be connected to the board.

Luckily, in our hardware lab we have a Dataman  https://www.dataman.com/which is a universal programmer. The Dataman requires adapters which are chip specific which results in a large amount of equipment needed to read the chip, not to mention to cost of the Dataman and adapters!

We also have a heatgun which was used to melt the solder allowing the chip to pop off with the help of some fine-nosed tweezers.

The technique for the heatgun is to run the heat across both sides of the chip quickly whilst using the tweezers to gently prise the chip off the board.

With the chip off, it could then be plugged into the appropriate adapter for the dataman.

With this all connected, I was able to dump the data.

Dumping the data

Once the chip is in the adapter it is relatively easy to dump the data using the Dataman, it has a GUI which asks for the type of dataman, then the specific chip set.

When that’s configured the “read” button can be used to dump the data from the chip.

The dataman will dump the data into hex format.

Reading the data

The data from this device was different the previous two devices, where the other devices held just the URLs, usernames and passwords this chip contained various references.

The text shows Word Games, Memory and even a Defrag option. This device has definitely been repurposed from one if not more other uses.

Running a strings command printed a lot more references, including miles driven and average cost per mile, however at the end of the data was the data I was looking for:

Looking through the outputted hex data is was possible to find the full entries:

It can immediately be seen that the data is encrypted, similar to the output from the PasswordFast device. However, I was able to find the master pin within the data. The masterpin was set as “444444” and was represented in the data as:

It can be seen that the data uses the same value for the same letter. Therefore, this data hadn’t been encrypted, it had been encoded. With this new information it was possible to decode the data as we knew the raw inputted data:

Using this data, especially the length, it was possible to look at the data and make an educated guess to where each bit of data was stored.

Looking at the data for the first site, something stood out:

The repetition of the “FE”. As we found out earlier, the same character is represented by the same values, the only repeating letters in the inputted data was the “oo” in “food”. From this, it’s possible to assume that E6,FE,FE,C6 spells out food. Therefore, 0B must be the operator code for hint.

It can then be seen that in the line above there is an FE (o) followed by an C6 (d) directly above, which matched the username dlodge.

From there it was possible to use the remaining number of letters to calculate the location of the password and decode the data.

I then used the letters I knew and put them into place onto the other input data, resulting in more letters being decoded.

With both entries decoded the result of all known letters was:

The pattern emerges quite quickly with the high and low nybbles (half an octet) corresponding to the cipher text.

This type of obfuscation is a bitwise operation called rotate right (ROR). This pattern is not random and has been carefully calculated so I believe that this same code would be used across all of these hardware devices.

This opens the device up to exploitation, where all the data off any of the devices can be decoded. We reached out to Royal to inform them of this security vulnerability, however they did not respond.

Summary

I struck it lucky with this project by finding three devices that do the same job however work and store data in such different ways, which resulted in a huge amount of different skills being learnt.

I found it interesting that each hardware project has a similar methodology, however the range of different chips on each device keeps it very interesting with varied results. I was surprised how easy it was to read SPI and I2C flash data using common equipment and that using more sophisticated chipsets and blob on boards can stop avenues of attack and less determined people with less equipment.

Hardware hacking is still in it’s infancy and has a huge learning curve from more traditional pentesting, there aren’t as many flashy websites, guides and CTFs to help with learning, it’s much more digging through Chinese websites hunting for the datasheet and trying to extract the useful information buried within the electrical details. For this reason, there is a strange sense of excitement when doing hardware, as if it’s a new, hidden gem ready to be explored and more importantly exploited!

 

For reference here are the links to all three hacking hardware password manager posts:
https://www.pentestpartners.com/security-blog/hacking-hardware-password-managers-the-reczone/
https://www.pentestpartners.com/security-blog/hacking-hardware-password-managers-passwordsfast/
https://www.pentestpartners.com/security-blog/hacking-hardware-password-managers-royal-vault-password-keeper/