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.
I understand what you are saying but not sure how to find or edit the relevant bits in the .sub file. When I replay the open signal I make sure that the door is in the clsoed state.
Record to cu8, open and close the door 10 times while recording, and just cut off the first good set of 64 bits of every block of bits that starts and take some different captured blocks from diffrent states below each other in the analyzer, you should see that most would be static and only the signature for crc/heartbeat will be the most variable bits prolly not more then a handful, and you could start fuzzing just those bits , since bruting 64bits seems kinda unrealistic.
Well, I have the .cu8 file (garage_door.cu8 - Google Drive) for several open/close of the door. I can view in URH but not sure how to find the relevant bits.
Detected OOK package
@82.313217s DSC Contact bad CRC: FFFFFF, Status: FF, CRC: FF
Analyzing pulses…
Total count: 53, width: 4155 (16.6 ms)
Pulse width distribution:
[ 0] count: 42, width: 37 [36;44] ( 148 us)
[ 1] count: 11, width: 70 [69;72] ( 280 us)
Gap width distribution:
[ 0] count: 42, width: 28 [23;30] ( 112 us)
[ 1] count: 10, width: 61 [60;63] ( 244 us)
Pulse period distribution:
[ 0] count: 37, width: 66 [64;68] ( 264 us)
[ 1] count: 6, width: 131 [130;132] ( 524 us)
[ 2] count: 9, width: 98 [98;100] ( 392 us)
Level estimates [high, low]: 16003, 202
Frequency offsets [F1, F2]: 646, 0 (+2.5 kHz, +0.0 kHz)
Guessing modulation: Manchester coding
Attempting demodulation… short_limit: 37, long_limit: 0, reset_limit: 64, demod_arg: 0
pulse_demod_manchester_zerobit(): Analyzer Device
bitbuffer:: Number of rows: 1
[00] {64} 00 01 57 0c a8 7f 19 ff
Test mode file issued 158 packets
All seem to be very similar, so not sure why replay is not working.
preample is always like
1010101010101010101010101010
and sync part looks like 1100110011001101010010101011010010110011001100101010
so the preamble will be the same all to trigger it to read
and the changing parts in the sync of those you could fuzz
i only see the same repeated every time so it looks like the same thing over and over again.
throw this in the generator, make sure advanced is on ASK, save it as sub, then change frequency.
10101010101010101010101010101100110011001101010010101011010010110011001100101010
then replay that for trial.
If you check the interpretation tool on URH you see a couple of variations, but most is very similar, so only a couple changed in some packets.so you can see the difrence beween states but only a couple changed in the entire capture.
101010101010101010101010101011001100110011010100101010110100101100110011001010101100110101010101001011001100110101001011010101 [Pause: 695635 samples]
for example.
so there are some bricks of diffrent data, but most seem kinda static, you just need to strip sync from preamble on package, compare the difrences, and play around with those variable bits but it seems really really static this one.
OK, bear with me, you want me to take the bit sequence above and uses URH to generate a .sub file? I go to urh and Generate and Edit and enter the bit sequence you isolated. Looks like this so far: Imgur: The magic of the Internet
How do I now save this as a .sub
I’m not sure I followed that. I took just the first line and created this .sub file. tryagain.sub - Google Drive
Needless to say, that did not work but I probably missed a step there.
after removing duplicate lines
101010101010101010101010101011001100110011010100101010110100101100110011001010101100110101010101001011001100110101001011010101
101010101010101010101010101011001100110011010100101010110100101100110011001010101101010101010100101011010010110101010101010101
10101010101010101010101010101100110011001101010010101011010010110011001100101010110101010010100101011010010110101010101010101
is kinda what is is the only thing i see in this capture
so try that for fun, not sure if it cares about pause gaps, most devices are pretty stupid and just process bits.
thats why you can better work from interpretation to analyzer to generator, so you can include some of those bigger gaps without putting effort.
ps try protoview for flipper… analyze door and replay with that application , can also send captured data a lot easier if it has pwm and you run into options of supported devicetypes on rtl433/sub-ghz read function.
playing around more with SDR and replaying it might be worth to buy a 433tx module you can hookup to analog audio for tx out with jackplug and power with usb cable from a old broken mouse and you have your own tx options on pc , keep in mind you need variable modules for variable frequencies if you do not want to invest in more sdr stuff for tx support.
but then again you can putty into your flipper so you could tunnel anything to anything , but for boredom and tx testing, 4 dollar tx module on amazon and a jackplug , old cable and connecting the thing to power , you could salvage one from old cheap remotes if you wanted to.but buying new ones is also really cheap to broaden the tx spectrum so you can play more with other generator applications that makes your playground a lot bigger.
looking at the capture wav form, those big gaps/pause breaks do seem like some pulswith modulation going on so that might be something, if i’m done with my beer session i can look again but my mind is far from optimal state of functioning now so , ill be back 
.
Before trying protoview I will try the sequence you extracted. However (I hate to have to ask) but when in Generate view in urh, I enter the bit sequence in Edit mode but how to then get it on the right hand side so as to save as a .sub file?
As far as a transmit module goes, that sounds like a good idea. I was also looking at the booster for the Flipper which has its own CC1101 chip but I don’t know if that offers the same degree of functionality as the internal or if an external Tx chip on the PC woud be better way to test. There’s also the HackRF but I don’t think I’m ready for that just yet.
I looked briefly at Protocol Visualizer app (protoview) but did not see how to change the Freq to 345M.
left/right/up/down button, 345 and different modulation types should not be the problem, just keep in mind that saving PWM you can check on other device but you cannot re-open files saved so it is more a handy tool to see what is going on.
Still not sure what to with the bit sequence you isolated (unless I missed a message here somewhere).
Thanks. I tried both .sub files and neither ahd any effect, nor were they decodable by rtl_433 as the Honeywell Security sensor (honeywell.c in rtl_433 source)