[mrb]

I would be immune to this attack because I always generate my own seeds, on a trusted computer. So I set up hardware wallets to import my seed, instead of trusting their seed generation algo. Of course this procedure doesn't protect against other hardware attacks, for example the wallet exfiltrating the private key somehow (R/F signal), but it certainly raises the bar for hackers.

[mattdesl]

Although you do open yourself to vulnerabilities in how you generate your random entropy—for average user, it might be worse than relying on a hardware wallet.

The safest play here for an average user is to just not buy your hardware wallets off eBay, as it seemed to be the case in the OP!

[drdrey]

you still trust that the hardware will use the seed you provided and not one of the pre-generated ones

[PretzelPirate]

You don't have to trust that at all. You can verify that the wallet signs a message with the correct private key that was generated offline.

When you send funds to the wallet, you don't need to send them to the address that the wallet presents, you can send them to the address you calculated during offline key generation. As long as you use the Trezor derivation path on your offline machine, it's predictable what the first address will be.

[mrb]

No because I feed my wallet public key (xpub) to scripts that derives the wallet addresses, and I verify that the derived addresses match what my wallet generates. I'm paranoid like this :)

Granted that would be really inconvenient to do if one used the wallet on a daily basis. In my case I use it rarely enough (large transactions only) that it doesn't bother me that much.

[tromp]

What software do you use to generate your 256-bit seed, and to convert that into the 24 words that the hardware keys require as input?

[mrb]

A custom script that essentially reads /dev/urandom and feeds the hex seed to bip39tool from pybitcointools.