TL;DR – Don't lose your recovery seed!

A customer came to us with an old Nano S with firmware 1.2, knows pin but lost seed, and try, access to 24 ETH and $50 + k restore value of ERC-20 token.

The old nano firmware 1.2 cannot be updated, and even if she could, it would have been too risky, because the customer had lost his seed. The Ethereum app on their ledger doesn't have a version number, but she has the option “Browser support”. So we decided, trying to restore with an old version of MyCrypto, that could communicate with the old ledger (and worked earlier for such restores). We were able to, to sign a test Tx on the device, but when we sent the Tx to the network, we got an error now: *play-protected only (EIP-155) Transactions allowed via RPC *. Hmmmm…

So we figured, maybe we should try the low-level tools, which we for one [earlier recovery of ETH from an older ledger](

So we sent a bootable virtual Linux image with the low-level tools to our customer and were able to sign a test Tx with his ledger, and when we sent it to the Ethereum network, we got the same error:

*Failed to broadcast the Tx:{‘code’: -32000, ‘message’: ‘only replay-protected (EIP-155) transactions allowed over RPC’}.

After an investigation, we found out, that since the most recent Ethereum Berlin hard fork, all Ethereum nodes are now rejecting pre-EIP-155 Tx’s, d.h. Tx’s, which do not contain the ChainID, which is used for replay protection.

See details here: [](

So we modified our low-level tools like this, that they generate and sign EIP-155 transactions with the correct ChainID.

But we found out, that the [Ledger Ethereum apps older than version 1.0.8 generate an invalid signature if EIP-155 transactions are passed to them]( They generate a garbage signature with v = 27 or v = 28, instead of a correct EIP-155 signature with v = 37 or v = 38 (for ChainID = 1). Ethereum Apps Version 1.0.8 (used on Nano S with firmware 1.3.1) and all later versions are capable, Sign EIP-155 transactions correctly (we checked that).

So it looked pretty problematic, ETH- and ERC-20 tokens from those old ledgers (Firmware 1.0, 1.1 and 1.2) restore, as the Ethereum app cannot be updated on these devices (and that the Ethereum app version 1.0.8, even if it could be loaded onto the page using development tools, probably not compatible with these older firmwares, so a custom version of the Ethereum app would likely only have to be developed for recovery, which is a lot of work).

Fortunately, the Ethereum folks have confirmed, that EIP-155 is only being enforced at the moment, when a signed Tx is submitted, and that it is not enforced internally on the Ethereum network, but internal enforcement is on the Ethereum roadmap. When this happens, this will likely make such restores a lot more complicated, if not impossible (as it would require, the development and side-loading of a customized Ethereum app on the old ledger).

Therefore we configured a private Geth Ethereum node on our server, of these old ones, accepts Tx signed in front of the EIP-155 and sends it to the Ethereum network.

With our adapted Ethereum Node and our low-level tools, which run under Linux in a virtual box on our client computer, we were able to sign the transactions and transfer them successfully, to restore ETH.

We panicked a little, than the ledger one “unknown error” returned, when we tried, Sign transactions, contained the contract data (to restore the ERC-20 tokens)… until we realized, that “Contract data” had simply not been activated in the Ethereum app of the customer ledger.

In the end we were able to, successfully restore all funds after a few hours of work!

Restoring it would have been trivial, if the customer hadn't lost their recovery seed, Naturally.

In the same recovery series:



Notify of
Inline Feedbacks
View all comments