Model T Support / Trezor One Firmware 1.7.1 about trezor.net

[touchjet]

@MelbourneDeveloper FYI

[touchjet]

Trezor Model T is a composite device, messages are going through the "TREZOR Interface" not the HID device.

[touchjet]

Trezor Model T uses USB in a different way. Simply changing PID/VID and some other parameters isn't working (at least on Windows). It seems that data needs to be send directly to and read from certain endpoints according to trezord-go source code. We may need something like a "Usb.Net" instead of Hid.Net to provide the communication layer.

Hopefully I can find some spare time playing with it later this week and post my results here.

[MelbourneDeveloper]

Thanks for taking a stab! Are you using the UWP or plain .net? I find it hard to believe that Satoshi labs would drop back out to USB. Vanilla USB is really difficult. I can't see any reason why they'd do that. I'll try to get on to the development channel and see what's going on.

[MelbourneDeveloper]

@touchjet also Trezor 1 and Trezor Model T share the same MCU firmware from what i can tell, so I would think that device enumeration would be pretty much the same. Do you have an Android by any chance?

[touchjet]

@MelbourneDeveloper Trezor 1 firmware is written in c trezor-mcu while Trezor Model T is mainly in Python trezor-core. This could be the reason why they changed their USB stack.

The project I tried is your Trezor.Net.Sample, it can enumerate the device but stuck on the initial message exchange on await _HidDevice.ReadAsync() to be precise.

[MelbourneDeveloper]

@touchjet oh yes. You are right.

If you an enumerate the device, it's a pretty good sign that the device will support Hid. There would be no reason to register the device as a Hid device if Satoshi Labs didn't intend on supporting Hid transfer.

Have you tried all the different devices available? My guess is that there will be a couple of different ones registered for different Usage Page and Usage IDs. Would you post some pictures from the device manager?

[MelbourneDeveloper]

Thanks for your research. I have to decide if I'm going to fork out for one now and try to figure out how this works.

[MelbourneDeveloper]

@touchjet you might want to join this Gitter community:

https://gitter.im/trezor/community

[matejcik]

Trezor T is using WebUSB and Trezor One will move to WebUSB soon too. This is because it's possible to use WebUSB devices with Google Chrome directly.
There's a HID interface on TT but it's only used for U2F.

FWIW you can update your Trezor One to v1.7.1 and test with that. The USB interface should be identical to Model T, except for different vid/pid

[MelbourneDeveloper]

@matejcik thanks for the information. Just so I understand this correctly...

WebUSB is a JavaScript API built in to Chrome. The Trezor Model T uses a protocol specific to WebUSB for communication. Is that correct? Are Hid, and WebUSB somehow mutually exclusive? Are you saying that the Trezor Model T only supports transfer in Chrome? Doesn't that mean that any apps that aren't Chrome will break? Does the Android Trezor Manager still work?

I tried to upgrade my Trezor One to 1.7.1 but I don't see anywhere to do that in the normal Trezor wallet. Can you please point me to the place where I can upgrade to 1.7.1?

[MelbourneDeveloper]

@matejcik , how would one communicate with the Trezor Model T without WebUSB? Obviously, C# doesn't support it, so what are the options? U2F over over Hid? Is there some documentation on this?

[matejcik]

HID and WebUSB are two different USB sub-protocols ... well, honestly, link-wise I'm not sure if there are any differences.
What is different is that there are HID-specific APIs in many OSes, while there aren't any WebUSB-specific ones. In bridge and python, we use libusb to communicate with the device.
(The Chrome support is just a cherry on top. Any app capable of communicating over USB can talk to a WebUSB device, the advantage here is that it's a proposed standard / JavaScript API in addition. So e.g. on android, chromebook, etc., we can communicate with Trezor straight from the browser without needing the bridge app.)

Re mutual exclusivity, I'm honestly not sure. But in case of Trezor, only WebUSB is going to be supported from now on. No tricks like U2F - you will need to implement WebUSB support. Possibly through LibUsbDotNet, but that's not UWP compatible it seems? From a quick google search, there's Windows.Devices.Usb namespace that could help?

Android Trezor manager still works AFAIK - but that's because Android's USB API seems to work on any devices, not just on HID ones. Also, again, any USB-capable application will work. You just can't use HID APIs anymore.

Re update: it's currently available on beta-wallet.trezor.io, and there's a gradual rollout to users of the regular wallet.

[MelbourneDeveloper]

@matejcik , thanks again for taking the time to explain things. But, I'm even more confused now.

What is different is that there are HID-specific APIs in many OSes, while there aren't any WebUSB-specific ones.

Yep. That's right as far as I understand.

Android Trezor manager still works AFAIK - but that's because Android's USB API seems to work on any devices, not just on HID ones.

This sounds promising because I ported from the original code from the Android library to .NET. I can only assume that if the original Android app works on Trezor One, then at least the Android library will continue to work.

in case of Trezor, only WebUSB is going to be supported from now on.

Understood. So, the question is: is WebUSB an API or a protocol? I understand that Chrome has a built in JavaScript API, but in what way is the data transfer (protocol) different between Trezor One, and Trezor Model T?

you will need to implement WebUSB support

Is there documentation so that I can see how the data transfer has actually changed? There is this documentation: https://wicg.github.io/webusb/ but it's not Trezor specific at all.

Big question:

Assuming WebUSB is a new protocol, does said protocol work on top of Hid? Or, is it lower level - i.e. where we will need to scan the COM port for data transfer?

[matejcik]

Well. You've caught me here, it turns out that I don't really know ;)

What I do know that the new thing is on the same level as HID, maybe even lower. You definitely can't use HID APIs to talk to a WebUSB device, simply because HID will not see it.

We don't care about the WebUSB API as defined in JavaScript/Chrome.
We do care about the WebUSB contract, i.e., what makes the device visible to said JavaScript API.
As for the API to use, we use libusb_interrupt_transfer, which I assume is as close to "raw USB" as it gets? In python the libusb API is actually rather nice to use; in Go, there's a custom higher-level wrapper on the low-level C functions. In Java there's some sort of read/write method. I'd expect that something similar would be available in .Net too. I don't think it gets as low-level as polling a COM port.

When you get down to it, and actually have a read(buf, length) and write(buf, length) calls, it's the same as it was with HID, i.e., read/write in 64byte chunks.

[MelbourneDeveloper]

@matejcik

new thing is on the same level as HID, maybe even lower. You definitely can't use HID APIs to talk to a WebUSB device, simply because HID will not see it.

This is the crux to understanding the problem. If it's on the same level - no problem! If it's lower, then Hid is in the toilet.

You definitely can't use HID APIs to talk to a WebUSB device

Understood. But, does Trezor Model T support Hid as well? You mentioned that it only supports Hid with U2F. Is the documentation for this?

We do care about the WebUSB contract, i.e., what makes the device visible to said JavaScript API.

Understood. But, we don't care about WebUSB contract. Unless my understanding is incorrect, WebUSB contracts cannot be used from C#. WebUSB is a relatively new Chrome/JavaScript only API. So, C# simply won't support it. We need to communicate with the device through some other protocol.

In python the libusb API is actually rather nice to use; in Go, there's a custom higher-level wrapper on the low-level C functions. In Java there's some sort of read/write method. I'd expect that something similar would be available in .Net too. I don't think it gets as low-level as polling a COM port.

If all these technologies can talk to Trezor Model T, and they haven't changed that much from Trezor One, it sounds as though other technologies like C# should still work... C# just wraps Java on Android, so if that still works, then C# should be able to work as well.

When you get down to it, and actually have a read(buf, length) and write(buf, length) calls, it's the same as it was with HID, i.e., read/write in 64byte chunks.

I guess I will have order a Model T and reverse engineer all the code to see how it has changed from Trezor One.

[touchjet]

@MelbourneDeveloper WebUSB is not on top of the HID, that is the reason there's no easy way using your Hid.Net library to communicate with Model T. However, the way Model T sending/receiving messages through the WebUSB interface is quite straight forward.

It can be easily supported with Xamarin.Android porting the trezor-android Java code.

On the PC side, I think the best tool available is LibUsbDotNet.

[MelbourneDeveloper]

@touchjet, if that's the case, the Android sample should just work. It uses the Xamarin Android USB API. Are you able to set the vid/PID in the sample and try it? It might be in a few places.

If LibUsbDotNet is the way to go, we just need to write an IHidDevice wrapper for it and pass it in to the constructor of the TrezorManager.

However, everything I'm reading tells me that WebUSB is a library - not a protocol. The real question is whether or not Trezor One 1.7.1 / Trezor Model T will continue to support Hid... If not, what protocol will it use?

[MelbourneDeveloper]

Anyway, I'll try upgrading the firmware to 1.7.1 this weekend and see if Trezor One still works. If it still works, there's no issue. If not, I'll start the reverse engineering/porting brain scrambling process.

[MelbourneDeveloper]

@touchjet @matejcik

I upgraded my Trezor One to 1.7.1. I can confirm that the old Hid interface has disappeared. There is still a U2F device that exists. This is it. Notice that the Vid, and Pid are the wrong way around. I.e. They are incorrect and will break all the stuff.

The Trezor.Net library is broken on UWP, Android, and vanilla windows, but the Trezor Manager app does work. So, the question is how and why it works... This library (Trezor.Net) was basically ported from the Trezor Android Manager app. So, I'm pretty baffled as to what is going on.

It looks like I've got a long hard road of pulling my hair out ahead of me.

[matejcik]

Once again let me be very clear: on the new Trezors, i.e., TT and T1 from version 1.7.0 up, the HID interface is useless for communicating with Trezor.
Just ... forget about it. It will not do what you want it to do.

(the purpose of the HID interface is to implement U2F protocol, which is defined on top of HID, so it needs a HID interface. Trezor's HID interface will therefore only talk the U2F protocol and nothing else. And in turn, the WebUSB interface will not talk U2F. This prevents issues like https://www.wired.com/story/chrome-yubikey-phishing-webusb/)

So yes, HID is in the toilet.

VID/PIDs are different from original Trezor One firmware, and same as on Trezor T.

I had a brief look at your Hid.Net sources, and it seems that in the UWP code there is only place that is HID-specific: here you query HID properties but you could be querying generic USB properties.
For the Android version, there is nothing HID specific far as I could tell, so maybe it could Just Work with updated vid/pid? You'll have to filter that it's "vendor-specific" class (see device clases) in order to skip the HID interface.

Only the Windows implementation uses HID API calls, that will need to be changed.

[MelbourneDeveloper]

@matejcik thanks. Actually, what is the new Vid/Pid?

I mean what is it supposed to be? I don't understand why the Vid has changed... The Vid should remain static for the company, and the Pid should change from product to product, or version to version. But, from T1->T2 it's different.

[MelbourneDeveloper]

This is the code from the Trezor Android Manager:

If I understand this correctly, the new Vid is 4617, and the two valid products are: 21440, and 21441. Which the two Pids is the Trezor One 1.7.x?

[MelbourneDeveloper]

I just tested it with Firefox. The beta wallet works fine with firmware 1.7.1. However, if I turn off the Trezor bridge, it is broken. This proves that the Beta wallet in Firefox is still talking Trezor bridge and not via WebUSB. The Trezor Bridge is talking to the device via some protocol, and that's the protocol I need to get working...

[MelbourneDeveloper]

@matejcik, , yes, you are right. I corrected the Vid/Pid on Android and now it works fine. The new Vid/Pid for Trezor One is: 0x1209, 0x53C1

@touchjet if you use 0x53C0, it should work for Trezor Model T on Android.

I will work out what I need to do to get Windows and UWP working.

[MelbourneDeveloper]

@matejcik I can see how to fix the problem in UWP now. UWP's Hid and Usb libraries are similar but not the same. I am going to have to write a provider for USB. It should be OK, but will take time.

But, this all begs the question - why did Satoshi Labs ditch Hid? What is so bad about Hid compared to the slightly lower Usb protocol?

[matejcik]

pID 0x53c0 is bootloader, 0x53c1 is the device in normal mode

But, this all begs the question - why did Satoshi Labs ditch Hid? What is so bad about Hid compared to the slightly lower Usb protocol?

I wasn't there for the decision, but I assume the point is native WebUSB in browsers. This allows the wallet (and all Connect-enabled services) to work on Android / ChromeOS without additional software. Unfortunately it looks like WebUSB is dead on arrival, Mozilla really doesn't want to implement it, but we couldn't have known that a year ago.

[MelbourneDeveloper]

@matejcik thanks. Yes, the new Trezor wallet doesn't even use WebUSB. Firstly, Firefox still works as long the Trezor bridge is on. Secondly, Chrome still gives you a warning message that the Chrome Extension is going to be deprecated in favour of the Trezor bridge, and then, like Firefox doesn't work without the bridge.

Trezor has always worked fine from Android and other OSs. It's a platform agnostic device. There's just no cross platform JavaScript library.

Anyway, you guys can switch to Wasm now. It's going to be a lot better than JavaScript. I'll probably have a wasm version of Hardfolio sometime early next year. That will run multiple hardware wallets including Trezor within a browser. I'm not sure what wasm's USB security is like but I imagine it's totally doable.

For my two cents, it would be worth reenabling HID on both devices so that all the existing apps aren't just broken over night.

[MelbourneDeveloper]

I'm stuck. I can get access to the device by USB, with the Windows APIs. I can write to the device. But, when I call ReadAsync, it says "Incorrect function".

Trezor.Net is not available for firmware 1.7.1 or Model T.

[MelbourneDeveloper]

@matejcik I'm really stuck. I removed all the Hid specific code from Hid.Net. It can now find the Usb (non-Hid) device, and I can open up a file handle with CreateFile (kernel32) but any subsequent calls either fail outright, or just hang.

Can you point me to any libraries that can successfully connect to the new firmware with libusb? Even C code or python etc.

[matejcik]

here's python-trezor code: https://github.com/trezor/python-trezor/blob/master/trezorlib/transport/webusb.py
but i'm not sure how helpful it's going to be, it is not similar to libusb C API

[MelbourneDeveloper]

@matejcik thankyou!

I really need some help with this one. I've already looked through the python code. What I really need is an example that uses the windows APIs such as kernel32 or libusb. Any ideas on that?

[MelbourneDeveloper]

Any 3rd party libraries you are aware of?

From what I can see, there should be no difference between accessing via HID and USB. It's more or less the same thing. With USB or his transfer , you just call CreateFile and then write and read from the handle. It's very straight forward but I'm having no luck.

[MelbourneDeveloper]

One of the things that's always puzzled me is that on Android (USB access) the Trezor expects 64 bytes, but on uwp and windows (HID) it expects 65. I don't know why it needs the extra byte. Ledger is the same but KeepKey wants 64.

[MelbourneDeveloper]

@matejcik what I am dealing with is probably peculiarities of the underlying libraries. I've already reverse engineered code from python and Java, but the kernel32 and UWP libraries remain as a black box. I don't know if they treat Hid and USB differently. What happens between the time I send the data to the device and it comes back is a mystery. I need some clues. Do you know of anything that the Trezor does differently between Hid, or USB?

[matejcik]

well you can look at trezord-go source, but I know nothing about Windows APIs

the 64 vs 65 bytes is something about "HID version", where apparently some versions (of the API? of the underlying drivers? who knows?) need a one-byte prefix

[MelbourneDeveloper]

Yeah that sounds about right. So is that hid only? Or do some USB implementations also need the one byte prefix?

I mean, all things being equal, should I be sending 64 bytes and expecting 64 back?

[MelbourneDeveloper]

Actually @matejcik what would help me a lot is if you could recommend a good windows USB trace tool so I can see what goes backward and forward with the Trezor bridge. That would be the best.

[MelbourneDeveloper]

@matejcik I'm able to move forward to some extent. I put a trace on the Trezor web wallet with Firmware 1.7.1 . I used Usbpcap and viewed the results in Wireshark. This is part of what I see

Notice that the input and output reports are 91 bytes in size. I.e. they are divided this way for some reason. You can see the first highlighted message is the Initialize message (3F 23 23). Then the subsequent responses are the features message. But, what is all the stuff in green? I don't need to send that when I use Hid. It's like some kind of 27 byte header.. The real data packet is actually 64 bytes though.

[matejcik]

that's clearly the IRP ID that you see up above in the decoded output, and presumably some other info that you'd see if you scrolled down, see https://desowin.org/usbpcap/captureformat.html

I ... don't think you're going at it the right way. Like, I'm not keeping secrets from you :) there's no hidden depths, in our software at least. We write 64-byte chunks and read back 64-byte chunks, through libusb.
If the raw Windows API behaves differently, I wish you the best of luck but you're on your own, because as I said before, I have no experience whatsoever with Windows API programming.

Why don't you look at what your code sends on the wire? Maybe it's nothing, in which case you need to figure out why it's sending nothing, instead of looking at what should be sent?

[MelbourneDeveloper]

@matejcik

I ... don't think you're going at it the right way.

I know I'm not. That's why I'm asking for help.

We write 64-byte chunks and read back 64-byte chunks

I've written libraries for three hardware libraries across three different platforms. I understand how this stuff works. I've looked at more 64 byte chunks than you can poke a stick at. One of the things that complicates this is that on Android, yes, you send 64 bytes, and get back 64 bytes. But, on Windows, you have to send 65, and get back 65. Why? Who knows...

I said before, I have no experience whatsoever with Windows API programming.

That's fair enough.

through libusb.

This is my question for you. Is there some sample somewhere that talks to the Trezor via libusb? If I can find that, I can circumvent talking to the device via Windows APIs which is probably the biggest problem here. You mentioned Trezor Go. Is that because the Trezor Go library uses libusb?

Why don't you look at what your code sends on the wire? Maybe it's nothing, in which case you need to figure out why it's sending nothing, instead of looking at what should be sent?

That's what I'm doing now.

[MelbourneDeveloper]

I answered my question - yes, Go uses libusb:

https://github.com/trezor/trezord-go/blob/master/usb/libusb.go

I will look in to this. Unfortunately, LibUsbDotNet doesn't actually work right now. I tried to get it working yesterday and it seems completely broken.

LibUsbDotNet/LibUsbDotNet#73
LibUsbDotNet/LibUsbDotNet#74

[MelbourneDeveloper]

@matejcik , @touchjet I got LibUsbDotNet talking to the Trezor:

LibUsbDotNet/LibUsbDotNet#73 (comment)

I don't know why standard Windows IO doesn't work yet. But, LibUsb does the trick. I can move forward in the sense that there is a path to getting this working on vanilla Windows, but better still, I can now bring Trezor.Net to Linux.

[MelbourneDeveloper]

@touchjet hey. The latest unit tests in the repo now support Firmware 1.7.x for Trezor One, and should support Trezor Model T. Would you mind giving it a test? You should be able to run any of the tests in WindowsModelTAndOneTests. You just need to have the Model T plugged in.

[MelbourneDeveloper]

This is being closed for now because LibUsbDotNet more or less plugs the whole on Android, and Windows, but a separate issue will be opened for UWP.