@SkorP I think you are referring to Hormann BiSecur which uses AES encryption and the vulnerability documented here which is relevent for devices manufactured up to 2017?
Earlier Hormann units (Series 1) used an 868mhz fixed code arrangement which is what I am referring to in this request. They are older units but still commonly used.
The remotes use a 40 bit fixed code, i assume the first byte in the 5 byte code remains \x00 always.
Here is an excerpt from the Hormann manual referencing backward compatibility:
The procedure for generating a new code and then copying this to the motor’s reciever unit which can be found here is consistent with simply generating a new random code in the handset and then transferring this to the main receiver.
The steps below describe pressing a reset button inside the handset which generates a new fixed code:-
Following this, the code is learned by the main unit by pressing the program button, and then pressing the button on the remote. Nowhere here is there a learning or exchange of an encryption key as you see in the programming instructions for a BiSecur system.
Also most paperwork basically says the blue-button remotes are not BS remotes although I think newer HSE2 remotes can support both systems and the colour represents the frequency.
I did a few tests on an existing remote:
Button 1: XX XX XX 46 01 C0
Button 2: XX XX XX 46 08 C0
I redacted the first 3 bytes although they were the same for both buttons. Using the internal reset button on button 2 reset the code to:
Button 2: 00 DF 39 06 08 C0
In every test I have conducted the first byte remains \x00 and the last remains \xC0.
This is the .sub file for the reset button 2. (37.7 KB)
I derived the 5 bytes using the pulse plotter and manually selecting PWM, Short=512, Long=1024, Sync=12323, Gap=0.
@sedje provided this python script which comes to the same result.