Nano S with Firmware 1.2: 539 ETH recovered successfully (seed lost)

Originally published on reddit: https://www.reddit.com/r/ledgerwallet/comments/1af8ei9/nano_s_with_firmware_12_539_eth_recovered/

TL;DR

Client has an old Nano S (Firmware 1.2) with 1.25 million dollars worth of ETH, and he lost his recovery seed phrase (i.e. the 24 words i.e. the master private key backup). Luckily he still knew the ledger PIN, and the ledger was working.

We were able to recover successfully his 539 ETH (worth about $1.25m at the time of recovery), using custom tools on a Linux virtual machine as a front-end to communicate with the device, and a specially configured ETH Full node running on Amazon AWS to process the transactions.

With the seed phrase, recovery would be trivial e.g. by just entering the 24 words in a new ledger. But without the seed phrase, the only way to recover is by using the old ledger, which in this case was not trivial (read the Long Version below for details).

Long Version

We noticed a post about the predicament of our client:

https://www.reddit.com/r/ledgerwallet/comments/19bquo4/ledger_nano_s_with_over_1_million_in_eth_usb/

The comments were mostly useless, misinformed, giving incorrect advices, or just calling the guy stupid or a troll, or from scammers. No surprise given the number of toxic people posting on this reddit forum.

Some people are asking why someone with that much worth in cryptos would be careless enough lose their seed phrase, but at the time our client bought those ETH, they were worth less than $10 per ETH, so they did not feel they had that much money in cryptos, and also they did not fully understand how crucial and precious the seed phrase is (the value of the seed phrase is the value of all the cryptos it secures).

We were pretty confident that we could recover, since a couple of years ago we did an ETH recovery from another old Nano S also with Firmware 1.2:

https://www.reddit.com/r/ledgerwallet/comments/nbcukn/nano_s_with_12_firmware_vs_eip155_successful/

So we got in touch and the owner of this old ledger agreed to work with us for the recovery, after checking our credentials.

... but some things have changed with Ethereum since we did the previous similar recovery, which made this one more complex.

The old Nano S firmware 1.2 cannot be updated, and even if it could, it would have been too risky since the client had lost their seed.

Our client already tried all existing ETH front-ends like Ledger Live, MEW, MyCrypto, MetaMask etc, but none of them could connect to their old ledger, of course.

The first thing we did was to explain our client the planned recovery process, and all the risks involved, and make sure that they fully understood all that, and that they would hold use armless and not sue us if for some reason, some funds were accidentally lost during the recovery.

Then we sent our client a linux virtual image containing our low-level command-line tools, that they could run in virtualbox on their Windows 11 laptop.

We then confirmed that those tools, running on client laptop, could communicate with the old ledger, and we were able to get the ETH address where the funds were, since our client did not know it (so he was not sure the funds were still there!). And yes, the 539 ETH were still there, untouched for almost 7 years. At this point we knew we had access to them using the ledger, so it was a big relief.

We already knew, from a previous recovery, that old Nano S with Firmware 1.0, 1.1 and 1.2 are only able to sign "legacy" ETH transactions, i.e. pre-EIP-155 transactions that do not contain the chain-ID for replay-protection. And we had to be very careful because of the huge amount of ETH to recover.

So for the recovery, we'd have to sign legacy transactions (using the old ledger) and send them to the Ethereum network. Since the "Berlin" update of ETH, ETH nodes now by default reject legacy transactions (i.e. pre EIP-155, i.e. with no ChainID), since they are considered unsafe, so the only way to push those legacy transactions to the network is via a specially configured Ethereum node that can accept them.

So the next step was for us to get our custom ETH node running and sync'ed, to move those ETH to a new address of the client (of which he did have the seed!), and get those Txs sent to the Ethereum network for execution, via our node.

The main difference with the previous recovery with Firmware 1.2 was that, when ETH was still Proof-of-Work, making a custom ETH node configured to accept legacy Txs was very simple with Geth using so-called "light node" or "light client". Light clients use very little disk space and sync very fast, as light nodes do not download the ETH blockchain, but rather rely on other full nodes (peers) that are configured to help light nodes.

Since Ethereum switched to Proof-of-Stake, Geth light nodes are not supported anymore. Also, there is now a Consensus layer (that uses the so-called beacon chain), so in addition to running Geth (the "execution" client i.e. node), a "consensus" client must also be run (we used Prysm) in order for the full node to sync to the Ethereum network / blockchain..

Running the node we needed for this recovery therefore required significant processing power, Network bandwidth and SSD disk space. We decided to use Amazon AWS, and the goal was just to get this node running sync'ed during the recovery process, and discard it after the job was done. So we used an AWS instance that was slightly oversized (8 cores, 32 GB RAM, 20 Gbit/sec), and a SSD block device of 2TB with fast performances.

Since we had never configured and run a Proof-of-Stake Ethereum full node with Geth and Prysm on AWS, we had to learn, experiment and try things out, so it took about 4 days before we got our node properly configured and running.

We then pushed a valid test "legacy" signed transaction to our node, and... 'error: exceeds block gas limit'. :(

After a bit of panic, we realized that the node was not fully Sync'ed, so it could not process the Tx (the error message should have been "Node not sync'ed"!!). Once the node was actually sync'ed, the test Tx was accepted, and appeared as confirmed on the blockchain a few seconds later. All good!

At that point we got online with our client (remotely), and first we made sure they the a new ETH address they planned to use to deposit the recovered ETH was fully under their control, They got it from a new ledger device (of which they did have the seed well secured!).

Then, the client started signing legacy transfer transactions using our command-line tools (running on linux on their virtual machine, connected to their old ledger), checking and confirming each transaction on the ledger device itself.

We then decoded each signed Tx, both on our side and on the client side, to triple-check that all the parameters (especially the destination address!) were correct, then we manually submitted each signed Tx to our node, which were processed in a few seconds and were visible and confirmed in etherscan.

Of course we started with a tiny test then used small amounts first, and made sure the funds were sent to our client's new ETH account.

The process was stressful (a single typo could send hundred thousands dollar worth of ETH into deep space!!). Everything went smoothly. The ETH account secured by the old ledger is now empty, apart for a few dollars worth of ERC20 tokens not worth recovering.

One interesting thing that we noticed is that as soon as we transferred large amounts, address-poisoning bots sent 0-ETH transactions to the old ledger account, with a from address starting by the same 5 characters and ending by the same 4 characters as the address we previously deposited to, hoping that we might copy-paste the "poisoned" deposit address from etherscan to accidentally transfer large funds to those hackers / scammers. So be very careful with address poisoning, and NEVER copy a deposit address from a past transaction that you see on a blockchain explorer like etherscan.

In the end, we were able to successfully recover all the funds (worth 1.25 million dollars), and both our client and us were very happy :)

Recovery would have been trivial if client didn't lose their recovery seed, of course.

[ADDED COMMENTS]

Someone asked: How much was your fee?

Answer: read this comment thread: https://www.reddit.com/r/ledgerwallet/comments/1af8ei9/comment/ko8utkn/?utm_source=reddit&utm_medium=web2x&context=3

Someone asked: I have some Eth from 2017/2018 that I have in my Ledger Nano and that account is marked (legacy). That account was generated in the Ledger at that time. Should I be worried that I wont be able to send my Eth out of this wallet in the future?

Answer: nope, you'll have no problem. ETH accounts marked "legacy" in Ledger Live just means that they are derived from a legacy / MEW derivation path. This has no effect on the transaction format being legacy (those are completely unrelated). Tx format depends on the firmware of the ledger used for signing the Tx. As long as you have your 24-word recovery / seed phrase, you will have full access to all your ETH on your old accounts, even if your ledger device become too old / unsupported, breaks or gets lost. Do NOT lose your seed, and protect it well from unauthorized access.

Someone asked: How did YOU verified the client's integrity. How was your fee paid?

Answer: read this thread: https://www.reddit.com/r/ledgerwallet/comments/1af8ei9/comment/kogchsq/?utm_source=reddit&utm_medium=web2x&context=3

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/