Ledger HW.1 with lost Security Card and lost seed: Successful BTC recovery

Originally published on reddit: https://www.reddit.com/r/ledgerwallet/comments/1h5d2cv/ledger_hw1_with_lost_security_card_and_lost_seed/

- Short version / TL;DR:

Client has BTC secured by an old Ledger HW.1 hardware wallet, but lost their Security Card and their seed phrase. They still have their unlocking PIN.

The Ledger HW.1 hardware wallet, released in 2014 in the early days of the Ledger Company, is a screenless USB dongle supporting only BTC. Its Security Card feature provides an additional challenge-response layer of protection, preventing unauthorized transactions when the dongle is connected and unlocked.

Without the Security Card or recovery seed phrase, BTC secured by the HW.1 was considered irrecoverable.

However, in 2022, Ledger revealed a firmware vulnerability allowing reassignment of a new Security Card through brute-forcing responses to challenges:

https://donjon.ledger.com/lsb/017/

Note: This vulnerability applies only to older screenless Ledger devices (HW.1, Nano). Modern devices (Nano S, X, S+ etc.) are unaffected.

Using this vulnerability, we successfully exploited the HW.1’s firmware to brute-force responses and reassign a new Security Card in our test HW.1 dongle.

This technique will allow recovery of our Client's BTC.

- Long version:

First, read the short version above, and read the linked Security Bulletin from Ledger Donjon.

The situation is: A Client who contacted us has a HW.1 dongle securing their BTC, but they lost their Security Card and seed phrase. They still had their unlocking PIN.

Our goal was to set a new (known) Security Card in their dongle, using the exploit described in the Ledger Donjon Security Bulletin #17 (see link above), allowing recovery of their BTC.

This exploit had already been demonstrated by Niv Yehezkel, the security researcher who discovered the vulnerability:

https://medium.com/@niv_28183/ledger-hw-1-nano-security-keycard-bypass-dc868f2893

But we needed our own code to perform this exploit.

The vulnerability allows calling as many times as we want the function that sets a new Security Card. This function requires the user to answer a challenge with a 16-bit value that is derived from the old Security Card. The trick is that the HW.1 dongle must be power-cycled between each call to this function, but there is no limit to the number of times we can call it, until we get the correct response to the challenge (we use a response generated randomly since we lost the old Card).

The more efficient time-based attack, described in the Ledger Security Bulletin and in the document above, requires specialized electronic equipment to measure very accurately the time between sending the challenge response to the dongle, and the dongle answering, by capturing electrical signal on the dongle USB pins.

We do not have such electronic equipment, so our approach was just using a brute-force technique to try to get the right 16-bit response to the HW.1 dongle challenge request, hoping to get lucky after a number of attempts. In fact, for each challenge, the average number of responses that are potentially valid is less than 63000, since we do take into account that the challenge can have duplicate characters. E.g. if the Challenge is "sRs7", we won't try the response "62b9" because this response is known to be incorrect.

- Our first approach was to use a Windows 11 host and a Linux VirtualBox guest:

The brute-force attack described above requires power-cycling (i.e. power off then power on) the HW.1 USB dongle to reset its state after each failed challenge-response iteration.

We decided to write the Python code on a Linux Debian guest running in Oracle VirtualBox (VB), using the Python packages from the ledger developer's site in order to communicate with the dongle. We had to modify parts of those Ledger Python packages because they do not support HW.1 anymore.

We wrote the code that unlocks the HW.1 dongle with the PIN, calls SET_USER_KEYCARD, answers that challenge with a random response, checks if we found the correct challenge response, and loops if not, after doing a power-cycle of the device. This code was pretty straight forward.

The main issue was how to power-cycle the HW.1 dongle programmatically.

The challenges that we faced here were guest-host communications, USB hub behavior / USB drivers issues, USB adapter failures, and software timing and performances.

We had access to the dongle device from the VB (VirtualBox) guest, but we could not find a way to cause any USB port to power-cycle. We looked at an opensource Linux tool called "uhubctl", that can cause some supported USB hubs to power-cycle. We installed "uhubctl" on our Linux guest and even ordered one of the uhubctl-supported hubs.

Then we realized that VB only gives the guest access to USB devices, but not to USB hubs, so there was no way to use "uhubctl" from within the VB Linux guest, to cause a hub to power-cycle its USB ports.

There were therefore 2 solutions: Either use a Linux host and use "uhubctl", or find a way to power-cycle the dongle from our Windows 11 host, which also has full access to the hub.

We first took the second approach. So the problem was now how to cause a hub to power-cycle its ports, from the Windows 11 host.

We first thought about running "uhubctl" on "wsl" (the new Windows Subsystem Linux), but "wsl" too only has access to the USB devices, not to the hubs ("wsl" is a virtual environment too).

Then, using the various USB hubs we had, we discovered that one particular StarTech hub caused all its USB ports to power-cycle when disabling and enabling it (or just restarting it) using "pnputil", or using the device management tool "DevCon", or using the PowerShell module PnpDevice. The PowerShell module is extremely slow, so it was eliminated.

We had to go though some pretty painful USB troubleshooting to get our USB hub to power-cycle properly our HW.1, see details in a comment.

Among the many other issues we had to go though to make our software reliable (as it had to run for long times) is that it looks like many of the programs we had to call (like "VBoxManage", "pnputil", "DevCon" etc) work in asynchronous ways, i.e. they return before the action is fully completed. So we have to estimate how long to wait, as there is often no way to reliably check programmatically if an action is fully completed by Windows or by VB. Also, we found that "ssh" calls (made from Python using paramiko) return immediately, before the called command terminates, and there is special things to do for waiting until the remote command terminates.

- Result achieved using a Windows 11 host and a Linux VirtualBox guest:

After solving all the issues above (and many others), we had reliable code that could perform the brute-force attack at a speed of about 3.2 secs per iteration.

The 3.2 sec delay is mostly due to the time for VBoxManage to actually detach the device completely so that we can power-cycle the hub without issues, the time for the hub to reset, the time for the Windows host to detect the dongle after the power-cycle, and the time for VB to re-attach the dongle to the guest virtual machine.

The 3.2 sec per iteration means about only 28000 iterations in 24h. The chances to find the matching challenge response being about 1/63000, this was not quite satisfactory performances.

- Moving our Python code from the Linux VirtualBox guest to the Windows 11 host:

We wanted to avoid all the delay dues to using VirtualBox, so we decided to move our Python code to the Windows 11 host. Python code can run on Windows, but we found out that some of the Python modules that the Ledger modules were using to communicate with the dongle, were not supported by recent versions of Python on windows. So we used an older version of Python (3.6), which made it a bit easier to install all the Python modules we needed.

With our Python code running on the Windows host, performances were much better, about 1.3 sec per iteration.

But we noticed a very problematic issue: the commands that we used to power-cycle our hub (on the Windows 11 host), i.e "pnputil" or "DevCon", were both slowing down significantly after power-cycling our USB hub a few thousand times, apparently due to a bug in the USB driver stack on Windows 11. Rebooting the Windows 11 host was the only way to let us go back to the original speed.

So it was not satisfactory to see the timing increase to 5 or 7 sec per iteration after a few thousands of hub power-cycles.

- Using a Linux host (instead of Windows):

So we decided to use a Linux host instead of a Windows 11 host. We configured our laptop to boot Ubuntu from an external drive, and installed our Python code on the Linux host. This time, our code was power-cycling our hub using the "uhubctl" utility, that we compiled on our Linux host.

- Performances using a Linux host:

With our code running on a Linux host on our laptop, we observed a stable performance of about 1.27 sec per iteration, which is satisfactory.

Interrestingly, "uhubctl" is much slower when we connect connect the hub directly on a USB3.0 port. To get good performances, we had to connect the hub via a USB cable extension that only supported the USB2.0 handshake.

- Risk involved

Power-cycling the dongle many thousands of times could cause the HW.1 dongle to reset or malfunction. There is nothing that can be done against this risk.

During our early tests, due to a bug (now fixed) in our code, we accidentally reset our test dongle by using a wrong PIN more than 3 times, so we had to set it up again with a new seed and a new PIN. Since the HW.1 is now completely unsupported by Ledger, we had to write custom code to do the HW.1 setup.

- Chances of successfully installing a new Security Card on the HW.1 dongle:

Assuming 1.3 sec per iteration (i.e. 66461 iterations per day), the probability of matching the challenge response and setting a new known Security Card in the dongle are:

- In 1 day: 65.2% chances of success
- In 2 days: 87.9% chances of success
- In 3 days: 95.8% chances of success
- in 1 week: 99.9% chances of success

On our test HW.1 dongle, we were able to succeed multiple times, usually in a day or less.

- Conclusion:

We are confident we can now recover BTC from HW.1 ledger dongles with lost Security Card and lost seed phrase.

- Credits goes to:

Niv Yehezkel who discovered the vulnerability in the Ledger HW.1 firmware, Ledger Donjon who published the Security Bulleting about it, Niv Yehezkel again who then published an article detailing how he exploited it using "uhubctl" and the timing measure, ChatGPT-4o (AI) for providing extremely valuable information and working code (but you should never tell ChatGPT that you are using it for exploiting a vulnerability, it is against their terms of service), and google / Gemini, as usual.

------------------------------------------------------------

This is the USB hub troubleshooting section that we removed from the report and referred to:

--- Begin of USB and Hub Troubleshooting Details ---

Our StarTech hub had a USB-C connector, and our development machine had USB-A ports, we we used a USB-A to USB-C adaptor. On the software side, since the code that was used for power-cycling the hub was running on the gest, we had to use ssh to execute that code from the guest. So we installed OpenSSH on our Windows 11 host. It was working pretty well, and we decided to run the code on a much faster laptop.

The laptop had both USB-A and USB-C ports, and we found that the hub would not power-cycle if plugged on the USB-C ports. So we thought that it may have something to do with USB2.0 vs USB3.0 used to communicated with the hub (the hub support USB3.0).

Then, one day it stopped working. Our hub was not powering up anymore. But the hub was still powering up when plugged on the USB-C port. So it looked like somehow our USB-A port or driver decided to not power-up that hub. After a lot of time looking into what could cause that, we discovered that the cause was the least likely one: the small (and brand new) USB-A (male) to USB-C (female) adapter that we used for connecting the hub to the USB-A was fried!! We really did not expect this simple adapter to fail...

So we got another USB-A (male) to USB-C (female) adapter, and back to work. The hub was powering up, but it was not power-cycling, even when plugged on the USB-A ports were it was working before. It also did not power-cycle when plugged on our development desktop, where it also used to work.

We spend a lot of time trying to understand why. We finally found out that the issue was both driver-related and hardware-related: the hub would only power-cycle if using a USB2.0 driver, but our USB-A ports were also supporting USB3.0, just like our USB-C ports. The reason why it was working before is because our first adaptor (the one that fried) did not have the internal wiring to support the USB3.0 handshake, and the new one we got (that looked almost identical) did have the wiring to support USB3.0 handshake, so our hub was using a USB3.0 driver (even when plugged on the USB-A ports) and therefore it did not power-cycle.

We spent a lot of time trying to force our particular hub to use a USB2.0 driver, but Windows 11 does not make this easy at all, so we went for the simple solution: we found a USB-A splitter (and also an old USB extension cord) that did not support USB3.0 handshake, and went though it to connect our hub to the laptop. It worked as expected, like it used to, i.e. the hub could be told to power-cycle its ports.

--- End of USB and Hub Troubleshooting Details ---

Comments: you can read and post comments on reddit, even if the post was "removed by reddit filters",

In the same Recovery series: Other crypto recovery reports by loupiote2

Contact loupiote2 via chat or message from reddit profile: https://www.reddit.com/user/loupiote2/