Since simplewallet has been renamed in 0.10 will you have to make a new release of your firmware for compatibility?
Experimental trezor firmware testing
NoodleDoodle posted this 8 years ago
DO NOT UPGRADE YOUR FIRMWARE IF YOU DON'T HAVE YOUR RECOVERY SEEDS
I worked on a trezor firmware which supports XMR awhile back but stopped development around August last year. I want to "complete" the firmware soon and then release the source to github when it's somewhat stable. I'm releasing the binary since I need help testing the current version.
While there are user interaction limitations, the firmware is fully functional and can be used to sync accounts as well as transfer XMR from active accounts. Only simplewallet is supported at the moment and from my testing, windows is fairly stable while linux needs some work [FIXED].
The firmware is compatible with BTC and does not remove any functionality available in the official firmware. The source is upstream compatible and can be merged to the official source (if they want to). XMR uses the same seed as BTC so you can restore your old seed anytime and regain your old account.
There are important points to note:
- The viewkey is sent to the client. A bad client could potentially store these keys and see all incoming transactions to your account, privacy is then compromised.
- The client has no access to the sendkey and can only request the device to generate key images or sign transactions. Your funds are safe.
- It takes about 40ms to generate each key image. For large wallets, re-sync is going to take a while, so keep the wallet bin files.
- [FIXED] The send confirmation prompt is incomplete. It will be fixed in subsequent versions.
- [FIXED] There is no reconnect/retry implemented in simplewallet at the moment.
- Max mix level is 9
V0925: trezor_xmr_test_firmware_0925
- Updated to trezor source v1.4.0
V0313: trezor_xmr_test_firmware_0313_win64
V0313: trezor_xmr_test_firmware_0313_linux64
V0313: trezor_xmr_test_firmware_0313_osx64
- Fixed Bus: 10 error
V0311
- Added reconnect handler when trezor is unplugged while simplewallet is active
- Added tx_seckey storage support to firmware
- Added support for 'address' simplewallet command
- Fixed support for entering passwords when trezor is initialized/recovered with password protection enabled
V0306
- Added binaries for linux-64 and osx-64
- Fixed usb transport bug in linux/osx
- Updated source to master b96147030cf06b7adacafebff196bc23a4b19199
- Added trezorctl to wipe, reset, recover the trezor
- Added trezorctl option to recover the monero mnemonic from the trezor seed given a specific address index
V0303
- Added send prompts when transferring xmr with multi destination support.
- Fix: added error handler when mixin level is > 9
- Fix: added error handler when sending to > 10 addresses in a single transaction.
V0301
- Test release
Upgrade instructions:
- Disconnect the trezor from the USB cable.
- Press both buttons on the trezor then connect the USB cable.
- Run upload.bat. Wait until new firmware upload is completed.
- Verify firmware fingerprint (from fingerprint.txt)
- Disconnect then reconnect trezor to USB.
- Go to MyTrezor.com (using CHROME) and initialize your device. (You have the option to restore your SEED words if you want to keep using the trezor with your current BTC (etc.) account.
- Close CHROME. Otherwise, it will not release the trezor USB device and simplewallet will not find it.
- Run simplewallet.exe --hardware-wallet n (n can be any reasonable number eg. --hardware-wallet 0)
PIN Entering: https://github.com/trezor/python-trezor
47AYtJeNKJjYNZLj71nBW938mbFSFwq1x4qVcNhBmdfUjhaqiGN7wqpVjH419eLYPzHFeF3TgzY2fDivz5EyGBYUSbAXwed
Had a serious issue installing V0313 OSX64 using: % ./trezorctl update trezor.bin.
The message generated by a Trezor device with prior production Trezor firmware v.1.4.0 installed was: Firmware installation aborted. You need to repeat the procedure with the correct firmware.
Effectively, the V0313 supplied "notes.txt" file really needs a step 0 for those not installing the Monero firmware on Trezor device "straight out of its tamper proof box".
The solution was to wipe the Trezor device before the loading Monero firmware. Ended up using the https://github.com/trezor/python-trezor package that has a Python implementation of trezorctl that can be easily inspected for how to apply, e.g. "python-trezor/trezorctl -h".
% python-trezor/trezorctl wipe_device <- Wiped the Trezor device to put it into a ground state prior to a 3-finger "bootloader" mode
% python-trezor/trezorctl firmware_update -f trezor.bin <- Is executed around 5 seconds after a Trezor device is connected into a USB port (to ensure a Trezor has hit steady state) with a Trezor 3-finger "bootloader" death grip prior to releasing the death grip.
From experimentation, I noticed uploading production Trezor firmware had no sensitivity to being previously wiped, for example following worked flawlessly:
% python-trezor/trezorctl firmware_update -u https://wallet.mytrezor.com/data/firmware/trezor-1.3.5.bin
If Trezor firmware files were downloaded locally using a command such as:
% curl -vL https://wallet.mytrezor.com/data/firmware/trezor-X.Y.Z.bin -o trezor-X.Y.Z.bin
It was a requirement to first wipe a functional Trezor device prior to uploading a local firmware file with a command of this form:
% python-trezor/trezorctl firmware_update -f trezor-X.Y.Z.bin
Fingerprints can be verified using piped commands to bitcoin-explorer (bx) *.bin Trezor firmware files, for example:
% tail -c +257 trezor.bin | bx base16-encode | bx sha256
dd209ce2076419860c4899cd13cd9633f0d2f422403eacbb962430ece2958a0a
Production Trezor firmware fingerprints are located here for those desiring rollback to production firmware.
Most everything else proceeded as expected. The number of wallet files decreased, no *.keys exist when an external HD device is used. The infamous "refresh" takes around 20 minutes.
However, I have an issue spending funds managed by a Trezor when I have a "password" in addition to my PIN. The wallet seems to think I have no funds to transfer when the balance shows otherwise.
If one is to compile Monero, what passed "make" arguments will cause the resulting "./build/release/bin/monero-wallet-cli" to support the "--hardware-wallet" input option? Not sure if my assumption that the "master" branch is currently the official fork prior to a Trezor merge into monero-project/monero?
Also, are there any details as to were the source to compile the Monero V0313 ./trezor.bin that is a fork of https://github.com/trezor/trezor-mcu?
Hey NoodleDoodle, can you make the binaries available again? Just bought a second trezor ready to test it out with monero :)
Links updated.
Confirmed that both a Trezor PIN and a password works with simplewallet. Had no luck getting trezorctl's recover_mnemonic functionality to work.
Sources to compile appear to be: 1. simplewallet 2. trezor.bin 3. trezorctl
My monero Hydrogen Helix (v0.9.4) bitmonerod node keeps giving me warnings upgrade. Any word about when Wolfram Warptangent (v0.10.0) monero-wallet-cli will be supported? (Not yet smart enough to get the sources above to compile.)
Confirmed interoperability with a couple transaction tests during the Hydrogen Helix to Wolfram Warptangent transistion. v0313's simplewallet, a fork of Hydrogen Helix (v0.9.4), and the trezor.bin firmware appears to function with a freshly compiled Wolfram Warptangent (v0.10.0) node. Still no luck getting the v0313 trezorctl's recover_mnemonic to function on a Mac Yosemite platform.
Excited this HD wallet technology might be another immediate counter measure to the CSRF vulnerability. However, in the interim while this code is still considered to be experimental, there is a strong need for key recovery Plan B where one can take their Trezor BIP 39 seed words and the integer associated with the --hardware-wallet argument and create a list of 25 Electrum words that a non-HD monero-wallet-cli application uses to reconstitute a wallet using --restore-deterministic-wallet.
If this recovery capability existed, more people will start using this technology because people will have comfort in knowing they can recover their funds if a major bug is discovered in Monero HD implementation(s) or if future ungraceful Monero transaction or protocol changes occur.