TL;DRVerlieren Sie Ihren Recovery-Seed nicht!

Ein Kunde kam zu uns mit einem alten Nano S mit Firmware 1.2, weiß PIN aber verloren Seed, und versuchen, den Zugang zu 24 ETH und $50 + k Wert von ERC-20 Token wiederherzustellen.

Die alte Nano-Firmware 1.2 kann nicht aktualisiert werden, und selbst wenn sie es könnte, wäre es zu riskant gewesen, da der Kunde seinen Seed verloren hatte. Die Ethereum-App auf ihrem Ledger hat keine Versionsnummer, aber sie hat die OptionBrowser-Unterstützung”. Also beschlossen wir, die Wiederherstellung mit einer alten Version von MyCrypto zu versuchen, die mit dem alten Ledger kommunizieren konnte (und früher für solche Wiederherstellungen funktionierte). Wir waren in der Lage, einen Test-Tx auf dem Gerät zu signieren, aber als wir den Tx an das Netzwerk sendeten, bekamen wir nun einen Fehler: *nur abspielgeschützte (EIP-155) Transaktionen über RPC erlaubt*. Hmmmm

Also dachten wir uns, wir sollten es vielleicht mit den Low-Level-Tools versuchen, die wir für ein [earlier recovery of ETH from an older ledger](https://www.reddit.com/r/ledgerwallet/comments/kz2eob/successful_recovery_story_how_we_recovered_100/).

Wir haben also ein bootfähiges virtuelles Linux-Image mit den Low-Level-Tools an unseren Kunden versandt und konnten einen Test-Tx mit seinem Ledger signieren, und als wir ihn an das Ethereum-Netzwerk sendeten, erhielten wir denselben Fehler:

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

Nach einer Untersuchung haben wir festgestellt, dass seit dem jüngsten Ethereum Berlin Hard Fork alle Ethereum Nodes nun pre-EIP-155 Tx’s ablehnen, d.h. Tx’s, die nicht die ChainID enthalten, die für die Replay Protection verwendet wird.

Siehe Details hier: [https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md)

Also haben wir unsere Low-Level-Tools so modifiziert, dass sie EIP-155-Transaktionen mit der korrekten ChainID erzeugen und signieren.

Aber wir fanden heraus, dass die [Ledger Ethereum apps older than version 1.0.8 generate an invalid signature if EIP-155 transactions are passed to them](https://www.reddit.com/r/ledgerwallet/comments/n9tdlh/old_nano_s_with_firmware_12_and_earlier_cannot/). Sie erzeugen eine Müllsignatur mit v=27 oder v=28, statt einer korrekten EIP-155-Signatur mit v=37 oder v=38 (für ChainID=1). Ethereum Apps Version 1.0.8 (verwendet auf Nano S mit Firmware 1.3.1) und alle späteren Versionen sind in der Lage, EIP-155-Transaktionen korrekt zu signieren (wir haben das überprüft).

Daher sah es ziemlich problematisch aus, ETH- und ERC-20-Token von diesen alten Ledgern (Firmware 1.0, 1.1 und 1.2) wiederherzustellen, da die Ethereum-App auf diesen Geräten nicht aktualisiert werden kann (und dass die Ethereum-App Version 1.0.8, selbst wenn sie mithilfe von Entwicklungstools auf die Seite geladen werden könnte, wahrscheinlich nicht mit diesen älteren Firmwares kompatibel ist, sodass eine benutzerdefinierte Version der Ethereum-App wahrscheinlich nur für die Wiederherstellung entwickelt werden müsste, was eine Menge Arbeit ist).

Glücklicherweise haben die Ethereum-Leute bestätigt, dass EIP-155 *im Moment* nur durchgesetzt wird, wenn ein signierter Tx eingereicht wird, und dass es intern im Ethereum-Netzwerk nicht durchgesetzt wird, aber die interne Durchsetzung ist in der Ethereum-Roadmap. Wenn dies geschieht, wird dies wahrscheinlich machen solche Wiederherstellungen viel komplizierter, wenn nicht unmöglich (wie es erfordern würde, die Entwicklung und Seite-Laden eine angepasste Ethereum app auf die alten Ledger).

Daher haben wir einen privaten Geth-Ethereum-Knoten auf unserem Server konfiguriert, der diese alten, vor dem EIP-155 signierten Tx akzeptiert und sie an das Ethereum-Netzwerk sendet.

Mit unserem angepassten Ethereum Node und unseren Low-Level-Tools, die unter Linux in einer Virtualbox auf unserem Client-Computer laufen, konnten wir die Transaktionen signieren und erfolgreich übertragen, um die ETH wiederherzustellen.

Wir gerieten ein wenig in Panik, als der Ledger einenunbekannten Fehlerzurückgab, als wir versuchten, Transaktionen zu signieren, die Vertragsdaten enthielten (um die ERC-20-Token wiederherzustellen)… bis wir erkannten, dassVertragsdatenin der Ethereum-App des Kunden-Ledgers einfach nicht aktiviert worden waren.

Am Ende waren wir in der Lage, alle Gelder nach ein paar Stunden Arbeit erfolgreich wiederherzustellen!

Die Wiederherstellung wäre trivial gewesen, wenn der Kunde nicht seinen Recovery-Seed verloren hätte, natürlich.

In der gleichen Recovery-Serie:

[https://www.reddit.com/r/ledgerwallet/comments/kz2eob/successful_recovery_story_how_we_recovered_100/](https://www.reddit.com/r/ledgerwallet/comments/kz2eob/successful_recovery_story_how_we_recovered_100/)

[https://www.reddit.com/r/ledgerwallet/comments/m4pk7q/successful_recovery_of_btc_from_a_hw1_ledger/](https://www.reddit.com/r/ledgerwallet/comments/m4pk7q/successful_recovery_of_btc_from_a_hw1_ledger/)

Abone ol
Bildir
misafir
0 Yorum
Satır İçi Geri Bildirimler
Tüm yorumları görüntüleyin