Go Down

Topic: Need help/ guidance on decoding RF signal (Read 619 times) previous topic - next topic

EagerT0L3arn

Okay, I was uncertain if you was receiving the DoorHan signal because of the reply in #5I see from other post the signal is the same so no rolling code, this will make the job easier.
From the image you initially posted the on/off sequence before the long gap is just a signal to feed the receiver AGC (automatic gain control) so it reads the signal correctly. The gap is so the decoder knows the payload data is about to begin and then you have the payload with a long off period at the end of the payload.
If you attach a sample recording to a post or upload it somewhere we can get it then working out the timings and code to transmit it will be easier.
If you want to do the job yourself then the principle involved is to set Audacity to display hh:mm:ss + milliseconds and select the width of a few sample peaks and note the selected lengths.
From the image it looks like each bit is the same time length and just the high/low duration determine if the the bit is a 1/0.
Once you have the timings for the header, gap, zero & one you can create a simple program to replay a bit sequence that matches your remote.

I uploaded audio file to be opened in audacity, let me know if you can download it.
best

Riva

Assuming your sample rate is 37500Hz then measuring the lengths of highs/lows in the preamble shows each is about 15 samples.
Measuring silence after the preamble it's about 135 samples long.

The payload bits are either...
30 samples high - 15 samples low (HHL)
or
15 samples high - 30 samples low (HLL)
This indicates a period rate of about 15 samples so first is 2 periods on, 1 period off (HHL) and the other is 1 period on, 2 periods off (HLL). The preamble is 1 period on, 1 period off (HL) repeated 12 times.
The silence is about 9 periods off.
With a sample rate of 37500Hz a period is about 400 microseconds (1 / 37500 * 15 = 0.0004uS)

It does not matter what one is the one/zero bit if your just going to repeat the pattern.
Taking the 30-15 as a one bit and the other a zero then the payload looks like 66 bits...
111110011001110110111111111101100011110101110100111100110001101100

All we need now is to knock up some code to re-create this pattern. I can work on this later unless you prefer to do the code yourself?
Don't PM me for help as I will ignore it.

EagerT0L3arn

Assuming your sample rate is 37500Hz then measuring the lengths of highs/lows in the preamble shows each is about 15 samples.
Measuring silence after the preamble it's about 135 samples long.

The payload bits are either...
30 samples high - 15 samples low (HHL)
or
15 samples high - 30 samples low (HLL)
This indicates a period rate of about 15 samples so first is 2 periods on, 1 period off (HHL) and the other is 1 period on, 2 periods off (HLL). The preamble is 1 period on, 1 period off (HL) repeated 12 times.
The silence is about 9 periods off.
With a sample rate of 37500Hz a period is about 400 microseconds (1 / 37500 * 15 = 0.0004uS)

It does not matter what one is the one/zero bit if your just going to repeat the pattern.
Taking the 30-15 as a one bit and the other a zero then the payload looks like 66 bits...
111110011001110110111111111101100011110101110100111100110001101100

All we need now is to knock up some code to re-create this pattern. I can work on this later unless you prefer to do the code yourself?
Woah!
Thank you very much! You calculated everything. I will first try to understand how you got to these conclusions then I will tell you whether I encountered any questions!
I will try to code the code myself first, I will post it here, then you can correct it okay? Think it's only fair I try to write code myself, since you did all the work yourself :/

I greatly appreaciate it ! Thank you Riva!
Will update when I get done with what I said above.

best of regards!

Riva

Woah!
Thank you very much! You calculated everything. I will first try to understand how you got to these conclusions then I will tell you whether I encountered any questions!
I will try to code the code myself first, I will post it here, then you can correct it okay? Think it's only fair I try to write code myself, since you did all the work yourself :/
I just used Audacity wish scale set to h:m:s + samples and selected regions. It then shows the selected length in samples. To convert samples to time you need to divide 1 by the the sample rate (audacity says 37500 in lower left) to get the time of one sample and then multiply it by the number of samples in your selection to get the selection time.

I have already written code and checked the timings using a logic analyser. Obviously it wont work for you directly because I don't know what pins your button and transmitter are connected to.
I have also written the code in a very simple and wasteful way to hopefully make it easier to understand and adapt.
Don't PM me for help as I will ignore it.

EagerT0L3arn

#19
Sep 26, 2019, 10:26 pm Last Edit: Sep 26, 2019, 10:42 pm by EagerT0L3arn
I just used Audacity wish scale set to h:m:s + samples and selected regions. It then shows the selected length in samples. To convert samples to time you need to divide 1 by the the sample rate (audacity says 37500 in lower left) to get the time of one sample and then multiply it by the number of samples in your selection to get the selection time.

I have already written code and checked the timings using a logic analyser. Obviously it wont work for you directly because I don't know what pins your button and transmitter are connected to.
I have also written the code in a very simple and wasteful way to hopefully make it easier to understand and adapt.
Hey Riva!

I did it all again, calculated myself and everything. I can say I fully understand the process now.
I would just, in no bad intention, tell you that checking if button is pressed should be done so:
Code: [Select]
if(digitalRead(buttonPin) == HIGH)


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!

EDIT: I checked again. Are we talking about rolling codes?

Thank you very much!

Riva

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:
Code: [Select]
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.
Don't PM me for help as I will ignore it.

EagerT0L3arn

#21
Sep 28, 2019, 02:02 am Last Edit: Sep 28, 2019, 02:09 am by EagerT0L3arn

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


Quote
"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:

Quote
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

Riva

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).
Don't PM me for help as I will ignore it.

EagerT0L3arn

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.


Riva

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.
Don't PM me for help as I will ignore it.

EagerT0L3arn

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?

Riva

#26
Sep 29, 2019, 10:49 am Last Edit: Sep 29, 2019, 10:50 am by Riva
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 :/
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.

Don't PM me for help as I will ignore it.

Go Up