Fix Nice Flor-s decoding Serial and Code

[zulea1]

Is using some kind of reverse-lookup tables (not the best way).
If there is any person with a Flipper Zero device in hand, maybe can help me to make this code in a short way (no more using this 128kb reverse table).

[zuckschwerdt]

Format here is generally only for nicer screen output and should not include a 0x prefix.

[zulea1]

ffb9211

[zuckschwerdt]

No need to add all those empty lines.

[zulea1]

ffb9211

[zuckschwerdt]

Thanks for the work! Yes, this will need a better to decode.
Can you elaborate what the decoding is based around or doing? Is this just derived from received data or is there an algorithm known?

[zulea1]

Thanks for the work! Yes, this will need a better to decode. Can you elaborate what the decoding is based around or doing? Is this just derived from received data or is there an algorithm known?

Decoder is based on info from this (I used Google translate):
https://vrtp.ru/index.php?showtopic=27867

Flipper Zero firmware used same method in first versions, but they stored encrypted this big tables (with STM32 AES256 production keys, same keys for all devices, no derivations. I suppose this are set when leaving factory).
E.g. Here on some older version:
https://github.com/flipperdevices/flipperzero-firmware/blob/0.39.0/lib/subghz/protocols/subghz_protocol_nice_flor_s.c

On new firmware, Flipper Zero use some kind of algorithm with 32 bytes (256 bits) key, again stored encrypted (with same keys), more details here:
https://github.com/flipperdevices/flipperzero-firmware/blob/dev/lib/subghz/protocols/nice_flor_s.c

[niklas-sparfeld]

Thanks for creating this PR, it helped me one step further in my path to controlling my covers ;)

For anybody trying do do the same thing, here's my work-in-progress encode function:

static int nice_flor_s_encode(uint32_t serial, uint16_t code, uint8_t button_id, uint8_t repeat)
{
    uint8_t snbuff[4];
    snbuff[0] = serial & 0xff;
    snbuff[1] = (serial & 0xff00) >> 8;
    snbuff[2] = (serial & 0xff0000) >> 16;
    snbuff[3] = (serial & 0xff000000) >> 24;
    fprintf(stdout, "snbuf:  %02x %02x %02x %02x\n", snbuff[3], snbuff[2], snbuff[1], snbuff[0]);

    uint8_t encbuff[7] = {0};
    uint16_t deccode   = code;
    uint16_t enccode   = 0;
    for (size_t i = 0; i < 65536; ++i) {
        if (nice_flor_s_table_decode[i] == deccode) {
            enccode = i;
            break;
        }
    }
    uint8_t ki = nice_flor_s_table_ki[deccode & 0xff] ^ (enccode & 0xff);

    encbuff[0] = button_id & 0x0f;
    encbuff[1] = ((repeat ^ button_id ^ 0x0f) << 4) | ((snbuff[3] ^ ki) & 0x0f);
    encbuff[2] = enccode >> 8;
    encbuff[3] = enccode & 0xff;
    encbuff[4] = snbuff[2] ^ ki;
    encbuff[5] = snbuff[1] ^ ki;
    encbuff[6] = snbuff[0] ^ ki;

    fprintf(stdout, "enccode: %x\n", enccode);
    fprintf(stdout, "deccode: %x\n", deccode);
    fprintf(stdout, "ki: %x\n", ki);
    fprintf(stdout, "encbuff: %02x %02x %02x %02x %02x %02x %02x\n", encbuff[6], encbuff[5], encbuff[4], encbuff[3], encbuff[2], encbuff[1], encbuff[0]);

    bitbuffer_t bits = {0};
    bitbuffer_add_row(&bits);
    bits.bits_per_row[0] = 52;

    uint8_t *b = bits.bb[0];
    for (uint8_t i = 0; i < 6; i++) {
        b[i] = ((encbuff[i] & 0x0f) << 4) | ((encbuff[i + 1] & 0xf0) >> 4);
    }
    b[6] = (encbuff[6] << 0x4) & 0xf0;
    fprintf(stdout, "b      : %02x %02x %02x %02x %02x %02x %02x\n", b[6], b[5], b[4], b[3], b[2], b[1], b[0]);
    bitbuffer_invert(&bits);
    bitbuffer_print(&bits);
}

[niklas-sparfeld]

Based on this, I implemented a Home Assistent Integration for my personal use: https://github.com/Kampfgnom/homeassistant-niceflors

[zulea1]

Based on this, I implemented a Home Assistent Integration for my personal use: https://github.com/Kampfgnom/homeassistant-niceflors

NICE. What sender (Tx-er) you use in Home Assistant? From my knowledge RTL-SDR is only receiver ...

Will be NICE to make a kind of "learning" procedure for serial number (based on decoder). Or at least a kind of "reading" procedure for remote(s) SN.

[niklas-sparfeld]

I explicitly do not want that. 😉 by reusing the serialnumber of your existing remote, your existing remote gets out of sync with the receiver - it is a rolling code encryption after all.

You better choose a new serial number (randomly) for your HomeAssistant and use the existing remote to pair the new serial with your receiver. https://manuals.easygates.co.uk/nice-flor-s-programming-guide/

That way your original remote does not suddenly stop working. And HomeAssistant acts as a separate shiny new remote. 😊

maybe I‘ll find the time for a small readme…

EDIT: as sender I use a FS1000A connected to GPIO: https://www.berrybase.de/433mhz-sender-empfaenger-superregeneration-modul-fs1000a-xy-fst-xy-mk-5v

I use pigpio to actually send the waves, because the timings need to be precise - more precise than python was able to achieve. https://community.home-assistant.io/t/pigpio-addon/314734

—-

Getting a bit off topic here, sorry 😅

[zulea1]

I explicitly do not want that. 😉 by reusing the serialnumber of your existing remote, your existing remote gets out of sync with the receiver - it is a rolling code encryption after all.

Sure is a rolling code. BUT if send last 5 and first 5 rolling counter values (variable named "enccode" in your implementations), the receiver will always work. I just tested on my Nice receivers sending with counters FFFB, FFFC, FFFD, FFFE, FFFF, 0000, 0001, 0002, 0003 and 0004. Receiver ALWAYS will find a valid rolling code (at least my receivers who are >5 years old). Of course, if use SN from original remote , the original one will no more work. To correct this "bug" Nice have to stop processing any transmiter SN who reached the bigest value (FFFF) of counter rolling code. I will try to order a new SMXI receiver to find if this is corrected.

EDIT: as sender I use a FS1000A connected to GPIO

I use now RFM23BPW, have +30dBm (1W) output power, and planned to install in my cars (can open doors from bigger distance, when arrive doors will be already opened): https://www.hoperf.com/modules/enhanced_power/RFM23BP.html

Getting a bit off topic here, sorry 😅

Yes, me too.

[gdt]

Where are we on this? Do the PR authors think it's ready to merge? Do reviewers? Are there doctrine issues to be resolved?

[dapxdap]

Tell me, I can't understand, is there a way to decrypt the serial number of the flor-s remote? I'm trying to integrate flor-s remotes into a parking access control system.

[Jev1337]

Read 433 raw values from remote and put them into Kaiju Analyzer.

[dapxdap]

The access system does not have internet access, is there a way to recognize remotes offline??

[Jev1337]

Why are you trying to clone your existing remote by decrypting it? Just make a new remote with a new serial and pair it with the receiver.

[dapxdap]

I make my own receiver with accsess control program. We have a community of garage owners, about 800 buildings on one territory. Some of them do not pay fees and in order to deal with payment delays, we need to block the passage for the defaulters. My system can open the gate on a phone call and on remotes with a static code, but they already have remotes with a rolling code that I would also like to integrate. Most of all there are nice flor-s remotes.