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)
yeah so it is gonna be a 64bit block, and some seems to be described in the documentation, but since it has timestamps/crc you have some margins of abusing timestamps/crc in a while of replaying lets sayā¦ a couple of minutes tops before it starts to panic about timestampsā¦ if i really wanted to break the door sensor i would try generating compiled files of dumped files, fuzz the changing bitsā¦ yes it can be a bit annoying to look at every dump manually, but just jerking around with some captures seem to make a lot of old devices panic. So using URH to capture some packages, fuzz the bit blocks that seem most variable and replay those seems a way of starting to trial and error if it breaks down or triggers warning? The documentation states a few parts of the blocks already that will prolly be static most of the times, , so just putting them below each other, analyze different parts , mark the part that is most variable in analyzer and fuzz those 4-10 bits, the generated file after should be a couple of megabytes max, but except really really old bitshift registry is an easy target , but for most devices that are less then 20 years old do have some form of rolling code implementation.
@codeallnight created a custom modulation and as a result I can capture and replay the door sensor and rtl_433 sees the replay as the honeywell_security sensor. Indeed it looks exactly like the actual door sensor EXCEPT the replay has no effect. Something is obviously different but what?
Again, compare captures, make sure modulation type matches and sample-rate is enough to be sure you got all data, and look at the differences. If it is timestamped or has a checksum replaying old stuff will just be discarded as noise.
I am not entirely sure which captures you are suggesting that I compare. As it stands now I have one capture done by the flipper, which, when replayed has no effect, however; RTO 433 decoded as the Honeywell sensor, and looks exactly the same as when it captures directly from the door sensor.
Well, depending on capture settings modulation types and filtering it is not that easy, if you have a raw capture with a good sample-rate you can extract a lot of data pretty easy, but lets say, with modulation/filtering and sample-rates in the back of your mind it is not always simple, there are some decent semi intelligent multi-frequency setups working together that even a single raw capture could be trash or everything, i have to be honest i did not took a lot of effort to actually look at the capture so I am just stating the obvious taking guesses, but if there is any time-stamping, checksum s , modulation types that vary to make it more obscure. It does not mean it is gonna be so hard to replicate, but you need more information on the stuff you are working with before you can say why just replaying old stuff does not work. apparently there is some frequency or pulse-width modulation going on that is more important that the rest of the OOK/ASK data in there. If you know what your are trying to break you will also know what angles you have to look at it and try to break it.
I have almost no experience using gnuradio. If I sent you 2 files, one captured from the door sensor using the rtl_433(or the Flipper) and one replayed by the Flipper and captured similarly, could you have a look at them and perhaps tell me what I am missing? Both are being decided by rtl_433 properly but the replay has no effect on the security system receiver.