How do I convert a Key file to a RAW file?
Filetype: Flipper SubGhz Key File
Version: 1
Frequency: 433920000
Preset: FuriHalSubGhzPresetOok270Async
Protocol: BinRAW
Bit: 133
TE: 356
Bit_RAW: 133
Data_RAW: 00 00 1D DD 11 11 DD 11 DD 11 11 D1 D1 D1 DD 1D 1D
From YouTube research, I have taken the approach to convert each hex to 8 bits in Python, set each 0 to be a ā380 -1180ā and each 1 to be a ā1180 -380ā and added a preamble, but this does not trigger the device whereas the key file does.
380 -12000 380 -1180 380 -1180 380 -1180 380 -1180 380 -1180 380 -1180 380 -1180 380 -1180 380 -1180 380 -1180 380 -1180 380 -1180 380 -1180 380 -1180 380 -1180 380 -1180 380 -1180 380 -1180 380 -1180 1180 -380 1180 -380 1180 -380 380 -1180 1180 -380 1180 -380 1180 -380 380 -1180 1180 -380 1180 -380 1180 -380 380 -1180 1180 -380 380 -1180 380 -1180 380 -1180 1180 -380 380 -1180 380 -1180 380 -1180 1180 -380 380 -1180 380 -1180 380 -1180 1180 -380 380 -1180 380 -1180 380 -1180 1180 -380 1180 -380 1180 -380 380 -1180 1180 -380 1180 -380 1180 -380 380 -1180 1180 -380 1180 -380 1180 -380 380 -1180 1180 -380 1180 -380 1180 -380 380 -1180 1180 -380 380 -1180 380 -1180 380 -1180 1180 -380 380 -1180 380 -1180 380 -1180 1180 -380 1180 -380 1180 -380 380 -1180 1180 -380 1180 -380 1180 -380 380 -1180 1180 -380 1180 -380 1180 -380 380 -1180 1180 -380 1180 -380 1180 -380 380 -1180 1180 -380 1180 -380 1180 -380 380 -1180 1180 -380 1180 -380 1180 -380 380 -1180 1180 -380 1180 -380 1180 -380 380 -1180 1180 -380 1180 -380 1180 -380 380 -1180 1180 -380 1180 -380 1180 -380 380 -1180 1180 -380 1180 -380 1180 -380 380 -1180 1180 -380 1180 -380 1180 -380 380 -1180 1180 -380 380 -1180 380 -1180 380 -1180 1180 -380 1180 -380 1180 -380 380 -1180 1180 -380 380 -1180 380 -1180 380 -1180 1180 -380 380 -1180 380 -1180 380 -1180 1180 -380 380 -1180 380 -1180 380 -1180 1180 -380
Here is the RAW data that works to trigger the device. I can not see how this RAW data that works is related to the Key file data that also works:
RAW_Data: 387 -5738 1053 -314 1051 -324 1039 -328 417 -1012 391 -1062 407 -1022 419 -1018 1075 -290 1063 -336 391 -1014 395 -1052 1061 -296 1077 -308 387 -1032 409 -1042 413 -1030 377 -1040 1067 -300 421 -1044 1035 -322 415 -1018 1053 -312 391 -1046 1073 -288 1073 -298 423 -1016 1075 -294 403 -1020 1081 -314 391 -168362 65 -1020 197 -262 65 -300 99 -370 101 -102 403 -368 133 -100 163 -130 197 -260 263 -68 263 -98 227 -98 163 -228 261 -66 589 -66 229 -66 197 -68 369 -198 327 -98 99 -326 1505
Did you try reversing the the sequence? Donāt ask me why but that seems to be a thing sometimes. āAbove my pay gradeā.
Thank you for your reply. Reversing the key sequence didnāt work. I have no idea how the raw data relates to the key file. They are both totally different but both seem to work. Either way, I stuck with the raw data and then reverse engineered the protocol from there. Hereās a link to the writeup https://github.com/adam-palmer1/subghz/blob/main/README.md
Hopefully someone can clarify how that key file relates.
Nice! I brute forced the ir signals for the Amazon Fire TV(version that is a TV). I think the ideal way to figure out a protocol would be to dig through Flippers code but Iām no expert in C and thatās a lot of work. I also used python to create files. I had an idea related to brute forcing. We can actually send command directly to Flipper over cli and I believe there is already a Python library. It might be more efficient.
You could try using applications like URH (Universal Radio Hacker) to convert them to cu8 or complex files, from there import them to audacity, if you do not like the URH interface and even edit them as WAV files. keep in mind samplerate of 250k/1000/1024k whatever matches the samplerate in audacity if you want to edit them like audio to prevent messing up the data converting back to sub for example.
You could use the rtl_443 application to check/analyze them more easy.
And from URH it is also easy to import them back and convert other files to sub.
Is is also easy to use URH to look at binary data and analyze packets, just user interface the tool could use some improvements.
But for converting to other files , editing raw and saving back to sub its nice to have. Also the fuzzing bits/blocks feature can be nice to check if something is broken by design. You can cut out parts of a capture and edit them in the gui.
both are on github and for the rtl433 i can advise you to also check the nightly builds that have some neat additions of protocols.
Thank you - this is very helpful in terms of visualisation and fuzzing of the content. My confusion is still how the key file in the original post that I captured relates to the RAW data that I also captured.
The entire communication is only 30 bits and Iāve successfully reverse engineered it - how does that 30 bit stream relate to the Key file data āData_RAW: 00 00 1D DD 11 11 DD 11 DD 11 11 D1 D1 D1 DD 1D 1Dā
All my best.
also handy to copy 
But you mean difference between binraw and readraw or? so actual wav recording vs just saving the captured data? Or? I should read back again before asking stupid questions 
Sorry I probably didnāt explain it very well. I have a Sub GHz ceiling fan with a remote. I captured it using "Read Bin RAWā functionality and it captured the following:
Filetype: Flipper SubGhz Key File
Version: 1
Frequency: 433920000
Preset: FuriHalSubGhzPresetOok270Async
Protocol: BinRAW
Bit: 133
TE: 356
Bit_RAW: 133
Data_RAW: 00 00 1D DD 11 11 DD 11 DD 11 11 D1 D1 D1 DD 1D 1D
I can replay this successfully and it works fine. I can also mess with Data_RAW to control different fans and issue different commands.
I then captured it in āRead RAWā format, and I got the following:
RAW_Data: 387 -5738 1053 -314 1051 -324 1039 -328 417 -1012 391 -1062 407 -1022 419 -1018 1075 -290 1063 -336 391 -1014 395 -1052 1061 -296 1077 -308 387 -1032 409 -1042 413 -1030 377 -1040 1067 -300 421 -1044 1035 -322 415 -1018 1053 -312 391 -1046 1073 -288 1073 -298 423 -1016 1075 -294 403 -1020 1081 -314 391 -168362 65 -1020 197 -262 65 -300 99 -370 101 -102 403 -368 133 -100 163 -130 197 -260 263 -68 263 -98 227 -98 163 -228 261 -66 589 -66 229 -66 197 -68 369 -198 327 -98 99 -326 1505
I figured out from the RAW_Data that you need a 380us pulse, followed by about 5000us silence, then you send 30 pulses, short ones (380us on/1080us off) for a 0 and long ones (1080us on/380us off) for a 1.
Here is the result:
111000010110000101100101101010
This RAW_Data successfully operates the fan too.
How does a 380us on pulse followed by 5000us of silence, and then the stream 11100001011000010110 0101101010 that functions correctly to turn the fan on and that I captured with Read RAW, relate to the key data that I captured with āReadā that is ā00 00 1D DD 11 11 DD 11 DD 11 11 D1 D1 D1 DD 1D 1Dā
I guess the initial ā00 00ā might be the 5000us of silence, but I see 15 hex pairs after the first two 00 00. Assuming each one is 0-FF and is a byte, we have 120 bits of data here, vs the 30 bits that I captured with Read RAW and is actually needed to operate the device - and no I canāt shorten the Key in any way, it doesnāt work, it needs all of it.
Edited to add, the hex from the keyhole doesnāt even appear in the raw stream anywhere (DD is 11011101 for example)
TL;DR - how does the key file ā00 00 1D DD 11 11 DD 11 DD 11 11 D1 D1 D1 DD 1D 1Dā relate to the raw data that I captured separately? They both work to operate the device.
And question 2, what process do I use to convert the key file ā00 00 1D DD 11 11 DD 11 DD 11 11 D1 D1 D1 DD 1D 1Dā to the raw data 11100001011000010110 that it corresponds to?
Filetype: Flipper SubGhz RAW File
Version: 1
Frequency: 433920000 ==> Frequency in Hz
Preset: FuriHalSubGhzPresetOok270Async ==> modulation and deviation settings. Here OOK with 270KHz RX filter bandwitdh
Protocol: RAW ==> un-decoded file containing duration of pulses in Āµs
RAW_Data: -1038 487 -1044 511 -1010 1011 [remaining pulses omitted, 512 pulses are present for each lineā¦]
RAW_Data: -1044 517 -1010 517 -521 [remaining pulses omitted, 512 pulses are present for each lineā¦]
In the above file, we can see:
So the data converted to a binary stream with a minimum bit length of 500Āµs (data rate= 2000 bits/s) is:
RAW_Data: 0010010011ā¦
RAW_Data: 0010010ā¦
but creating big files, combining multiple lines and playing around with timing you can trick a lot of devices who can process data a lot faster, so you can often turn 5 minutes into 1,5-2 minutes and it will still trigger with stupid devices. You can take out 10-30% of time on most devices and they do not even notice you are a bit more enthusiastic then an average remote. Also fuzzing a couple of specific bits makes it nice to create annoying files that are really fast.
The key is just hex/bin over time with amount of bits?
The - values/pause bits or 0ās and high values for 1 for example in AM OOK/ASK , its how you define the 0-1 or *2 in fm/fsk options for example ,compatible to the modulation type where am/ask/ook is more like a rough ābeat counterā versus checking differences in amplitude or comparing multiple of them in the signal.
Also why stupid AM ask/ook devices are not to picky about the signal or waveform and āclose enoughā usually works, where in other modulation types you have a bit more logic in being sure on what is being transmitted and getting rid of noise more easy.
so even if the key is a bit more then the single 30 bits, and the remote transmits the same thing in repetitions, you could capture, 1,5 or 3 times the data in binraw where you just got a bit more but since the modulation type and receiver just recognize something that looks sorta familiar, so good enough,so even if you got some extra data, if the needed key is in there even if it is only a part of the signal you transmit , especially for AM ASK/OOK applications, having a couple of bits less or more here and there are ignored more easy to prevent interference problems, so if the needed sequence is somewhere in-between, it is also fine.
But bin-raw is actual binary converted to hex, i think? but the read raw function where you get the entire waveform, you get the multiple options , where it is just modulated/demodulated but not decoded, so you can get a lot of extra data with it not 100% relevant to what you expect to capture. and if you have the modulation specifics you do not need the difference in time high or low pulses, cause you expect default modulation specs so you usually get a different result in data without filtering.
So sorting out raw captures, visualizing them and interpreting them as audio files makes it somewhat more easy to see differences. At least for AM ASK/OOK , then you can just count peakās where in other modulation types it becomes a bit more specific but for this is should give some clarity.
But in brute-forcing stupid devices, after the preamble some keep listing for seconds to get a valid command, and if you lets say for example, brute-force the entire 16bit keyspace after it in seconds, a lot cheap devices fall for stupid stuff like this , so you could reduce time to trigger all max annoyance in files to a fraction of the size and time for tons of devices.
Sorry if i am rambling trash, i should not reply as much when not being sober
That is some good lateral thinking!
Well, you just made it up, bin_raw is a file with undecorated data, and this is also a set of durations like read_raw, but with the difference that here, all durations are aligned in time. each bit bin_raw has a duration of te and letās say 0x00 is 8Te of a low signal, 0x0f is 4Te of a low and 4*Te of a high signal and so onā¦ and in bin_raw there is no noise or other unnecessary things, only a useful signal
Thanks , i did not see it in documentation and never bothered to look at the part of the git so i did make some false assumptions there. Also to much ethanol and i just ramble thoughts , so i should limit my replyās then 
That makes sense - thank you. One last question then.
With the RAW stream, we need a pulse and then 5000us+ of silence before the 30 bits of the command. If I omit the pulse at the beginning and 5000us of silence, it doesnāt work.
How come the key then starts with ā00 00 1D DDā¦ā (and works) - surely it should start with ā80 00ā (10000000 00000000) which would be 1xTE (356us) of on, and 15xTE (5340us) of off?
??? -5738 see raw
Te 356 => 16*Te => 0x00 00
Hey - yes I see the raw for the 00 00 but what about the first ā387ā in the RAW? Thatās why I donāt understand how the bin can start with a 00 00 when it needs a 387 on pulse at first. Why not ā80 00ā so you get that first on pulse?
because in raw there is noise, inaccuracy in the baudrate of the receiver, the curvature of the transmitter, and so on. going through my algorithm in bin_raw, the durations for bit encoding are aligned, the smallest multiple - Te is selected and calculated. The repeatability of packets is analyzed and the repeating sequence is output. this is bin_raw. if you loop this sequence, it will completely repeat the upload. and there is no need for any high levels at the beginning.
Thank you. A few last questions pls -
If I wanted to convert this format to RAW, I would convert the key to binary. Where each 0 was a low for Te usec and each 1 was a high for Te usec?
If the initial high isnāt needed as the sequence repeats, and the high at the end of the sequence followed by the ~5000usec of low at the beginning will trigger the device, is it right to assume that in the flipper, pressing the āSendā on this key file sends it more then once? If so how many times? I am assuming it must be at least twice as the device needs a 380us high followed by 5000 us low to trigger it.