Hello everyone, useless-user with you again, I hope everyone is doing okay
Today, I finally received the Trezor Ones I asked my supervisor to get me in order to do some tests. In previous posts, I am trying to reproduce the results of an article. In order to do so, I need to downgrade to versions older than v1.8.0 of the firmware. I haven’t turned the devices on yet, I want to make sure not to install a firmware version from which i wouldn’t be able to downgrade the firmware version. Upon looking for an answer to my question (is it possible to downgrade to versions older than 1.8.0) I stumbled on the downgrade-firmware-trezor-model-one link which clearly states the versions from which and to which it is possible to downgrade. This makes it seem impossible to downgrade to versions older than 1.8.0.
However, the trezor-firmware docs, under the legacy section, makes it seems possible to install custom firmware, therefore (and this is pure assumption from my part) it is possible to install versions older than 1.8.0 (as custom firmware, if it’s not possible to directly downgrade to it).
Can anyone please confirm or refute my theory ? If it is indeed possible to ‘downgrade’ to older versions, can anyone please give me a link to help me achieve it.
Thank you in advance
It’s possible in theory to build a firmware version older than 1.8.0 and install it, in “unofficial” mode, on a Trezor One.
In practice, you are going to run into trouble because the linking process has changed at version 1.8.0. The problem is the new file header.S that you will (a) need to embed into the linking process somehow (see memory_app_1.8.0.ld), and (b) make sure its data is filled in correctly – specifically the code hashes (see firmware_sign.py).
I don’t know how to do that off the top off my head so you’re on your own 
Hope this helps.
Okay, seems like all the information I needed is here. Is there any link you can forward me to in order to learn more about the linking process changes and/or documentation about it please ?
nope, completely undocumented, sorry. I’d go looking at commits that touch the files mentioned.
1 Like
I started doing the same, I think I am getting the general idea. Thanks anyways.
So, I tried installing the signed version of the firmware binary and sure enough I had an error saying : “Firmware is too old for your device. Aborting.” So i decided to put on my big boy pants and build the firmware by myself from the trezor-mcu github repository, switched to the tag concerning the version 1.7.1. While building i had to modify some dependencies in the pipfile.lock. However, I get the follozing exception : “Exception: bootloader has to be smaller than 32768 bytes”
Is this exception related to the linking process changement ? if not, how can I resolve this, please. Help Please @matejcik
The easiest you can do is find what command is producing that error and just skipping it or editing out the check. It might be difficult to fix the underlying problem, and you don’t actually need to build the bootloader – your unprivileged firmware is not going to be installing it anyway.
Thank you, I did that. However for installing the generated firmware image I had to add the ‘-s’ flag to skip firmware integrity verification and the binary installs on the device. However the device shows the follozing Error :
Wrong frimware header.
Unplug your TREZOR, reinstall firmware.
I am assuming this is happenning because of the problem you mentionned in your first reply, right ?
that’s a very reasonable assumption, yes.
the header.S file is declaring a header structure that the bootloader expects to find at start of firmware. If you don’t manage to link it correctly at start of the generated file, the structure will be missing.
Note that you can’t just take the firmware binary and prepend the header (which is what was done pre-1.8.0). Previously, the firmware header with signatures would be stored in Trezor separate from the rest of the firmware. But in the new format, it’s part of the firmware image. Adding or removing the header messes up the internal jump offsets etc. in the compiled code.
Also, an important part of the header is a code pointer at 4 bytes in. Get that wrong and your firmware won’t run.
1 Like
Okay, thank you a lot for the help.
I am going to try all of this. I’ll let you know either way, and provide you with all the modifications I’d have to do to make it work.
Hello again for a third time, I guess you are getting tired of my posts but please bear with me. SO I applied the necessary modification (I guess) and the firmware installs correctly (I guess x2). When I plug the device I get the following message :
WARNING
unofficial firmware detected
I press the I’ll take the risk button which causes the device to prompt me the firmware fingerprint (to compare with the one I get while compiling i suppose). Then I press continue and BAM! I get the following :
Unknown bootloader detected.
Unplug your TREZOR, contact your support.
I thought the trezor comes with it’s own bootloader and the one that’s compiled during compilation of firmware is not used. Any idea where this error comes from ?
It doesn’t even seem like I can reinstall the firmware to try again (or at least I don’t know how). @matejcik sorry again for the ‘obsolete’ posts.
you have to set something like, uhhh MEMORY_PROTECT=0 for the compilation?
The “Unknown bootloader detected” is your compiled firmware already running. You can locate the string and see the code that produces it. I believe it’s the part of code that checks if a bootloader is one of the known ones, and if yes, it replaces it with its own copy. When you disable “memory protect” (in later versions called PRODUCTION), the whole bootloader test-and-update chunk should disappear. If not, just manually edit it out.
uhhhh the normal way? hold down the button while plugging in?
Oh, I was setting PRODUCTION env variable to 0 I only had to set MEMORY_PROTECT instead. The firmware seems to be working fine. Thank you a lot for your help. If you want to know all the modifications i made to your code (not much), let me know.
1 Like