I have door sensors which operate at 312Mhz but Read does not appear to be able to decode them. Read Raw sees transmissions but replay has no effect. How to further analyze this or is this likely to be an encrypted protocol that cannot be handled?
2 Likes
Give us as much information as you can about the sensors. I haven’t seen any encrypted door sensors. Playback would be an issue if they were encrypted or rolling code.
I believe this is a Honeywell Security sensor operating at 345Mhz. I have tried replaying a Read Raw capture but it doesn’t seem to be recognized by the system as a state change.
I ran rtl_433 and found that it was able to decode the signal and verify it is a Honeywell-Security sensor with a unique (unchanging) id and an event code which shows either open or close. How to get Flipper to recognize and replay this signal?
RTL-433 can detect and decode another sensor: Interlogix_Security at 319.5Khz which F0 also cannot replay and effect a state change.
For clarification does the Flipper play the signal without giving an error? Have you used your SDR to see if the Flipper plays any signal at all when you try to replay it? Have you looked to see if the signal looks different when played by the Flipper versus the sensor?
Yes, the Flipper plays the signal without error; however, unlike the signal from the sensor it is not decoded by the rtl-sdr when I do rtl_433 -f 319500000 - S unknown. Instead it saves the received signal in .cu8 files.
How could I take the .cu8 file captured by the RTL-SDR and convert it to a format the flipper understands and replay that?
I was able to record the sensor to a .ook file using RTL-SDR and then with this utility:flipper_toolbox/subghz_ook_to_sub.py at main · evilpete/flipper_toolbox · GitHub convert to .sub file which when played by the Flipper worked as expected. This is great but it begs the question of why the Flipper can’t record and playback this file using Read Raw.
That technique worked on 2 sensors but failed on a 3rd similar sensor for no apparent reason.
Someone suggested that I record in .cu8 format rather than.ook to see if it helps with the two sensors that are not working. How can I convert from .cu8 to .sub?
Depending on versions, cmd arguments might be a bit diffrent but using the -G option and -A for analyzing recieved data should help. I Record a lot of crap to cu8 files also URH (Universal Radio Hacker) and other applications are compatible with cu8 files, also URH has filpper sub filtetype support now , and you can even open cu8 like a wav and edit it with sound editors to extract information from cu8 dumps. So sometimes it is just easier to optically check a dump with Audacity and cut out the part you need, or edit it for example to play around. URH makes it more easy to analyze and edit on bits.
going into the sub-ghz realm, check the rtl-sdr website, defnitly a lot of fun stuff to look into.
It always makes me happy to see more people wanting to understand more about it, so yes, rtl433 is a good dumping option, but keep in mind you are just recording audio in a way, and can handle those cu8 files like wav files, so extracting bits of it can be simplified fast with simple tools or applications you prolly already know.
1 Like
I assume that since the RTL_433 command has no trouble decoding the signal, the information in the honeywell.c module (honeywell.c - Google Drive) has the necessary information. It says: .modulation = OOK_PULSE_MANCHESTER_ZEROBIT. I am new to F0 and I am not sure what I need to adjust for this to read and playback properly.
The document says it has crc/heartbeat and tamper detection , so replaying an old packet just gets discarded, so you need to make the heartbeat match and and make sure the signature matches, otherwise you are just gonna trigger tampering protection or you are basically sending out trash.
So cut single packet/states out of captures using URH , analyze them in URH , just fuzz a couple of none-static bits, and test for results to see how smart the device is.
If you can see a couple of packets from different captures of different states next to each other it is more easy to compare and see how static those packages are, and if it is just a couple of bits changing. Generating huge files of nothing is just gonna jam the frequency and bother other devices on the frequency.
1 Like
I was going to try your first suggestion and take .cu8 file and use urh to convert to .sub how to do that. I recorded a .cu8 with rtl-sdr and opened in urh, I added the flipperzero addin but when I go to Generator and ask it to save the file in .sub format it says there is no content (yet it shows the content in the analysis window). I also did a recording using urh into its native format and that too wold not convert to .sub. Where am I going wrong?
OK, I figured out that I have to drag and drop the file first (duh). Converted the native format to .sub and a .cu8 file captured by rtl-sdr to .sub and when Played by F0, no effect. On to your other suggestions.
I tried -A but not sure what if any additional information that gave me. rtl_433 has no problem decoding the signal reliably but my attempts at replay from f0 recordings or urh have failed. I don’t belive this device is very smart but I can’t be sure of that. How would it know an “old” packet?
Yeah URH works in projects and could have some visual tweaks but you can open it in a project, move it to analyze into generator and save sub from there, make sure to textedit sub after to check if frequency is not at 433 (urh thingy) so just change it with notepad for example and change the frequency to 345000000
From analyze you could mark specific data structures and fuzz only small things then from the generator save to sub.
Yes, I had to change it from 433.92 back to 345M. Still does not work. Not sure what to try now.
If you cannot just replay it , it means the crc/heartbeat are none static bits, so you , or need to capture live and edit those, or see if the heartbeat is a counter that increases over time so you have to take a value that is above current one, it just means its has some bits added in those 64bits to match the signature of the sensor. If you do not follow those counters and are > those values, they will just be discarded as old data. And even if it is static, if you replay a closed state while being closed already the device does not change, so you kinda need to compare different captures to see what changes in those 64 bits and what are static bits. If bit X changes over time you could roughly guess ahead and trigger the sensor.