trezor / trezor-core Goto Github PK

when using "personal.listWallets" in geth console,
only can see the FIRST mainet account (m/44/60/0/0) , actually there is plenty of account in m/44/60/0/0 and m/44/1/0/0.

and can't open wallet with URL shown for account 1.

OS: mac os.

just a todo item to look at refactoring out display_pwm_init because now it is not the case that every stage of code resets the clock tree. thus, the timer should not have to be re-initialized. i'll look into this after the other display changes have been discussed.

There are a number of TODOs in the code and wanted to mention these specifically to make sure they are not forgotten. Specifically, the first affects the boardloader so I'd like to get the current thinking on it.

/trezor-core/embed/trezorhal/image.c, TODO: expiry mechanism needs to be ironed out before production or those devices won't accept expiring bootloaders (due to boardloader write protection).

/trezor-core/embed/trezorhal/image.h, TODO: change above limitation to 13 blocks after fixing writing to non-continuous area

/trezor-core/embed/bootloader/messages.c, TODO: pass info about installed firmware (vendor, version, etc.)

/trezor-core/embed/extmod/modtrezorconfig/norcow.c, TODO: error

how to make multisig with trezor?

It's regression from Trezor One.

The SDIO RX FIFO is only 128 bytes large. The read block size is 512 bytes. Delays encountered while performing polling reads with HAL_SD_ReadBlocks are susceptible to FIFO overruns and other abnormal results (like timeouts where only a portion of the data is returned before the peripheral gets into a weird state).

This is most easily reproduced by stepping through with the debugger.

INSTRUCTION_CACHE_ENABLE being 1 in stm32f4xx_hal_conf.h is one thing hiding the issue and saving us usually at full speed. But, other delays can still cause the problem to manifest itself.

In fact, INSTRUCTION_CACHE_ENABLE == 0 and disabling the SDIO_BUS_WIDE_4B (that is, just using a 1-bit bus) works just as well. But, with that config, introducing delay with the debugger still causes RX FIFO overrun.

I was mainly researching this area to see what was possible without PREFETCH_ENABLE and INSTRUCTION_CACHE_ENABLE because PREFETCH_ENABLE can't be used at some voltage levels.

Perhaps SDIO reads should be interrupt driven, or DMA? Maybe the read block size can be lowered? I tried lowering it to 128 bytes, but was getting CRC errors, so either that's not a great approach or I missed changing something else.

As it is currently written, trezord-go and extension detects if device is connected using pings

However, when the device is in waiting for user action, the pings back never come.

As I noticed by adding logs, this functions stops being called when waiting for action (button press etc)

https://github.com/trezor/trezor-core/blob/master/embed/unix/usb.c#L127

it probably makes sense in the context of the USB device. But I don't know where else to put this :)

One of the possible ways is just switch to TCP and throw away this pinging; other way is use a different UDP port for this

missing the second param, needs_backup.

> python2 trezorctl -v recovery_device

$ make emu
./emu.sh
Traceback (most recent call last):
  File "/trezor-core/src/trezor/wire/__init__.py", line 128, in session_handler
  File "/trezor-core/src/trezor/wire/__init__.py", line 126, in session_handler
  File "/trezor-core/src/trezor/wire/__init__.py", line 162, in protobuf_workflow
  File "/trezor-core/src/trezor/wire/__init__.py", line 162, in protobuf_workflow
  File "/trezor-core/src/trezor/wire/__init__.py", line 151, in protobuf_workflow
  File "/trezor-core/src/trezor/utils.py", line 16, in inner
  File "/trezor-core/src/trezor/utils.py", line 11, in inner
  File "/trezor-core/src/apps/management/recovery_device.py", line 41, in recovery_device
TypeError: load_mnemonic() takes 2 positional arguments but 1 were given

Right now if you have a properly configured microSD card in the the slot at reset, then the boardloader nearly instantly starts erasing flash memory.

Perhaps it would be safer to get a user confirmation, or show a N-second timed count down warning until re-flashing starts?

I do want to keep the boardloader simple though. Maybe it's OK as-is since a user would have to go out of their way to have such a microSD card inserted? Feel free to close if that's how you feel, or leave open as a todo.

Easy to reproduce:

• go to wallet
• click on "eye" (or sign tx, or sign a transaction, or anything that requires user interaction)
• reload wallet

Initialize never gets an answer, so the device is never read correctly and requires reconnecting

Getting "Unexpected message" error in both trezorctl / web wallet

Bootloader 2.0.1 / Firmware 2.0.5 / trezorctl 0.9.1

trezorctl load_device -m "all all all all all all all all all all all all"

Traceback (most recent call last):
  File "/usr/local/bin/trezorctl", line 851, in <module>
    cli()
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/click/decorators.py", line 27, in new_func
    return f(get_current_context().obj, *args, **kwargs)
  File "/usr/local/bin/trezorctl", line 283, in load_device
    'SLIP-0014'
  File "/usr/local/lib/python3.6/site-packages/trezorlib/client.py", line 162, in wrapped_f
    ret = f(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/trezorlib/client.py", line 176, in wrapped_f
    ret = f(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/trezorlib/client.py", line 1120, in load_device_by_mnemonic
    skip_checksum=skip_checksum))
  File "/usr/local/lib/python3.6/site-packages/trezorlib/client.py", line 190, in wrapped_f
    return f(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/trezorlib/client.py", line 235, in call
    msg = handler(resp)
  File "/usr/local/lib/python3.6/site-packages/trezorlib/client.py", line 247, in callback_Failure
    raise CallException(msg.code, msg.message)
trezorlib.client.CallException: (1, 'Unexpected message')```

After reset with delayed setup (as on the new wallet), device still shows "Go to trezor.io/start", as seen on the screenshot.

It does not happen on the old wallet with the non-delayed setup, see second screenshot

It can be reproduced on both device and emulator.

Which will be set at the end of the backup process. This will be used to detect broken backup process (i.e. it started, but was not finished).

Another option is to change it from bool (b'' / b'\x01') to int (b'' / b'\x01' / b'\x02')

I'm wondering if it is worthwhile for the boardloader to clear the local memories of used peripherals when possible?

I assume that I'd have to at least enable the peripheral clocks to (and maybe the whole peripheral?) to be able to do this. I haven't tried yet. If it's worthwhile, I can spend the time to figure it out.

I did some research and found the following local memories where this might apply. I wasn't sure which USB peripheral will be used (it's changed a couple of times), so I looked up both.

Side question: Did you wind up using USB HS on the reference hardware? If so, did you need to add an external PHY?

• OTG_FS:
  section 34.10: "The USB system features 1.25 Kbyte of dedicated RAM with a sophisticated FIFO control mechanism."
  section 34.16.1 "Direct access to data FIFO RAM"
  OTG_FS base + 0x20000

• OTG_HS:
  section 35.2.1 "features a dedicated 4-Kbyte data RAM"
  section 35.12.1 "Direct access to data FIFO RAM"
  OTG_HS base + 0x20000

• SDIO:
  section 31.9.15: "The FIFO data occupies 32 entries of 32-bit words, from address: SDIO base + 0x080 to SDIO base + 0xFC"

• FSMC:
  section 36.1: "A Write FIFO, 2-word long"
  probably too small to worry about and should be covered by the display clearing code already

Note: All section references are to the manual RM0090.

when running a command like:
python2 trezorctl get_address -c Bitcoin -n "Bitcoin/0'/0/0" -d
the top of the qr code on the "Confirm address" screen is truncated/obscured by the bottom of the address string. This does seem to affect scanability as when I stopped displaying the address text in /trezor-core/src/apps/wallet/get_address.py the code began scanning quickly/easily.

To simulate a failed firmware update, which leaves the device stalled and displaying only a percentage of the circular progress indicator, I started an update and hit Ctrl+c:

python-trezor$ python2 trezorctl firmware_update -f ../trezor-core/build/firmware/firmware.bin
Please confirm action on device...
<wait for installing firmware screen to display and start working>
^C
Aborted!

I then unplugged and re-plugged the device and got a fatal error:

msg: invalid firmware hash
file: embed/bootloader/main.c:319
rev: 37f6987

In this case, you probably want to start the bootloader's USB loop and treat it as a firmware not present scenario.

Also, from a user perspective, they should be told to simply try again when the firmware installation stalls (without unplugging). That is, this works without unplug/replug:

python-trezor$ python2 trezorctl firmware_update -f ../trezor-core/build/firmware/firmware.bin
Please confirm action on device...
<wait for installing firmware screen to display and start working>
^C
Aborted!
python-trezor$ python2 trezorctl firmware_update -f ../trezor-core/build/firmware/firmware.bin
Please confirm action on device...
True

to erase all RAM similarly to reset_handler here: https://github.com/trezor/trezor-mcu/blob/master/startup.s

When initialize is called with a different state, than the state in the device, calls to getPublicKey do not require passphrase and do return current state - so it seems like the cache is never actually reset.

Hi all,

Love the Trezor.

Was wondering if anyone or group was able to assist me in the customisation of the code to create firmware so that I can use it on custom hardware.

Assistance would be greatly appreciated. Thanks in Advance.

> python2 trezorctl -v sign_message 'abc' -n "Bitcoin/0'/0/0"
...
SENDING <SignMessage> (38 bytes):
<SignMessage: {'message': 'abc', 'address_n': [2147483692, 2147483648, 2147483648, 0, 0], 'coin_name': u'Bitcoin', 'script_type': 0}>
RECEIVED <Failure> (18 bytes):
<Failure: {'message': u'Firmware error', 'code': 99}>

tried the same command against the emulator and got this:

$ make emu
./emu.sh
Traceback (most recent call last):
  File "/trezor-core/src/trezor/wire/__init__.py", line 128, in session_handler
  File "/trezor-core/src/trezor/wire/__init__.py", line 126, in session_handler
  File "/trezor-core/src/trezor/wire/__init__.py", line 162, in protobuf_workflow
  File "/trezor-core/src/trezor/wire/__init__.py", line 162, in protobuf_workflow
  File "/trezor-core/src/trezor/wire/__init__.py", line 151, in protobuf_workflow
  File "/trezor-core/src/trezor/utils.py", line 16, in inner
  File "/trezor-core/src/trezor/utils.py", line 11, in inner
  File "/trezor-core/src/apps/wallet/__init__.py", line 38, in dispatch_SignMessage
  File "/trezor-core/src/apps/wallet/sign_message.py", line 7, in <module>
  File "/trezor-core/src/apps/common/signverify.py", line 5, in <module>
  File "/trezor-core/src/apps/wallet/sign_tx/signing.py", line 14, in <module>
MemoryError: memory allocation failed, allocating 1280 bytes

This only happens when sending <1ETH

so 0.21 ĺooks suboptimal like this:

and 1.21 looks better like this:

I want to update my dev kit to support TREZOR 2 development (https://mcudev.github.io/trezor-dev-kit/index.html).

I need a display.

It looks like the basic requirements are:

• 240x240 pixel
• TFT LCD 18-bit color screen
• ILI9341V or ST7789V driver
• I2C capacitive touch

Do you have any recommendations on a module to use (preferably on a breakout board with headers)?

I see some 240x320 modules, but not 240x240. Is 240x320 what is actually being used?

For example, this looks close to spec: https://www.adafruit.com/product/2090

At

To quote https://gcc.gnu.org/onlinedocs/gcc/ARM-Function-Attributes.html#ARM-Function-Attributes

While using extended asm or a mixture of basic asm and C code may appear to work, they cannot be depended upon to work reliably and are not supported.

Opening this because according to https://preorder.trezor.io/:
"All confidential data, including the PIN, are entered exclusively through the screen."

This meaningfully violates that (I actually care more about the passphrase in this case because the PIN still uses the unpredictable keypad):

./trezorctl -t udp get_address -c Bitcoin -n "Bitcoin/0'/0/0"
Use the numeric keypad to describe number positions. The layout is:
    7 8 9
    4 5 6
    1 2 3
Please enter current PIN: 

Passphrase required: 

Confirm your Passphrase:

See ethereum/EIPs#712

It seems that endpoint 0x05 is problematic - it causes loop in PCD HS handler.

It also causes the same problem when we shuffle endpoints around interfaces differently.

• skip_backup displays "Backup is done!"
• There is no visual indication that the backup has not yet been performed
• BackupDevice is not implemented

Hi,
I'm learning how to work with the emulator. I used this manual. The build was without errors. When I access emu.sh through terminal id outputs:

Traceback (most recent call last):
File "main.py", line 112, in
MemoryError: memory allocation failed, allocating 136 bytes

My system:

Kubuntu 17.10 64bit (plasma)
Python 2.7.14 (pip 9.0.1 from /usr/lib/python3/dist-packages (python 3.6) )
gcc 7.2.0
Kernel 4.13.0-16-generic

I also tried run as sudo user. Outputs the same result.

During device tests, sending the DebugLinkDecision seems to cause the tests to fail due to ButtonAck being sent directly after.

Cannot be worked around without refactoring python-trezor. Essential for security review and fuzzing.

I noticed some visual flicker (there's probably a better word to describe what I'm seeing) while toying around. It's not a horrible problem, but it is common across various functions and could use some polishing.
To reproduce:

1. plug-in device
2. on host: python2 trezorctl wipe_device
3. on device, the "wipe device" screen appears.
4. put finger on screen, but not on the "hold to confirm" button, then move finger around and you'll see some UI disturbance (lots of ephemeral black horizontal lines, i call it a flicker). it kind of looks like a whole bunch of redraws are being requested faster than the screen can update. Perhaps the fix is something simple, like not acting on useless events or events not on some interactable UI elements.

SDIO_IRQHandler is only possibly used by the firmware. It's not used by the boardloader and the bootloader.

It would be nice to not link it with the boardloader so that it does not get into the vector table.
But, need to move to a separate file and maybe disable stack protector and maybe mark sd_handle volatile?

Passphrase origin = ASK, ALWAYS_DEVICE, ALWAYS_HOST

Unset is ASK, otherwise don't perform ButtonRequest round and choose method directly.

Also add new flag to Initialize which can say - I am an "passphraseless" app, so the passphrase won't be used in that session.

Please add

  git submodule update --init --recursive

to the build instructions

In Ethereum, signed messages are usually prefixed with "Ethereum signed message:\n" in order to avoid being able to trick the user into signing transactions.

However, dapps such as decentralized exchanges and others that use signed messages, usually make the user sign a hash. This is not very user friendly, since the user still does not know what they're allowing.

An EIP exists to solve that: ethereum/EIPs#712

This essentially means that the user will know what they're signing, but it requires implementation in wallets. Since the Model T has a large-ish touchscreen, this EIP makes a lot of sense in order to enhance the UX of dapps in the future.

Another consideriation is that since this is a standard, it will remove issues like the one where Trezor uses a bitcoin variant length integer after "Ethereum signed message", vs the ASCII formatted used in Metamask and geth: ethereum/go-ethereum#14794 ( https://github.com/0xProject/0x.js/pull/376/files#diff-0dcbf3991e702af6b8de8208658c581aR111 and https://github.com/AdExBlockchain/adex-core/blob/signed/contracts/ADXExchange.sol#L275 )

Fresh git clone of [master] on ubuntu 16.04 after completing commands in README underr "Debian/Ubuntu" ..

$ make build_unix
make -j 4 -f ../../../micropython/unix/Makefile -C vendor/micropython/unix MICROPY_PY_BTREE=0 MICROPY_PY_TERMIOS=0 MICROPY_PY_FFI=0 MICROPY_PY_USSL=0 MICROPY_SSL_AXTLS=0 DEBUG=1 MICROPY_FORCE_32BIT=1
make[1]: *** vendor/micropython/unix: No such file or directory.  Stop.
Makefile:66: recipe for target 'build_unix' failed
make: *** [build_unix] Error 2

$ mkdir -p vendor/micropython/unix
$ make build_unix
make -j 4 -f ../../../micropython/unix/Makefile -C vendor/micropython/unix MICROPY_PY_BTREE=0 MICROPY_PY_TERMIOS=0 MICROPY_PY_FFI=0 MICROPY_PY_USSL=0 MICROPY_SSL_AXTLS=0 DEBUG=1 MICROPY_FORCE_32BIT=1
make[1]: Entering directory '/home/jcalfee/opt/trezor-core/vendor/micropython/unix'
../../../micropython/unix/Makefile:102: ../py/mkenv.mk: No such file or directory
../../../micropython/unix/Makefile:116: ../py/py.mk: No such file or directory
../../../micropython/unix/Makefile:288: ../py/mkrules.mk: No such file or directory
make[1]: *** No rule to make target '../py/mkrules.mk'.  Stop.
make[1]: Leaving directory '/home/jcalfee/opt/trezor-core/vendor/micropython/unix'
Makefile:66: recipe for target 'build_unix' failed
make: *** [build_unix] Error 2

WebUSB is a new standard that will probably be implemented in Chrome and Firefox soon-ish (it is already in newest builds of Chrome in experimental mode).

It would be nice to support it right "off the bat". But I am not sure how hard would that be.

referencing slide 29: https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Datko-and-Quartier-Breaking-Bitcoin-Hardware-Wallets.pdf

there are probably some things that we can do to harden image_check_signature against fault attacks. specifically, i'm thinking around the areas of hamming distance to hinder single bit flip glitching on the result check/ensure and checking more than once and comparing results.

Currently, Trezor return malformed public node, which gets rejecting by trezor-agent (ssh).

Traceback (most recent call last):
  File "/usr/local/bin/trezor-agent", line 11, in <module>
    load_entry_point('trezor-agent', 'console_scripts', 'trezor-agent')()
  File "/home/user/projekty/trezor/trezor-agent/agents/trezor/trezor_agent.py", line 5, in <lambda>
    ssh_agent = lambda: libagent.ssh.main(DeviceType)
  File "/home/user/projekty/trezor/trezor-agent/libagent/ssh/__init__.py", line 159, in wrapper
    return func(*args, **kwargs)
  File "/home/user/projekty/trezor/trezor-agent/libagent/ssh/__init__.py", line 279, in main
    for pk in conn.public_keys():
  File "/home/user/projekty/trezor/trezor-agent/libagent/ssh/__init__.py", line 194, in public_keys
    self.public_keys_cache = conn.export_public_keys(self.identities)
  File "/home/user/projekty/trezor/trezor-agent/libagent/ssh/client.py", line 28, in export_public_keys
    curve_name=i.curve_name)
  File "/home/user/projekty/trezor/trezor-agent/libagent/formats.py", line 152, in decompress_pubkey
    raise ValueError(msg)
ValueError: invalid ed25519 public key: b'\x02{l\x01&\n.....<censored>'

...and add unit tests to python-trezor

By default, the My Trezor apps generates BTC addresses at (BIP 49)
m/49'/0'/0'/0/x

It generates LTC addresses at:
m/49'/2'/0'/0/x

It generates BCH addresses at
m/44'/145'/0'/0/x

Would it be possible to include the default BIP number, or possibly even the full default path of the coin? This is related to #95. The reason I ask is because, if a new coin is added, it would be great to get Trezor's default path for the coin. That way, my app can take a good guess about where the coins may be stored and I don't need to create a new version of my app to get the addresses.

python2 trezorctl recovery_device -d
appears to have the same effect on the device as
python2 trezorctl recovery_device

I was also wondering if it would be useful to make the mnemonic display after input by using the 6 screens of 4 approach (or however many screens based on the recovery mnemonic word count). I guess it's not important because of the mnemonic sentence checksum, but it might assure users more that what they thought they input is what was accepted.

When you initialize the Trezor, it returns are Features message. This message includes a list of valid coins. It would be great if each coin object included the coin number so that when we get addresses we can iterate through this coin list instead of just knowing the number.

Also, the GetAddress message accepts the parameter "coin_name". Why? We are already passing the coin number in as part of the path, so why do we need to send a duplicate value?

Sending about 0.01 ETH if I remember correctly.

When I delete the first letter, it is not actually deleted in the GUI. (However, after writing another letter, it overwrites the existing letter.)

I am not sure which passphrase is actually sent, if empty or the stuck letter.

See screenshot from emulator; the same issue is on device. First is correct state with a letter, second is a wrong state with letter removed

I am trying to send Bitcoin Gold from my Trezor Model T wallet, but I get the following error:

"Failed to send transaction
Error details: Transaction has changed during signing"

This error appears on the browser window when I confirm the transaction on the Trezor.

Technical details: Chromium on Linux
beta-wallet.trezor.io

This is my workflow, which always produces mismatch.

• I call device with Initialize
• I get features with a state A in return. I never call any passphrase yet, user never enters any passphrase. Yet I save a state A to the device mode.
• I then call getPublicKey.
• I get ButtonRequest in return.
• To the ButtonRequest, I reply ButtonAck. User select "on host" (on_device false)
• I get PassphraseRequest again
• To that passphrase request, I - for the first time - reply with a passphrase, and add the state A, because that is saved with the device.
• To that, I get a passphrase mismatch.

Where is a step I am doing wrong?

I understand that A is not a hash of the passphrase - since I never enter passphrase and I still get A (so it cannot be derived from the passphrase). But I also don't understand what am I doing wrong.

If invalid block is encountered during firmware update, the whole operation fails. Bootloader should try to redownload the block again (3-times maybe?).

I noticed while entering my mnemonic for the recovery_device flow that if my thumb accidentally tapped the word twice (to accept it) that the extra tap was slow enough that it happened on the "Type #. word" label/prompt and that actually accepted the extra tap as a blank word. This results in an invalid mnemonic. I was expecting that the text label was not interactive.

Similar to trezor/trezor-mcu#289

If a backup is initiated by sending backup_device message to the device, the device displays the "Backup your seed" screen with an "I understand" (hold to confirm) button.

However, the needs_backup: false flag is already set as soon as the backup_device call is received. If the user doesn't touch and hold "I understand" and disconnects the device instead, it will no longer display the NEEDS BACKUP warning on the display or send the needs_backup: true flag in features.

Please only set the needs_backup: false flag after user completes this screen..

When transferring tokens - transferring 1 WALL token in this test - the gas is displayed:

• gas is not payed in the token but in ETH - soI think on the screen above there should be no mention of WALL

In this screen it is correct I guess - just the zeroes should be removed and IMHO it should not be "wei WALL" what I think is behind there - just WALL. Seems a bit similar to #14 - just also happens when value is >1