Need help/ guidance on decoding RF signal

EagerT0L3arn: I did it all again, calculated myself and everything. I can say I fully understand the process now. That's good. Better you understand something instead of having blind faith in someone else's ramblings. :)

I would just, in no bad intention, tell you that checking if button is pressed should be done so:

if(digitalRead(buttonPin) == HIGH)

Depends on how the button is wired. I tend to wire buttons to GND and use INTERNAL_PULLUP for the pin definition. This way the pin reads HIGH when the button is not pressed. When the button is pressed it connects the pin to GND and reading the pin it will be LOW. The reason for doing this is you don't need a resistors with the button as you would if you wired the button to VCC.

I would however, want you to take a look at the audio recording, to tell me whether I am confused or I am right and the patterns are not all the same. I would really appreaciate if you did that! I have looked and the codes are different every time the button is released and pressed but remain the same while a button is pressed for a long enough to repeat the TX.

EDIT: I checked again. Are we talking about rolling codes? Looks like it. Can you send details (model number etc) and links to the remote controller your using, maybe we can find a compatible replacement or details on the rolling protocol used.

thank you again Riva for taking time and checking my confusion. I did some digging and the best thing I found was this link: Info on remote

"algorithm of floating code for signal KeeLoq;"

Judging by above we can assume it's using KeeLoq algorithm to roll codes?

so I did some more digging: INfo on keeloq On the link above we can find KeeLoq info:

The Microchip HCS301 was once the most widely used system on garage and gate remote control and receivers. The chip uses the KeeLoq algorithm. The HCS301 KeeLoq system transmits 66 data bits. 34 bits are not encrypted : a 28-bit serial number, 4 bits of button information, and 2 status bits (repeat and low battery indicators). 32 bits are encrypted (the rolling code) : 4 bits of button information, 2 bits of OVR (used to extend counter value), 10 bits of DISC (discrimination value; often the low 10 bits of the serial number), and a 16-bit counter.[1] In a resyncing situation, the encrypted 32 bits are replaced with a 32-bit seed value.

I read that rolling code can only be "broken" if you jam the receiver in order to save the signal it would be sent, so you can use it at later time. Let me know if there are other ways. Best

Yes it looks like it may be Keeloq as it's 66 bits.

What was your ultimate aim in doing this project, was it to just have another remote control for the garage door or something that can be controlled from home automation?

A look online at eBay implies you can buy cheap remotes that can clone an existing Keeloq remote but I have my doubts such a simple and cheap device can clone rolling codes. If they do work then you could clone your remote and then use an Arduino to press the buttons on the clone (assuming this is for home automation).

So we found out there is 90% taht it's keeloq algorithm. How do we proceed in building our project with this knowledge?

So the goal was to clone the DoorHan remote by using arduino. I have no intention to buy cheap keeloq rolling code clones or anything like that, but I want to build it myself and understand how to do that.

EagerT0L3arn: So we found out there is 90% taht it's keeloq algorithm. How do we proceed in building our project with this knowledge?

You will need to determine the format of the Keeloq payload (probably documented nicely somewhere).

Determine the key/serial number and discrimination value used to encrypt the Keeloq part of the payload (having the remote in your hand you might be able to brute force it with enough samples or try the side channel method)

Write Arduino code to generate/emulate the Keeloq encryption so you can transmit it.

All in all a very steep hill to climb.

Riva: You will need to determine the format of the Keeloq payload (probably documented nicely somewhere).

Determine the key/serial number and discrimination value used to encrypt the Keeloq part of the payload (having the remote in your hand you might be able to brute force it with enough samples or try the side channel method)

Write Arduino code to generate/emulate the Keeloq encryption so you can transmit it.

All in all a very steep hill to climb.

What do you mean format of the Keeloq payload?

I think I should read on how to decrypt keeloq yes? Hmm Will get back to you once I find out something, think it will require a lot of thinking and calculating :/

P.S. I saw Nohawk's methods on attacking rolling code, but that is only one time thing right? just to block code from being accepted to use it a later time, but only once?

EagerT0L3arn:
What do you mean format of the Keeloq payload?
This…

I think I should read on how to decrypt keeloq yes? Hmm Will get back to you once I find out something, think it will require a lot of thinking and calculating :confused:
Yes it will. The hard part would be figuring out the 64bit key used to encode the encrypted payload with.

P.S. I saw Nohawk’s methods on attacking rolling code, but that is only one time thing right? just to block code from being accepted to use it a later time, but only once?
Yes, and this raises an interesting point/problem. Because of the sync counter you cannot make an exact clone of a remote and expect both to work properly as the last remote to transmit will have a higher sync counter so when you try to transmit on the other remote it will not work as its sync code has already been used.
If you can program multiple remotes to the receiver then you can maybe make your own remote (a HCS301 costs about $1.50) with a unique serial that get over the sync counter problem mentioned above or just buy another remote.

It looks like a version of Manchester Encoding Decoding to me. Though the long sync pulse lo looks unusual, but should not be too hard to code around. Easy to design a transmitter.

Have a look at these pages for a no-nonsense reliable explanation of this protocol I used to hack my weather station sensors. There are some really weird explanations of this protocol out on the web, most actually work, but they do it the hardest way possible.

It is really simple, and if solution does not look simple, then they don't really understand it.

https://github.com/robwlakes/ArduinoWeatherOS (it hacks 433MHz Manchester encoded data from Oregon Scientific weather sensors + good explanations, graphics etc)

and if you want to design a Tx and Rx system yourself then look at

https://github.com/robwlakes/433MHz_Tx_Rx (Tx is very easy).

and if you want the shortest, cleanest algorithm I have devised to collect Manchester data look at the Rx and Tx code in my thingiverse 433 RF Weather station

https://www.thingiverse.com/thing:3546977 This is my best Rx version of Manchester protocol. Quite easy to understand and modify.

I hope this at least helps a little in your quest.

Cheers, and best wishes, Rob