Request to support Chamberlain (rolling code)

Sub-GHz
#1

I can only post 2 links. I modified my external links and posted the raw captures and the PCB picture in comments.

Frequency: 315MHz, 390MHz
Modulation: Amplitude Modulation (AM)
FCC ID: HBW7964 (link 1)
IC: 2666A-7964 (link 2)

Device Model: 953EV/EVC
Manufacture Date: 02/15
Other Information:

  • 3 buttons
  • Link below contains information for decoding Sec+ 1.0 and 2.0. (link 3)
  • Only capturing for 315MHz because 390MHz seems to only be for legacy devices (link 4)

Auto Hopping Read

Button 1 - Tied to Chamberlain garage door motor
Security+ 1.0 42b 315AM
key: 0x917E94EF0000A578 ## This changes at different points in time
id1:1 id0:1 Btn:left
Sn:0x056380C6
Cnt:0xA578 ## This changes at different points in time
Sw_id:0x1

Button 2 - Not tied to anything
Security+ 2.0 62b 315.00 AM ## This seems to do both 315MHz AM and 390MHz AM
Pk1:0x3C045F2FB714 ## This changes at different points in time
PK2:0x3D105753A3D0 ## This changes at different points in time
Sn:0x7F84B164 Btn:0x21
Cnt:0xE500055 ## This changes at different points in time

Button 3 - Not tied to anything
Security+ 2.0 62b 315.00 AM ## This seems to do both 315MHz AM and 390MHz AM
Pk1:0x3C282C125BB2 ## This changes at different points in time
PK2:0x3D06AE335EAD ## This changes at different points in time
Sn:0x7F84B164 Btn:0x20
Cnt:0xE500050 ## This changes at different points in time

Links:
Link 1 - FCC ID Info:

Link 2 - Industry Canada Info:
[https://]industrycanada[.co]/2666A-7964

Link 3 - Chamberlain Sec 1.0 and 2.0 Reverse Engineered:

Link 4 - Chamberlain Frequencies:
[https://]support.chamberlaingroup[.com]/s/article/How-to-get-my-old-garage-door-opener-on-the-same-frequency-as-my-new-opener-1484145611617

Attachments:
Garage Remote Board.jpg - This is a picture of the garage remote PCB
Button1.sub - Raw capture of button associated with my garage door. Physically labeled with a 1 on the button.
Button2.sub - Raw capture of button 2. Not associated with anything. Physically labeled with a 2 on the button.
Button3.sub - Raw capture of button 3. Not associated with anything. Physically labeled with a 3 on the button.

2 Likes
#2

Garage Remote Board
Garage Remote Board3226Ɨ1786 646 KB

Button1.sub (34.4 KB)

#3

Button2.sub (62.4 KB)
Button3.sub (62.4 KB)

1 Like
#4

I felt that you would ask for it, and I already did.

or what do you want from me?

2 Likes
#5

Well, damn. I am new to the community and I had no idea that all my requests would be done before I asked for them!

1 Like
#6

I see this was committed to the dev branch. The DFU link created by the Github actions bot leads to a 404 page. So I upgraded to the dev branch on my flipper and it does not seem to work? I cannot save the frequency. It still shows locked.

Was this actually implemented on the dev branch?

Sorry, if I am missing something obvious. I am new.

1 Like
#7

flipper is a mega creation that can predict the desire of ordinary people. yes DEV have everything

1 Like
#8

Hey sorry to bother you again. It looks like even when I pull the Dev branch it still does not learn my garage code. Security+ 1 & 2, may be implemented but I am still not able to use my garage door opener via the flipper.

#9

You cannot save rolling codes, only read them. This is a legal limitation and weā€™re not going to remove it.

1 Like
#10

Accepting that it is necessary, I am curious to learn more about why this restriction is implemented in this place specifically. Is there a particular law or regulation that prohibits storing dynamic codes? Or do dynamic sub-GHz codes enable / block particularly (legally or morally) hazardous use cases?

I realize this wonā€™t change in official builds: Iā€™m really just interested to benefit from the teamā€™s research into the legal (or moral?) landscape hereā€”so any background you can share would be most welcome!

#11

In short, rolling codes are still considered secure and are used in a lot of places. Enabling the ability to send them will open the door to a ton of possible misuse cases and possibly legal troubles for us afterwards. This does not apply to static codes, as right now theyā€™re almost universally considered insecure.

So no, thereā€™s no particular law about that, but if someone hacks someone elseā€™s garage and steals all their stuff it may cause a lot of trouble for us, so weā€™d rather stay on the safe side

3 Likes
#12

It is not my intention to press the issue. Since I am able to have a conversation with one of the developers, I feel like it would be a waste to not at least ask. I really appreciate your time by the way Astra and SkorP.

Does their need to be a complete ban on rolling codes? Instead of cloning a garage door opener, what about going through the learning process to pair the device as an original remote? The flipper zero is just a smarter universal remote and should not carry additional liability. I understand there is effort that goes into something like that, but if there was a patreon or something people would pay.

There are not enough RF experts like you guys around. I want to support this project however possible. I am sure I am going to get some response in the negative about rolling codes, which is fine. If anything you get from this comment, please open a patreon. I want to continue to support the project even if the only way I can is through monetary donations.

#13

You can actually generate a random sendable dynamic signal on your Flipper via the ā€œAdd Manuallyā€ function, and then pair that to your garage as you would any other fob. The problem is capturing someone elseā€™s key code and using it.

2 Likes
#14

I can logically follow that, but not sure how to technically implement. I will try a few things and see what I can break.

Thank you for your time.

1 Like
Creating "Add Manually" Entry
#15

I appreciate you asking, as I was unsure of this as well. Given the clarification (new random remotes are okay, cloning is not), Iā€™ve filed an issue on the Flipper Zero firmware repository to help track this:

EDIT: Apologies, I misunderstood the distinction here between random but still static and random and dynamic/rolling code. This issue isnā€™t valid.

1 Like
#16

Thanksā€”this is actually an extremely helpful clarification. If I understand you correctly, the issue is, at least in part, that rolling codes are often a best-available (albeit far from ideal) security technology. In view of this, the optics of stock firmware that readily captures and clones such codes are poor, especially when the feature would serve little educational or research purpose above and beyond the extant capture and decode capabilities.

Is this a fair way to characterize why the line was drawn here, even while emulating a variety of other RFID, NFC, 1-wire, and sub-GHz technologies?

(And again, just to underscore the point, I do not mean to implicitly push back on the teamā€™s doubtless well-informed judgment here. It is simply a question of improving my own understanding!)

2 Likes
#17

Yes, because for other technologies there are existing popular tools for their bypass/cloning/emulation (proxmark3, iKey, etc), but for the rolling codes this was mostly limited to a very niche group of codegrabbers, and we donā€™t want to expand that group.

1 Like
#18

haha ā€œwill open the doorā€¦ā€ well this is what I was here to find outā€¦ bummer.

#19
1 Like
#20

Thank you I can confirm the Sec+ 1.0 works with adding a new door opener using this firmware