|
|
2 лет назад | |
|---|---|---|
| .flipcorg | 2 лет назад | |
| assets | 2 лет назад | |
| docs | 2 лет назад | |
| sub | 2 лет назад | |
| CHANGELOG.md | 2 лет назад | |
| README.md | 2 лет назад | |
| application.fam | 2 лет назад | |
| rolling_flaws.c | 2 лет назад | |
| rolling_flaws.png | 2 лет назад | |
| rolling_flaws_about.h | 2 лет назад | |
| rolling_flaws_keeloq.c | 2 лет назад | |
| rolling_flaws_keeloq.h | 2 лет назад | |
| rolling_flaws_send_keeloq.c | 2 лет назад | |
| rolling_flaws_send_keeloq.h | 2 лет назад | |
| rolling_flaws_settings.c | 2 лет назад | |
| rolling_flaws_settings.h | 2 лет назад | |
| rolling_flaws_structs.h | 2 лет назад | |
| rolling_flaws_subghz_receive.c | 2 лет назад | |
| rolling_flaws_subghz_receive.h | 2 лет назад | |
| rolling_flaws_utils.c | 2 лет назад | |
| rolling_flaws_utils.h | 2 лет назад |
Rolling Flaws (version 1.4) by @CodeAllNight.
YouTube demo of using Rolling Flaws application. The video shows how to use the application to simulate a receiver that has a Replay attack flaw, Pairing FZ to a receiver, Cloning sequence attack, Future attack, Rollback attack & KGB attack. The Rolling Flaws application also supports things like "ENC00" attack & window-next attacks, which are described in scenarios below but was not in video. Rolljam is discussed in document, but discouraged to test since it is illegal to jam signals in the US. If you have additional ideas, please let me know!
Note: This application works with Official firmware & most of the other firmware versions as well. Xtreme firmware needs to be on DEV channel to build.
This application is intended to help you learn about rolling code flaws.
Educational use only. This application is intended to be used for educational purposes only. It is intended to help you learn about rolling code flaws. IIf you use this information to attack devices, you are responsible for any damage you cause.

The Keeloq protocol has a FIX (button + serial number) and a HOP (encrypted data that can be decrypted into a count + some validation information, such as the end of the serial number). The receiver has a current count for the serial number, like 0x1E00 in the diagram above. There are a set of "Next" codes that will Open the device. When one of those codes is received, the beginning of the Next block will start with the received code. There are also a set of "Future" codes. When two adjacent codes are received, then typically the Next block will start with the second received code. The remaining set of codes are considered "Past" codes. Different manufacturers handle past codes differently. As a new count is accepted, the door opens and the location of the Next, Future and Past codes change. For more details, see this video along with the rolling code playlist.
Sending signals to a real receiver has the potential to desync the remote and can even cause the remote to no longer be valid. The reason this application was built was so that you DO NOT mess with equipment, unless you are pen testing it with permission. Even then, you can still mess things up & require service or replacement (for example, HCS300 overflow bits get cleared and you reach 0xFFFF count then bad things may happen). Please use this application instead of an actual device.
This application is intended to simulate various KeeLoq receivers that you may encounter. You can configure the receiver to simulate the device you want to practice on. Use a second Flipper Zero or HackRF or whatever to try to get the "Opened!" message.
In the future, I hope to offload this application to an ESP32+CC1101 so that you can use a single Flipper to practice rolling codes.
You can rename the file SD Card\subghz\assets\keeloq_mfcodes, so that a .sub file with KeeLoq protocol will be sent without incrementing counts. This will also cause all signals to be decoded as "KL Unknown". Be sure to rename it back when you are done.
Firmware other than Official does support encoding rolling code signals. This makes it easier to save and transmit rolling codes. This can be a good thing when you are pen testing, but a bad thing when you are just clicking around and don't understand the potential risks. In official firmware, you can still decode signals, write the keys down and then use the "Add Manually" option to create a signal, and then edit the keys to match what was decoded. It's more work, but then you won't accidently be sending signals that you don't understand. Unofficial firmware may also unlock the TX frequency list, which may be illegal in your region. Only broadcast on frequencies that are legal in your region. If you choose to install Unofficial firmware, it is not supported by the Flipper Zero team, so you will need to get support from the community. If you are using unofficial firmware, you should be aware of the risks.
This rest of this section assumes you are familiar with building your own firmware. If you are not familiar, this video will walk you through the process of being able to build and deplay the firmware. Note: Due to recent firmware changes, you need to do "[Debug] Flash (USB, with Resources)" [instead of without Resources] since some of the subghz code has moved into Resources.
If you want a Bin_RAW file, you can build a custom firmware without knowledge of keeloq. In .\lib\subghz\protocols\protocol_items.c replace the line &subghz_protocol_keeloq, with // &subghz_protocol_keeloq,. Then build the firmware. Now you can use the "Read" option with Bin_RAW set to "On" to get a Bin_RAW file. Be sure to edit the file back when you are done.
If you want to generate a custom SUB file for a specific key and count, you can replace the case SubmenuIndexDoorHan_433_92 code in the .\applications\main\subghz\scenes\subghz_scene_set_type.c file. You will need to build and deploy the firmware with resources. This will replace the implmentation of "Add Manually/DoorHan_433". For example, if you want to generate a SUB file for a DoorHan remote with key=0x084EE9D5, button=0x2, and count of 0xEC00, at 433.920MHz; you would use the following...
case SubmenuIndexDoorHan_433_92:
generated_protocol = subghz_txrx_gen_keeloq_protocol(
subghz->txrx, "AM650", 433920000, "DoorHan", 0x084EE9D5, 0x2, 0xEC00);
if(generated_protocol != SubGhzProtocolStatusOk) {
furi_string_set(
subghz->error_str, "Function requires\nan SD card with\nfresh databases.");
scene_manager_next_scene(subghz->scene_manager, SubGhzSceneShowError);
}
break;
If you want the Flipper Zero to be able to decode the same signal multiple times, in .\lib\subghz\protocols\protocol_items.c after the two occurances of instance->decoder.decode_count_bit = 0; add the line instance->generic.data = 0;. This will cause the Flipper Zero to forget the previous data, so it will decode the same signal multiple times. Be sure to edit the file back when you are done.
To scan for more interesting sequences, make this breaking change to keeloq.c file that will keep incrementing the key until it finds a DoorHan code (but it leaves the FIX value the same). This is one technique to search for ENC00 sequences. Be sure to edit the file back when you are done.
void subghz_protocol_decoder_keeloq_get_string(void* context, FuriString* output) {
furi_assert(context);
SubGhzProtocolDecoderKeeloq* instance = context;
// Uncomment the next line if you want to ALWAYS jump ahead.
// instance->generic.data += 0x100000000L;
while(true) {
subghz_protocol_keeloq_check_remote_controller(
&instance->generic, instance->keystore, &instance->manufacture_name);
if(strcmp(instance->manufacture_name, "Unknown") == 0) {
// UNKNOWN
} else if(strcmp(instance->manufacture_name, "DoorHan") != 0) {
FURI_LOG_E(
TAG,
"Wrong manufacturer name: %s high-bytes:%08lX cnt:%08lX",
instance->manufacture_name,
(uint32_t)(instance->generic.data >> 32),
instance->generic.cnt);
} else {
FURI_LOG_I(
TAG,
"Found manufacturer name: %s %08lX",
instance->manufacture_name,
(uint32_t)(instance->generic.data >> 32));
break;
}
instance->generic.data += 0x100000000L;
}
// Continue with the original code.
Two common hardware implementations of KeeLoq are the HCS300, which uses 10 bits in discriminator & the HCS200, which uses 8 bits. The Flipper Zero software implementation decodes using 8 bits. If you make a custom change to the .\lib\subghz\protocols\keeloq.c file you can return the encoded data, which will be used by the Rolling Flaws application. For "SN00/cfw" set to "No" to work properly, you will need these changes. For "SN bits/cfw" set to "10 (dec)", you will also need this changes. These changes allow the application to see the encrypted data, which is needed for the "SN00/cfw" and "SN bits/cfw" features to work properly.
Step 1. Change the two occurances of decrypt & 0x0000FFFF to read decrypt.
Step 2. Change the printf at the bottom of the file...
instance->generic.cnt & 0xFFFF instead of instance->generic.cnt."Enc:%04lX\r\n" to the end of the printf string.We added a final parameter instance->generic.cnt >> 16 to the end of the printf.
furi_string_cat_printf(
output,
"%s %dbit\r\n"
"Key:%08lX%08lX\r\n"
"Fix:0x%08lX Cnt:%04lX\r\n"
"Hop:0x%08lX Btn:%01X\r\n"
"MF:%s\r\n"
"Sn:0x%07lX \r\n"
"Enc:%04lX\r\n",
instance->generic.protocol_name,
instance->generic.data_count_bit,
code_found_hi,
code_found_lo,
code_found_reverse_hi,
instance->generic.cnt & 0xFFFF,
code_found_reverse_lo,
instance->generic.btn,
instance->manufacture_name,
instance->generic.serial,
instance->generic.cnt >> 16);
Method 1: (easiest)
Method 2: (command-line + allows for "SN00/cfw" and "SN bits/cfw" features + allows for replay feature)
git clone --recursive).rolling_flaws folder into your firmware's applications_user folder.fbt updater_package.Method 3: (VS Code + allows for "SN00/cfw" and "SN bits/cfw" features + allows for replay feature)
git clone --recursive).fbt vscode_dist at least once, so VSCode works properly.rolling_flaws folder into your firmware's applications_user folder.Method 4: (command-line)
rolling_flaws folder.ufbt launch.This is where you can configure the settings. The settings are reset whenever the application restarts.
This will reset the count to 0. This is useful when you want to start over or want to test some rollback scenarios.
This will transmit the signal. This is useful to capture the next signal.
This will receive signals. This is the primary purpose of the application.
This will sync the configuration using a remote signal. This is useful when you want to pair the Flipper Zero to your remote.
This will show information about the application.
Frequency is the frequency that the receiver and transmitter will use. This should typically be set to 433.92 unless prohibited in your region.
This is the button and serial number to decode.
If this is set to "yes" then it is possible to do a replay attack. NOTE: The flipper has built in code that prevents it from receiving a duplicate signal, so you will need custom firmware if you want to receive the same code twice.
This is how many counts forward from the existing count are considered acceptable. For example, if the current count is 0x0001 and the window is 16, then the next count can be 0x0011.
This is how many counts forward from the existing count are considered future. For example, if the current count is 0x0001 and the window is 32768, then 0x5011 would be considered a future count, but 0xEC00 would be considered a past count.
This is how close two future counts need to be from each other for them to be considered within the gap. When a second count is received and is within the gap, the next count will be advanced to the last count sent.
If this is set to "yes" then if the decoded data serial number bytes match 0x00, then any serial number will be considered a match. If this is set to "no" then the serial number must match exactly. For this feature to validate the serial number, you will need custom firmware.
By default the firmware only checks 8 bits of the serial number. If this is set to "10 (dec)" and you have custom firmware, then 10 bits from the decoded data will need to match the serial number.
This will cause the receiver to open when it receives a count of 0. This is a very bad idea, but I have multiple devices that implement this strategy. They also implement "KL (All)", which means an Unknown MF with matching FIX can open the gate. This is a very bad idea, but it is a real world example.
This tutorial assumes you have two Flipper Zeros. The first Flipper Zero will run this application and the second Flipper Zero will be used to send Sub-GHz signals.
Flipper #1:
Flipper #2:
SD Card\subghz folder).You need to make sure your Flipper Zero is using the same frequency as the remote. You can use the "Frequency Analyzer" option in the "Sub-GHz" application to determine the frequency of the remote. In some cases, you can also go to https://fccid.io and enter the FCC ID number and it will tell you the frequency being used. In some cases you may need to add custom frequencies to the firmware. For this tutorial "433.92MHz" is the frequency we will be using (but you can change it to "315MHz" or "390MHz", as long as you also edit the .SUB files to have the matching frequency).
You need to make sure your Flipper Zero is using the same modulation as the remote. In some cases, you can go to https://fccid.io and enter the FCC ID number and it will tell you the modulation being used. Otherwise, you can try each of the modulations until you find the one that works. For this tutorial "AM650" is the modulation we will be using.

The first attack we will try is called a "Replay attack". This is a very common attack to do with the Flipper Zero. For static codes (codes that don't change every time they are sent) this approach works really well. For dynamic codes, where the code changes each time it is sent, this attack will only work if the device has a replay attack flaw.
WARNING: With some receivers, when receiver detects a Replay attack (the count didn't increment) it can stop responding to the remote. It may be necessary to take the receiver to an authorized dealer to get it reset. This is rare, but it is something to be aware of, since it could be an expensive mistake.
Flipper #1: Enable Replay attack
Flipper #2: Freq Analyzer
Flipper #1: TX signal
Flipper #2: RX signal, determine frequency
Flipper #2: Read RAW record
Flipper #1: Reset count, TX signal once
Flipper #2: Stop recording
Flipper #1: Receive signal
Flipper #2: Send signal
Flipper #1: Opened!
Congratulations! You have successfully cloned and replayed a signal.

In the previous attack we successfully performed a "Replay attack". This is because our dynamic codes receiver had a replay attack flaw. Let's try the above steps again, but without the flaw.
WARNING: With some receivers, when receiver detects a Replay attack (the count didn't increment) it can stop responding to the remote. It may be necessary to take the receiver to an authorized dealer to get it reset. This is rare, but it is something to be aware of, since it could be an expensive mistake.
Flipper #1: Disable Replay attack
Flipper #2: Freq Analyzer
Flipper #1: TX signal
Flipper #2: RX signal, determine frequency
Flipper #2: Read RAW record
Flipper #1: Reset count, TX signal once
Flipper #2: Stop recording
Flipper #1: Receive signal
Flipper #2: Send signal
Sadly, this time the last step will be... Flipper #1: Closed
Sometimes you aren't trying to attack a device, you just want to use your Flipper Zero as a Universal Remote. For this you will need to know the protocol that the remote is using. You can use the "Sub-GHz -> Read" application to determine the protocol. In this example, we will use a "DoorHan" remote. Since you will pair the Flipper Zero as a new remote to your receiver, it should not impact the existing remotes and you don't have to worry about getting things out of sync.
NOTE: Some receivers have a limited number of remotes that can be paired, so you may want to check the manual to see if this is a concern for you.
Flipper #1: Set Frequency
Flipper #2: Read
Flipper #1: TX signal
Flipper #2: Determine protocol
Flipper #2: Add Manually
Flipper #2: Emulate signal (Same Flipper Zero as previous steps)
Flipper #1: Sync Remote
Flipper #2: Send signal
Flipper #1: Receive signals
Flipper #2: Send signal
Flipper #1: Opened!
Congratulations! You have successfully opened a gate by pairing the receiver to your Flipper and sending the next code in the sequence. You can continue to press OK on Flipper #2 and the gate will continue to open and the "Count" will continue to increase!

In this example, we will clone an existing remote. This is a "bad idea" as you are likely to get the receiver out of sync with the original remote. There is a high probability that the original remote will no longer work & using the original remote could cause the Flipper Zero remote to no longer work. This is why it is better to use the "Pair Remote" option instead of the "Clone Remote" option.
This scenario WILL most likely cause problems for you. You should only do this if you are pen-testing a device and you are willing to take the risk of getting the receiver out of sync.
WARNING: Your original remote will be considered as performing a "Replay attack" since it's codes will be in the past. With some receivers, when receiver detects a Replay attack (the count didn't increment on your original remote) it can stop responding to the remote. It may be necessary to take the receiver to an authorized dealer to get it reset. This is rare, but it is something to be aware of, since it could be an expensive mistake. More commonly, you will have to pair the originial remote one or more times (which may also require an authorized dealer).
The "Rolling Flaws" application has no consequences for getting the receiver out of sync, it was made to help you learn. Let me know if you think the application should punish you for getting the receiver out of sync -- for example, we could store a list of banned FIX values & no longer allow them to work until you enter a special code.
Flipper #1: Set Frequency
Flipper #2: Read
Flipper #1: TX signal
Flipper #2: Determine protocol
Flipper #2: Create a SUB file & emulate it
SD Card\subghz folder).Flipper #2: Add Manually
Flipper #2: Emulate signal (Same Flipper Zero as previous steps)
Flipper #1: Sync Remote
Flipper #2: Send signal
Flipper #1: Receive signals
Flipper #2: Send signal
Flipper #1: Opened!
Congratulations! You have successfully opened a gate by pairing the receiver to your Flipper and sending the next code in the sequence. You can continue to press OK on Flipper #2 and the gate will continue to open and the "Count" will continue to increase! This cloning worked because the protocol was known by the Flipper and it contained the manufacturer keys. If the protocol was unknown, the Flipper would not have been able to clone the remote.

In this example, we somehow have a file with a matching FIX to our remote. This file also happens to have a count that is only a little bit larger than the current count. This is a very unlikely scenario, but it is possible. This is why it is important to use a receiver that has a small "window-next" value.
Previous warnings still apply.
Flipper #1: Set Frequency
Flipper #2: Emulate signal
Flipper #1: Receive signals
Flipper #2: Send signal
Flipper #1: Opened!
Congratulations! You have successfully opened a gate by skipping ahead to another code that is in the expected range. We jumped ahead and now the count is "000C". You can continue to press OK on Flipper #2 and the gate will continue to open and the "Count" will continue to increase!

In this example, we somehow have a file with a matching FIX to our remote. This file also happens to have a count that is quite a ways in the future (but less than the receiver's window-future value). For this attack to work, we need to also have a signal containing a count right after it (or a small gap). When we send those signals in sequence and if the count is less than the receivers window-future, when the receiver detects the second signal it will resyncronize the current count to the second signal. In some cases it will open the door (and some will require a third signal to be sent, within the window-next range). Most only require two signals to be sent, because to reduce the number of times the user has to press the button.
If your receiver becomes out of sync with your remote (because you were pressing the remote too many times, so your count is too far in the future) then pressing the button 2-3 times may resync things; depending on the receiver firmware. If your reciever becomes out of sync with your remote (because a cloned remote sent a future signal) then you would want to press the button many times on the remote (out of range of the receiver, so as not to do a replay/past attack) until the remote was in the window-next or window-future range.
Previous warnings still apply.
Flipper #1: Set Frequency
Flipper #2: Emulate signal
Flipper #1: Receive signals
Flipper #2: Send future signal
Flipper #1: Opened!
Flipper #2: Send next future signal
Flipper #1: Opened!
Congratulations! You have successfully opened a gate by skipping ahead to future code sequence. You can continue to press OK on Flipper #2 and the gate will continue to open and the "Count" will continue to increase! At this point, your old remote is way in the past and is no longer useful.

This is very similar to a future attack, but instead of using codes from the future, we record and use codes from the past. Typically this attack will only work if the Window [future] is set to "all". What is most likely happening is the previous codes are considered as part of the far future, and when you play back two sequencial codes, it resyncs the remote to the second code. This is a very rare attack, but it is possible on some receivers.
Previous warnings still apply.
Flipper #1: Set Frequency, future all
Flipper #2: Read RAW record
Flipper #1: TX signal
Flipper #2: Stop & save recording
Flipper #2: Read RAW record (Same Flipper Zero as previous step)
Flipper #1: TX signal
Flipper #2: Stop & save recording
Flipper #1: TX signal
Flipper #2: Emulate signal
Flipper #1: Receive signals
Flipper #2: Send signal
Flipper #2: Emulate and send next signal
Flipper #1: Opened!
Congratulations! You have successfully opened a gate by replaying signals from back in time (that were considered future codes). This attack worked using RAW signals, where we don't need to ability to decode the data, we just needed to record two open commands to play back later!

The concept is when the first signal is sent from the remote, you somehow record the signal (narrow bandwidth) while preventing the receiver from getting the signal (perhaps interference near the receiver). The user of the remote then sends the second signal, which you again somehow record the signal (narrow bandwidth) while preventing the receiver from getting the signal. You then send the first signal without interference and the device will open, so user doesn't realize anything strange. You still have a second signal that you can use to open the device. Depending on other flaws, you may need to use the second signal before the next open signal (or before any signal, including "close/lock" signals). Samy Kamkar released videos on this attack years ago.
https://www.fcc.gov/general/jammer-enforcement (illegal to jam signals in the US) so you should not practice this technique in the US.

The concept here is that perhaps the receiver knows how to decode many manufacturers, instead of just one. If we send a FIX value that matches the expected value, but encode the count using a different manufacturer key, then perhaps it will open (you will typically combine this attack with a future attack, because you don't know what the count should be). For universal receivers, there is a chance they forget to actually store the manufacturer associated with the remote but instead loop through all of the keys they know about. For this demo, we use KGB/Subaru as the manufacturer, but you can use any manufacturer that the receiver knows about.
Previous warnings still apply.
Flipper #1: Set Frequency, KeeLoq all
Flipper #2: Freq Analyzer
Flipper #1: Sync Remote
Flipper #2: Send signal
Flipper #2: Prepare to Read signal (same Flipper as previous step)
Flipper #1: Send signal
Flipper #2: View signal details
Flipper #1: Receive signals
Flipper #2: Emulate and send KGB signal
Flipper #1: Opened!
Congratulations! You have successfully opened a gate by using a different manufacturer key to encrypt the count. This attack worked because the receiver didn't save the manufacturer of the remote, so it tried all of the keys it knew about.

The concept here is that when the receiver can't decode the manufacturer, it uses a count of 0. For universal receivers, there is a chance they open when the count is 0. For this demo, we use a "KeeLoq Unknown" as the manufacturer, but you can use any manufacturer that the receiver doesn't know about.
Previous warnings still apply.
Flipper #1: Set Frequency, KeeLoq (All)
Flipper #2: Emulate signal
Flipper #1: Transmit signal
Flipper #1: Receive signals (On the same Flipper Zero as the previous step.)
Flipper #2: Emulate and send Unknown signal
Flipper #1: Opened!

The software implementation of KeeLoq used by the Flipper Zero treats a decoded serial number of "00" as a special case that matches ANY serial number. This is interesting, because once we find a HOP code for a manufacturer that decodes to "00" for the SN and a Button value we want, we can replace the FIX code with any other SN. The FIX code (Button+SN) is sent in the clear for KeeLoq.
For example, DoorHan with Key of "C0 00 0B D4 AB 97 72 14" decrypts to a count 3DC9 with a "00" SN. The last digit of the key is 4 (0100) which written backwards is "0010" so button 2. Now if someone transmits a button 2 DoorHan signal, say "AD 04 58 14 AB 97 72 14" we can replace their "AD 04 58 14" with "C0 00 0B D4", getting "C0 00 0B D4 AB 97 72 14" which will decrypt to a count of 3DC9 but using their serial number! We can then use Key "C0 02 8A 33" prefix to get a count of 3DCA with a "00" SN, which is the next code in the sequence. Likely this would resync the receiver to our remote! (NOTE: if "3DC9" was in the past, we would need to use a different KEY to jump to a different count, like count of A247 or FD75.)
At this point the original remote would no longer work, since it was in the PAST. If we jumped even further into the future, at some point it might work when we press the remote button twice?
WARNING: Some receivers have a limit as to how many times you can cycle! The Overflow bits make it so that you can only cycle 0, 1 or 2 times. "This can be done by programming OVR0 and OVR1 to 1s at the time of production. The encoder will automatically clear OVR0 the first time that the synchronization value wraps from 0xFFFF to 0x0000 and clear OVR1 the second time the counter wraps. Once cleared, OVR0 and OVR1 cannot be set again, thereby creating a permanent record of the counter overflow. This prevents fast cycling of 64K counter. If the decoder system is programmed to track the overflow bits, then the effective number of unique synchronization values can be extended to 196,608." -- HCS300 datasheet
Previous warnings still apply.
Flipper #1: Set Frequency, SN00/cfw
Flipper #2: Read
Flipper #1: TX signal
Flipper #2: Determine key (FIX:BTN+SN)
Flipper #2: Load ENC00 file
Flipper #1: Receive signals
Flipper #2: Send signal
Flipper #1: Future
Flipper #2: Load next ENC00 file
Flipper #2: Send signal
Flipper #1: Opened!
Congratulations! You have successfully opened a gate by using a different serial number. This attack worked because the receiver didn't check the serial number ending of the remote when the decoded serial number was "00".

"The HCS512 decoder will automatically add a test transmitter each time an Erase All Function is done. A test transmitter is defined as a transmitter with a serial number of zero. After an Erase All, the test transmitter will always work without learning and will not check the synchronization counter of the transmitter. Learning of any new transmitters will erase the test transmitter." -- HCS512 datasheet
Flipper #1: Set Frequency, SN0000000
Flipper #2: Load sn0000000 file
Flipper #1: Receive signals
Flipper #2: Send signal
Flipper #1: Opened!
Rolling Flaws by @CodeAllNight.