Go Down

Topic: rf433 code for ELRO Flamingo home devices (FA500) (Read 32235 times) previous topic - next topic

renard-ad

great, thank you !
any idea about the curious part ?

robwlakes

#31
Apr 17, 2015, 02:47 am Last Edit: Apr 17, 2015, 03:02 am by robwlakes
Is there the possibility the 'curious' section is a Rolling Code?

This has a good explanation of a car door or garage style controller that uses a Rolling Code Remote Entry.

What do you think?

Cheers, Rob

Edit: Sorry I did not mean that the codes rolled on every press.  That has been shown not to be so, but I was thinking the 'curious' section have some how been obfuscated by a cryptographic algorithm so it scrambles the bits beyond simple human (I am a great example) pattern recognition?
Learning Flute and C++, heading for a meltdown.

renard-ad

Thanks for the interesting links

The goal of rolling key process is no to be captured (I admit that I don't understand why because 256 times later, a captured code would work) but in our case, if you capture a key you just have to reproduce it and it works. We might also build a device that tries all the codes for a specific button (the curious part is only 16 bits, and there are 4 solutions to switch the plug, so it's only 65536/4 = 16384 codes to try).

This two files :
http://skory.z-net.hu/alkatresz/PT2262_1.pdf (many timing stuffs comparable to our plugs)
http://www.ti.com/lit/ds/slws011d/slws011d.pdf (about the rolling codes)
but none explain how to "decode" what has been received

About the link you provided (in which I found the second above link), I'm wondering why rolling key systems would be so robust to hacker replication. It seems you just have to record enough frames (let's hide a scanner for a long time or have access to the emitter) to be able to unlock the receiver.

robwlakes

The reason why is that that 16 bit or 16384 combinations are traveled though in defined pathways where the algorithm visits any particular number maybe a number of times, but depending on where it is in the algorithm sequence will certainly branch off to non sequential (pseudo random) numbers.  So while there may only be 16 bits and hence 16384 combinations, if there is a  distinct 'pathway' but a secret pathway, sequencing through the 16384 points then it makes it much harder to guess what sequence point is next if only one point is 'sniffed'.

I don't think now that these remotes do rolling codes (or their code would change on each key press and would not be static as you have shown), but to use my experience  with the Oregon Scientific Weather Station, the sensors send out a signal that is nibble (4bit) based, but each nibble has the significance of the bits reversed.  So the Tx sends a 4 bit number where the ABCD is normally decimal weighted 1,2,4,8 whereas when this is reversed for each nibble where we swap the significance to DCBA and we weight the numbers as 8,4,2,1 suddenly the bytes can be seen to represent the data on the LCD console.
So once the nibble boundaries are determined, and the reversal of significance is applied to each byte, the weather data is observable.  Numbers become recognisable in either BCD (eg humidity)  or pure binary +conversion maths (eg windspeed). Until this processing is applied the bit pattern is just a meaningless jumble. (I would like to give kudos to whoever worked this out for my weather station, but I just don't know exactly who figured it out!!!) Plus the Checksum works on nibbles not bytes.

The other possibility is that there is also a checksum or cyclic redundancy involved where the integrity of the bit pattern is tested for by the receiver.  I think one of the contributors above said that sending a single burst of a bit pattern was sufficient to trigger a response.  If that is the case then my previous comments about repeating 4 times to validate it are wrong, and the burst of 4 times would be just hoping that at least one got through (am I right here?).  But it also points to some other means of validating a successful transmission occurring so that erroneous transmissions can be eliminated.  Fairly important when switching things connected to the mains power!!!

It maybe the case that the 'curious' bit satisfies some validity checking algorithm and does not have much else to do with the switching data. So while you are cloning transmitters successfully, it maybe as much as you can do to manually determine codes for each separate one purchased.  So the learning mode maybe just something put in place to assign an earlier factory randomisation of transmitters, ie to create the uniqueness of the association of the Tx's to multiple Rx's, with no other generality involved.  That is each Tx is sent out with a "unique" random 16bit number, or what ever number of bits, that does not change in a transmission, but they take the chance that the very close neighbours don't have the same number???  So for 16bits by 16bits = 1 in 268,435,456 chance of sharing the same number??? Reasonable odds in a capitalistic world??

However if there is a checksum or CRC of say 4 bits then that reduces the number of combinations of 16 bits being checked to 12 (4096 combos? chance of neighbours sharing =16,777,216).  There is no free lunch, but still pretty good.

I hope this helps and stimulates some brilliant inspiration on someone else's part!!

Rob

 
Learning Flute and C++, heading for a meltdown.

Karl-Heinz

Thanx for sharing your thoughts.

I just played around to cross-check some theories.

1. Just 1 of the 4 codes is enough to teach-in the switch.
--> The switch automatically recognizes the remaining 3 ON of the same button codes without having seen 'em.
--> The switch automatically recognizes the 4 correct OFF codes.

2. The switch is able to listen to more than one button. I repeated the teach sequence for all buttons A-D.
Then the switch could be turned off and on by any of those.
--> More than one code is stored in the switch (if required).

3. The switch can be teached to listen to any other remote control
--> There is no factory side pairing.

4. Clearing the teached codes only succeeds using the remote control that was used when teaching the switch.



I think this is not a rolling code based on large lists of data with secret paths and such stuff. The device is simply too cheap for storing large data.
If you just need any of the 4 ON codes to know the other 3 ON codes AND the 4 OFF codes then this should be a kind of algorithm that is able to decode in any direction:

lets imagine you have 4 ON codes (only the curious 16 bit)

A ON 
0x1001
0x1002
0x1003 (<- you know only this code but you are able to calculate the rest)
0x1004 

and the corresponding 4 OFF codes

A OFF
0x2001
0x2002
0x2003
0x2004

If the switch sees 0x1003 during the teach in process, then the switch is able to
predict the other codes 0x1001, 0x1002, 0x1004 and even the OFF codes
0x2001, 0x2002, 0x2003, 0x2004. But this also works for any of the remaining 3 ON codes.

It could be a kind of symmetric chiffre algorithm that delivers the remaining codes based on just 1 input code. To keep the code simple this could also be a kind of filter operation with XOR and shift operators...


BUT:
why should someone send 4 different codes per button when one is enough for switching?





robwlakes

To respond to the last question first, I think the extra codes are designed to operate either alternative or legacy receivers as well.  For example the same chipset in the Tx could interact with a very different Rx in a garage door or gate control using the 'other codes', without having to reprogram a whole new remotes.  Just package up the chip with a new plastic coat and we may never realise that it is the same remote, unless it is analysed as you have done.  What else does that company (or the chipset manufacturer) make that is RF controlled, I wonder?

I agree with everything above.  Just to further explain (sorry about the longish post, a bad habit of mine being a now retired teacher) I agree the coding system for the switches appears simple enough and I am happy with your explanation of how 1 key can set the other 3. What I am suggesting is the 'curious' bits are a permanent (not rolling) unique factory number randomly chosen so it is very unlikely that a batch of remotes would ever have the same 'curious' bits and hence the same signature that is learned by the switches. (My weather station has an 8bit rolling code that is freshly chosen every time the power is lost, eg changing batteries, the sensor must then be re-registered with the base station, grrrr.  But it does mean there is a 1/256 chance of another sensor belong to someone else interfering.  This would not be unacceptable for controlling power switching in a house, but acceptable for low cost weather stations.)

However I think I am right in saying - someone above tested the switching by just sending the one pattern, and only sent it once, and it still worked?  If that is true then I would guess there is some error checking code in the 'curious' bits.  If not, then it is possible the same pattern has to be received say at least 3 times (out of the 4, or all 4) to be considered valid, in which case there would be little need for a checksum concept in the 'curious' bits.

Another thought is if the number (eg 1-4 switches) assigned to the signal the power switch (is apparently attached to the end of the bit packet) it would need to be incorporated into the preceding 'curious' bits if it was to act as an error checking system, otherwise it would not work.

Either way, if I was designing a receiver to listen to the remote I would just accept the whole pattern as a given, put any further diagnosis aside, program the Rx to learn the pattern, and then listen for at least 3 identical packets and use that as the validity check. Pretty crude, but I reckon it would be ok.

Cheers, Rob
Learning Flute and C++, heading for a meltdown.

renard-ad

Quote
why should someone send 4 different codes per button when one is enough for switching?
Good question ! As mentioned above, for other systems the codes are sent 6 times for enough redundancy. Here we just have four codes. Maybe the designer considered one code might not work for any RF reason and that would be a great idea not to persist in sending the same one. This is quite complicated for this poor reason, I admit.

Quote
To respond to the last question first, I think the extra codes are designed to operate either alternative or legacy receivers as well.
There are two things to consider :
- my remote sends 3 types of codes (not HK's which only send the first type) : 4 times the first type, 6 times the second, 6 times the third. We are here discussing about the first type of code. The others codes may indeed be designed to operate with other devices
- considering the first type of code, each button is associated to 4 different "curious parts". If the "extra codes" you're mentioning are the 3 apparently-usefulness-codes, then it would mean your remote works one time every four pushes.

Quote
What I am suggesting is the 'curious' bits are a permanent (not rolling) unique factory number randomly chosen
This bits are permanent in the remote (even if you remove the battery).
This code may have been generated randomly in factory but it has to be "curiously-associated" to 7 other codes (3 on, 4 off) through an algorithm we'd like to understand.
If the 8 codes of two buttons are indeed generated randomly (no correlation between them), then it implies every receiver knows all the remotes that could exist. A single remote would mean to be able to store 8(buttons)x4(codes)x16(bits)=512Bytes. I don't know how many different remotes the factory would like to implement, but I guess it will soon be a huge memory. However, today memory costs nothing...

Quote
However I think I am right in saying - someone above tested the switching by just sending the one pattern, and only sent it once, and it still worked?
I did not test it personally, but you're right. Sending on of the 4 codes associated to one button, whatever the codes sent before and whatever the code used for the pairing process, will turn the switch.

Quote
the same pattern has to be received say at least 3 times (out of the 4, or all 4) to be considered valid, in which case there would be little need for a checksum concept in the 'curious' bits.
I think it's this philosophy here !

Quote
Either way, if I was designing a receiver to listen to the remote I would just accept the whole pattern as a given, put any further diagnosis aside, program the Rx to learn the pattern, and then listen for at least 3 identical packets and use that as the validity check. Pretty crude, but I reckon it would be ok.
Yes, it's what I'm doing despite of understanding our famous algorithm. But it would be so interesting to understand and to program something cleverer :)

ATB

robwlakes

It seem like we agree 100%.  The 'curious' bits are indeed enticing morsels of technology, but if just random assignments, to give each remote an identity then trying to crack it maybe superfluous, however if that was the approach mankind to every unsolved technological problem we would still be sitting in dark, dank caves eating woolly mammoths roasted on an open fire.

I think there is a clever bit of programming to be revealed here, but we will probably be unable to crash through at this stage.  I think if you put it aside and let a few things settle out while you concentrate on the other parts of the project, something might gel and the answer will hit you on the head like the proverbial falling apple!!  I often would tell my students I would have to forget some question they had asked me, usually a problem in their programs, before working it out later on.  It was ten times harder in class, but once I had gone home and relaxed it was a whole lot easier. I used to say "We have done enough today I will talk to you tomorrow about it". (My most infuriating bit of problem solving was a processor board my student had beautifully soldered together that was really unreliable, in fact would barely work at all.  I checked very joint, component and track probably 10 times over 3 weeks, tried all sorts of things.  We had made 40-50 of the boards and they were well tested.  Turned out he had put a battery in reverse and instead of getting 6V to run it off it had 4.5V-1.5=3V!!  How simple, but stumbled on it at home, quietly, quietly... the language afterwards was not!)
Quote
These bits are permanent in the remote (even if you remove the battery).
This code may have been generated randomly in factory but it has to be "curiously-associated" to 7 other codes (3 on, 4 off) through an algorithm we'd like to understand.
If the 8 codes of two buttons are indeed generated randomly (no correlation between them), then it implies every receiver knows all the remotes that could exist. A single remote would mean to be able to store 8(buttons)x4(codes)x16(bits)=512Bytes. I don't know how many different remotes the factory would like to implement, but I guess it will soon be a huge memory. However, today memory costs nothing...
All the Remote factory would need to do would be make list of the numbers they had issued and make sure they did not use the same one twice.  If they used a pseudo random number generator, they would only need to know how far through the list they were for the next remote. This number I would suggest is hidden in the 'curious' bits and relate to a checksum, but as it is static and they oblige us with repeating it 4 times, I think a very good project can be made without worrying about any hidden codes (even if they do exist). (Someone coming from a totally different viewpoint may crack it for us?)

I really like your excellent project as switching mains voltages is always a difficult task and if these manufacturers have created cheap little boxes that conveniently do it all for us then that is a real bonus and combining it with thoroughly researched Arduino technology (as you have now done) is a great outcome.  I will now patiently await news of the apple!!!   ;D
Learning Flute and C++, heading for a meltdown.

renard-ad

We could also have fun in cracking all the codes that works. To do so, we could just generate all combinations and see if the plug switches.
Something "sad" is that the plugs first have to be paired. It's just a bit longer.
All of this could easily be done by :
- switching the receiver chip power. It is in pairing process.
- sending it a code (start with the first one...). It doesn't even need any remote, just connect an MCU to it.
- trying to switch it again with the same code and also try the 65535 others. Record when it works.
- do it again

Hum, will I do it... later maybe !

Karl-Heinz

I thought about nearly the same procedure, but it seems to take very long time.
Maybe I will try to pair the switches with 0x0000 or 0xffff for the curious part in the middle.
If it is possible to use this code for pairing then the resulting 3 other codes will hopfully
point into the right direction ...

renard-ad

True !
Looking forward to hear back from your experiment  :smiley:

robwlakes

Agreed, excellent!  ;)
Even the just first 16, $0000-$00010 could be interesting.  If the ELRO switch turned on a spare 5V phone adapter that the Arduino detects, could you could just leave it running and log any discovered "switching" results?
Learning Flute and C++, heading for a meltdown.

Stuntteam

I have also been working on this little challenge :)
Here are my findings:

I have measured the signal with an Ikalogic analyser.
I see 3 different waveforms coming fro mthe remote control.

Method 1: 28Bit code
Method 2: Automatic Code learning (AC) KAKU compatible code
Method 3: 24Bit manchester code resulting in a final 12 bit code

Method 2 and 3 are straight forward and easy to replicate.
Indeed the remote is able to control different kind of devices.
As mentioned, the FA500S (Switch) only responds to the first signal which is the one we are interested in.

For clarity:
FA500S Flamingo Switch
FA500DSS Flamingo Dimmer
FA500WD Flamingo Outdoor
FA500R Flamingo Remote Control

I agree with most of the findings posted earlier, like that there is probably some base number like address/button number that is twisted into the magic numbers.
I did a bit of number crunching with the info from the thread and a set I have here.
However, I always seem to get stuck. For sure when adding data from this thread into the calculation mix.

After some more digging I found the following PCB markings on the FA500R's: (can be seen through the battery door)
    50027.01B FLF-130105
KT50039.01A FLF-13-06-03 Chip marking: S007V0.1
KT50040.01A FLF-13-06-04 No marking on the chip
there might be more.

If one assumes that the first code is always the same code (for a single RC) and the order of the four codes is also always the same then there could be some base value that is -for example- shifted with the "curious" part. However, it is possible that the different PCB versions use slightly different "tricks" to form the curious part. So perhaps we need to first work with results from the same PCB versions to rule out version differences.

Karl-Heinz

My remote control 1:
KT50040.01A FLF-13-06-04
Lot No 08SA14

My remote control 2:
KT50040.01A FLF-13-06-04
Lot No 11SA13

Mine seem to be of the same type.

Stuntteam

One more, PCB: KT50040.01A FLF-13-06-04
A On:                 
001001 0010100011111101 0111 10 
001001 1110110010011110 1101 10
001001 0001010100001110 1000 10
001001 0101100001101101 0101 10

A Off:
001001 0001100000000010 0011 10
001001 1010111011100110 0001 10
001001 1011010100101111 1110 10
001001 0011010011000110 0110 10

B On:
001001 1111111111001010 0110 01
001001 0001001110100000 1110 01
001001 0100111100001101 0001 01
001001 0011001111010101 0100 01

B Off:
001001 0100010010100111 0111 01
001001 1010010010000001 0101 01
001001 1001100001011101 0011 01
001001 1010100110100001 1010 01

C On:
111001 1001110001011000 1110 01
111001 1111110111111111 0100 01
111001 0110100101100111 0110 01
111001 1000111000110111 1100 01

C Off:
111001 0100100111110111 0101 01
111001 0100101001010110 0011 01
111001 0101010000000001 0111 01
111001 1111101010011000 1101 01

D On:
011001 0111010100110110 1010 10
011001 0010000100010100 0110 10
011001 1110100011001101 0000 10
011001 1010011000001000 0001 10

D Off:
011001 0110000111000101 0010 10
011001 0000110110010110 1101 10
011001 0001000101100100 1110 10
011001 1101001100000110 1100 10

Go Up