433.92 MHz roller blind remote (and the RTL SDR)

[voltagex]

I have been on a quest to decode the protocol used by Rollease Acmeda / Dooya roller blinds.

I have been using the Universal Radio Hacker software as it works in Windows, but I'll have to drag my Linux laptop out and try FISSURE.

I think these tools could be very useful. Would you consider adding some information around 433MHz FSK?

[cpoore1]

Sounds fun. This type of thing is exactly what FISSURE is designed to help with. I'm not going to lie though, it isn't developed enough to give you everything you need with any real level of automation. The goal is take the lessons learned from enough RE examples like this and to build out all the different capabilities. For example, the point of the Protocol Discovery component is to (one day) do a recursive demodulation approach where you can do things like:

• Take input from some other FISSURE component that already classified the signal of interest as an FSK signal with an associated set of features
• Run a generic flow graph/script that detects frequency deviation (if not already specified)
• Feed that value into another flow graph/script that measures the data/symbol rate
• Feed that value into something that produces a bitstream
• Analyze the bitstream to see if there is manchester encoding, differential encoding, detect patterns, etc.
• Compare messages and fields, calculate CRCs, make sense of the protocol, add it to the FISSURE library

There are still some things you can do manually with FISSURE that line up with a generic RE process people go through for an unknown protocol. FISSURE can:

• Launch something like rtl_433 to see if the capability already exists or launch URH to see if it can give you most of what you need (I think they both are capable of retrieving a bitstream for a simple FSK signal)
• Show you a link to look up the FCC ID and compare test results to what you are seeing
• Record/view the signal
• Make sense of the timing and frequency deviation with inspection flow graphs (I like the 1_10_100 one) or the IQ data viewer
• Do replay to see early evidence of protocol constraints like sequence numbers, encodings, or encryption that prevent the same message from being received over and over
• Work with streams of 1's and 0's in the Bit Viewer to see if there is manchester encoding or differential encoding and to compare messages to each other
• View examples of other GNU Radio OOT modules that do FSK demodulation to build your own blocks to demodulate/modulate signals and messages
• Store your attacks, demodulation flow graphs, protocol information, product images, and online reference material for others to use.
• Run your attacks with different field values or fuzz fields to see their impact on the target

I've used FISSURE recently for reversing Z-Wave and TPMS but I'd point you in the direction of other people and projects for the right way to build GNU Radio solutions. Eventually, we'll have guides for walking through all these different topics and could include things like working with generic or specific 433 MHz technologies.

[ResistanceIsUseless]

It would be nice to see support for specific MCU's. It might be possible to add support for exporting to FISSURE from current frameworks like FlipperZero, RFQuack, EvilCrowRF, etc. Creating a custom MCU firmware for FISSURE is probably the best way to go long term. Is there documentation on integrating with FISSURE? If there is documentation on the dateformat or API, I'm sure folks would contribute.

I've seen the following combinations being very popular in RF testing tools:
ESP32 + CC1101 (subghz + bt + wifi)
STM32 + CC1101 (subghz)
ESP32 + RFM69 (subghz + bt + wifi)
STM32 + NRF24 (subghz)
CC13x2 (subghz + bt + lora)
NRF52 (bt)

[cpoore1]

I am working on updating and releasing documentation. A lot of it already exists in the form of very outdated User Guides, ICDs, APIs, CONOPS, Help Menu items, etc. In the weeks to come I'll try to both consolidate and modernize it. It will likely be posted to a website with supplemental information and videos that can be accessed from the Github page. I'm going to start off with the grand vision for the framework (to be done before GRCon) and then progress into more of the specifics. But the more activity I receive on Github in the form of suggestions/feedback/demands/discussions/issues, the greater the push it will be to get it done.

As far as the MCUs go, how they get integrated into FISSURE depends on what you're trying to do with them. I'm very much in favor of reusing existing solutions wherever possible, especially if those solutions are familiar to people. I know for certain there are experts out there that have solutions for nearly every aspect of an RF framework but I'm looking to consolidate it all and make it publicly available. FISSURE is flexible enough where it isn't too much work to send any type of command to a device or receive/process any kind of data back. If you can think of way to do it in your head, it can probably get done.

[ResistanceIsUseless]

I'm still new to all this and have been contributing where I can to get familiar with embedded development and RF. I'll start playing around with FISSURE and see what I can do once I understand it better.