Trezor - Can a custom chain change the key derivation path?

because MetaMask does not ask for the seedphrase twice when the Trezor Hardware Wallet outputs an address without balance, i have lost crypto to a mistype - probably.
(This is an extremely dangerous implementation imo and i am surely not the first person to get surprised this way. An empty wallet should require 2x passphrase confirmations minimum.)

Here is the scenario:

  1. I wanted to self-custody a microcap.
  2. I setup a clean VM, installed MetaMask and the trezor-bridge (linux).
  3. I added the chain to MetaMask
  4. I connected the Trezor, put in the seedphrase on the device.
  5. It showed me 5 addresses, I selected probably the first one.
  6. Transferred some funds. First a test-transaction, then the full amount, after I saw the funds in the wallet.
  7. I went on with my day.
  8. I later added other coins to other addresses… so I used MetaMask a bunch more.

A week later, i wanted to transfer more funds to the same wallet, but the seedphrase didnt get me to the same wallet. That hit me hard.

My recovery steps so far:

  1. I downloaded the log-files from my MetaMask installation and extracted all addresses that MetaMask ever checked and cached a balance of. This happens for every address that is shown on-screen ever.
  2. I have written a password-brute-forcing program running on my GPU. This program emulates the address generation that happens on the Trezor usually - just with 100k passwords per second.
    Creating this program took me a month and it is still running now.
  3. I am checking the standard BIP44 derivation path 44’/60’/0’/0.
  4. I have a rough idea, what the passphrase must have been.
    β†’ MetaMask saved the timestamp when I connected the Trezor to create the wallet-address in question (interestingly not all trezor-connections are logged as thoroughly! Why is that?)
    β†’ I have a timestamp of when i noted the reference to the used password
    β†’ I have a timestamp when my transactions happened on-chain.
    Everything lines up within a reasonable time window.
  5. I have checked all 5-character passwords (because that is feasible) and the passphrase with all possible mistypes with up to 4 errors and a bunch more stuff that I could think of. I also started to doubt myself and used the same passphrase-checker on my other passwords, just in case.

During this process I have found a lot of passwords that I typed into the Trezor. To be precise: out of 568 cached addresses, my brute-forcer has associated passwords with 515 of them. This leaves 53 addresses undiscovered. Some of those are the MetaMask-addresses which i dont use but they show up in the log-files anyway. Some of them are transaction-source addresses which belong to exchanges. But some of them are the addresses that must have been on screen during the fatal wallet creation.

In short: I fail to find the passphrase for the address in question - the one that matters. All this despite having a reasonable idea about the passphrase and having checked billions of variations.

This really makes me doubt one fundamental question: the derivation path 44’/60’/0’/0
Is there any scenario where this can change? Notably, the β€œ60” in this path is the chain-id (for Eth). And when specifying a custom chain, MetaMask asks for such a chain-id.

Now, in Metamasks defense, all passwords I found, and all test-addresses I generated to validate my password-cracker were indeed on derivation path 44’/60’/0’/0… but i am now getting really worried about, if there could be a bug somewhere. I mean…

  • it was a fresh installation
  • it was a new chain
  • it was the first connection of the Trezor to that system
  • everything after that action created confirmable addresses (even if I mistyped!), just not that first interaction.

It would be helpful if some developer or other knowledgeable person could confirm that my search on 44’/60’/0’/0 is the only feasible derivation path. I am burning a lot of power in my GPUs…

Thank you!

1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.