Go Down

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

renard-ad

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

#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.

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.

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?





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

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 !

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:

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.

Go Up
 


Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

Arduino
via Egeo 16
Torino, 10131
Italy