Flipper Zero

The Flipper Zero is an open-source portable RF multi-tool that sells for roughly $169 to $199. It introduces no new attack techniques. Every primitive it exposes, from sub-GHz replay and 125 kHz badge cloning to CRYPTO1 key recovery, BLE advertisement flooding, infrared replay, and USB keystroke injection, was documented and tooled years before the device shipped.

What changed is packaging. A polished interface, a curated protocol library, community firmware, and a form factor that looks like a toy collapsed a workflow that used to require a laptop, an SDR, a Proxmark3, and hours of setup into a pocket device an untrained person can operate in minutes. For defenders that means the Flipper is a symptom rather than the disease: it is an accessibility multiplier aimed at systems that were already insecure.

This information is provided for general awareness and defense purposes only. It is not intended to be a complete description of the functionality or risks of the identified tools.

Quick Facts

• What it is: An open-source handheld multi-tool that captures, stores, and replays signals across sub-GHz, 125 kHz LF RFID, 13.56 MHz NFC, Bluetooth Low Energy, infrared, and 1-Wire.
• What it does not have: a Wi-Fi radio. Wi-Fi attacks require an ESP32 add-on board, which costs about $8 on its own.
• Where it is genuinely effective: fixed-code sub-GHz systems, 125 kHz prox badges, and MIFARE Classic with default or dictionary keys.
• Where it is not: DESFire EV1 through EV3, iCLASS SE and Seos, properly implemented rolling codes, EMV payment fraud, vehicle ignition, and RF jamming.
• Realistic range: 10 to 20 m for sub-GHz and BLE work, and 2 to 10 cm for LF and NFC reads. Badge cloning across a lobby is not supported by the hardware.
• The actual gap: visibility. Sub-GHz, BLE, LF, and infrared activity falls entirely outside Wi-Fi and wired instrumentation, so an adversary in those bands is not stealthy, just unobserved.

The following short briefing explains how the Flipper Zero democratizes wireless attack tooling across Bluetooth, sub-GHz, and infrared, and why unmonitored legacy protocols are exploited in plain sight.

Verified Hardware Baseline

These figures come from the manufacturer’s published technical documentation. Use them rather than the numbers repeated in press coverage, which are frequently wrong in both directions.

Subsystem	Component	Specification
MCU	STM32WB55RG	Cortex-M4 at 64 MHz for the application, Cortex-M0+ at 32 MHz for the radio
Memory	—	1024 KB flash, 256 KB SRAM shared between app and radio, microSD expansion
Integrated radio	STM32WB55	Bluetooth LE 5.4, 802.15.4, proprietary modes
Sub-GHz	TI CC1101	300 to 928 MHz across three hardware bands; 20 dBm maximum transmit
NFC	ST ST25R3916	13.56 MHz high frequency
LF RFID	MCU and analog circuitry	125 kHz nominal, 110 to 140 kHz at reduced distance; no dedicated LF chip
Infrared	3 transmit LEDs, TSOP-75338TR receiver	Learn and replay with a large community code library
iButton	1-Wire pogo pins	Dallas, Cyfral, Metakom
Expansion	GPIO header	3.3 V logic, 5 V tolerant, SPI/UART/I²C
Power and size	2100 mAh LiPo	100 × 40 × 25 mm, about 102 g

Realistic Range

Manufacturer documentation cites a 50 m maximum for the sub-GHz module. An independent path-loss measurement campaign published in peer-reviewed proceedings found the transmitted signal stayed above −90 dBm, within IoT receiver sensitivity, out to roughly 15 m outdoors.

Plan against 10 to 20 m for sub-GHz and BLE, and 2 to 10 cm for LF RFID and NFC. That second figure carries most of the threat-modeling weight: badge attacks require near-contact proximity. Claims of cloning a credential from across a lobby are not supported by the hardware, which means the practical attack requires a moment of physical access to the card, not a line of sight to its owner.

Firmware Changes the Threat Model

Official firmware is region-locked and refuses transmission on restricted frequencies. Community firmware removes those guardrails and adds capability, and any assessment premised on out-of-box behavior is optimistic by a wide margin.

Firmware	Character	Threat-model impact
Official	Region-locked, conservative feature set	Baseline; the gap to third-party builds narrowed considerably by 2026
Unleashed	Region unlock, extended sub-GHz ranges	Removes frequency guardrails and expands credential key dictionaries
RogueMaster	Aggressive feature aggregation	Broadest capability surface, with variable stability
Momentum	Polished UX, BLE spam lineage	Origin of the Apple BLE denial-of-service applets

For assessment purposes, assume region unlock, extended frequency coverage on modified builds, expanded key dictionaries, BLE MAC randomization, and BLE spam applets. The MAC randomization point matters most, because it invalidates the prefix-based detection tools most organizations reach for first.

Capability by Subsystem

Ratings below: effective means it works reliably against deployed systems, conditional means it works only against specific weak configurations, and ineffective means it does not work and is commonly misreported.

Sub-GHz, 300 to 928 MHz

Target	Rating	Notes
Fixed-code garage doors, gates, barriers	Effective	Capture and replay; no cryptographic barrier exists
Fixed-code switches, doorbells, smart plugs	Effective	Common in legacy commercial and residential installs
Wireless sensors and telemetry	Effective for read and spoof	Most transmit in the clear
Legacy KeeLoq rolling code	Conditional	Depends on manufacturer key reuse across a product line, a flaw documented since 2006
Modern authenticated rolling code	Ineffective	Requires signal suppression hardware the device does not have
Vehicle ignition and engine start	Ineffective	Unlocking is not starting; the immobilizer is a separate cryptographic system
Relay attacks against keyless entry	Ineffective	Requires paired relay hardware, which is what actual theft crews use

125 kHz LF RFID

EM4100 and EM4102, HID Prox II and H10301, and AWID are all effective targets: read and clone to a T5577 card, because no encryption exists in the protocol. Indala is conditional, since some formats read but writing is unreliable and remains Proxmark3 territory.

LF prox credentials are unauthenticated broadcast identifiers and have been considered broken for well over a decade. If your access control runs on 125 kHz prox, assume any badge that leaves the building for thirty seconds is compromised.

13.56 MHz NFC

Target	Rating
MIFARE Classic 1K/4K with default or dictionary keys	Effective; CRYPTO1 has been broken since 2008
MIFARE Classic with custom keys	Conditional; partial recovery via nested attacks, slower and not guaranteed
MIFARE Ultralight and NTAG21x	Effective for read and emulate where no authentication is configured
MIFARE DESFire EV1, EV2, EV3 with AES-128	Ineffective; vendor advisories confirm no known exploit path
HID iCLASS SE and Seos	Ineffective against properly configured deployments
EMV payment cards	Ineffective as a fraud vector; reads a UID and some public data only

Bluetooth Low Energy

• Advertisement spam abusing Fast Pair, Swift Pair, and Apple proximity pairing is effective and disruptive across iOS, Android, and Windows.
• The iOS denial of service tracked as CVE-2023-42941 is historical; Apple hardened it in iOS 17.2, and unpatched devices remain exposed.
• Collateral disruption of BLE peripherals such as payment readers, input devices, and medical accessories is effective and badly under-appreciated. See the section below.
• Traffic sniffing, decryption, and connection MITM are ineffective. The integrated radio is not a promiscuous BLE sniffer.

Wi-Fi, read this carefully

The Flipper Zero has no native Wi-Fi radio. Wi-Fi capability requires an ESP32-S2 development board running Marauder or Deauther firmware, which then provides scanning, sniffing, beacon spam, PMKID capture, and deauthentication.

Two implications follow. Wi-Fi attacks attributed to a Flipper are attacks by an ESP32 that happens to be riding on one, and the same attack costs about $8 with a bare board. And deauthentication is a management-frame attack that 802.11w Protected Management Frames mitigates, which WPA3 mandates. If your enterprise WLAN does not enforce PMF, that is the finding, not the Flipper. Detection belongs to your existing wireless intrusion detection, not to a device-specific control.

Infrared, BadUSB, and iButton

Infrared learn-and-replay works against TVs, projectors, HVAC, and A/V control, backed by a large crowd-sourced database. Severity is low in most environments and non-trivial in conference rooms, hospitality, signage, and any facility where infrared controls physical systems.

BadUSB mode enumerates the device as a keyboard and runs scripted keystroke payloads, which is USB Rubber Ducky functionality in something that does not look like an attack tool. It is a physical-access attack requiring an unlocked, unattended endpoint, so the mitigation is ordinary endpoint hygiene: USB device control, HID allow-listing, short lock timeouts, and port control on kiosks and shared workstations. The iButton reader covers Dallas, Cyfral, and Metakom contact keys, which matters mainly for legacy intercom and building-entry systems.

The Under-Discussed Risk: Collateral BLE Disruption

BLE advertisement flooding is usually filed under prank. The documented consequences argue otherwise.

At Midwest FurFest in 2023, BLE spam in a crowded venue produced reported disruption to Square payment readers, and an attendee reported that the Android device controlling their insulin pump crashed. BLE-connected hearing aids and heart-rate monitors were also reported affected, and Bluetooth mice and keyboards commonly stop responding during sustained floods.

The attacker’s intent in that case was almost certainly nuisance, and the impact reached safety-relevant systems. Any environment with BLE-dependent medical accessories, payment infrastructure, industrial HMI, or assistive devices should treat advertisement flooding as an availability risk with potential physical consequence. It also means a Flipper operating nearby can cause an incident in your facility without anyone targeting your organization at all.

Incident and Policy Timeline

Date	Event
2020	Kickstarter campaign raises more than $4.8M from over 37,000 backers
2022 to 2023	Viral social video drives mainstream awareness, much of it exaggerated or staged
2023	Amazon delists the device under its card-skimming policy; Brazil’s Anatel begins seizing imports and refusing certification
Oct to Nov 2023	Apple BLE denial-of-service applets appear in community firmware and are ported to Android, Windows, and a standalone app
Dec 2023	Midwest FurFest disruption; Apple addresses the iOS crash in 17.2; the Wall of Flippers detection tool is published
Feb 2024	Canada announces intent to ban import, sale, and use, citing roughly 90,000 annual vehicle thefts
Mar 2024	Canada withdraws the ban, shifting to enforcement against illegitimate use
Aug 2025	Reporting surfaces an underground market in firmware targeting vehicle keyless entry; the manufacturer publishes a technical rebuttal
2026	Peer-reviewed capability and path-loss studies published; official and third-party firmware converge; no second-generation hardware announced

The Canadian episode is the reference case for why device-targeted bans fail. The stated justification described a capability the hardware does not have, and the withdrawal in favor of prohibiting illegitimate use is the more durable model. The productive regulatory lever sits on the vulnerable systems instead: minimum security standards for keyless entry, mandatory disclosure, and end-of-life timelines for unauthenticated credential technology.

Detection

What works

Full-spectrum passive RF monitoring is the only approach that generalizes, because it keys on activity anomalies with device attribution and location rather than on identifying one product. Signals worth alerting on:

• Sub-GHz transmissions in bands where no legitimate on-site emitter exists, typically 315, 433, 868, or 915 MHz.
• Repeated near-identical sub-GHz bursts consistent with capture and replay.
• BLE advertisement rates far above baseline, or payloads spoofing Fast Pair, Swift Pair, or Apple proximity services.
• BLE devices with rapidly rotating addresses appearing in a fixed physical location.
• New unmanaged 2.4 GHz emitters near access-control infrastructure.

Access-control telemetry is the second half of the picture, because cloning is largely invisible at the RF layer and often visible in the log: badge reads outside behavioral norms, presentations at physically implausible times, repeated failed reads at one reader, and any credential used while its holder is known to be elsewhere. Endpoint telemetry covers the BadUSB path, where a new HID enumerating on a machine that should have no keyboard is the signal.

What does not work reliably

• BLE MAC prefix fingerprinting. Tools such as Wall of Flippers identify the device by address prefix. That works against stock firmware and fails against any build that randomizes the address, which is standard in the firmware most likely to be used adversarially. Useful for awareness, not as a control.
• Visual identification and possession policy. The device is smaller than a phone, and the same capability lives in a phone, a Proxmark3, or a keyfob-sized ESP32.
• Wi-Fi-only WIDS. Blind to every band the device uses natively.

One coverage gap deserves naming plainly: most commercial RF monitoring, Bastille included, does not sense 125 kHz LF fields. LF badge cloning is therefore effectively undetectable at the RF layer in most deployments. Compensate with access-control log analytics and credential migration rather than with sensors.

Mitigations by Domain

• Physical access control, highest priority. Inventory credential technology at every reader, including secondary and legacy doors. Migrate to DESFire EV3, iCLASS SE, or Seos, and verify the reader runs in secure mode with mutual authentication, because a secure credential in a reader left in legacy mode buys nothing. Phase the cutover with multi-technology cards, add PIN or mobile MFA at high-risk doors, tighten deprovisioning latency, and alert on off-hours read patterns.
• Sub-GHz systems. Inventory every gate, barrier, garage, bollard, and dock door, identify the fixed-code ones, and replace them with authenticated rolling code or credentialed access. Where replacement is not near-term, add camera coverage tied to actuation events or a secondary credential. Treat any wireless sensor feeding a safety or operational decision as spoofable until proven otherwise.
• Bluetooth. Enforce BLE policy on managed endpoints, disable Fast Pair and Swift Pair notifications on managed fleets, keep OS patch levels current, and inventory BLE-dependent operational and safety systems with an availability contingency for each.
• Wi-Fi. Enforce 802.11w PMF and move to WPA3 where supported, and keep rogue access point and evil twin detection active.
• Endpoints. USB device control with HID allow-listing, short enforced screen-lock timeouts, and physical port control on kiosks, conference room PCs, and shared terminals.
• Program level. Add wireless attack surface to physical security assessments and red team scope, since most engagements still stop at the network boundary, and deploy full-spectrum monitoring integrated to SIEM where the environment justifies it.

In budget order: credential migration off 125 kHz prox and CRYPTO1, replacement of fixed-code sub-GHz systems on anything that matters, PMF and WPA3 enforcement, endpoint USB device control, then RF monitoring for environments where undetected wireless activity is unacceptable. Do not spend the budget on device-possession policies you cannot enforce.

Common Misconceptions

Claim	Reality
It can steal cars	It can unlock some vehicles with weak implementations and cannot start them
It defeats rolling codes	Only implementations that reuse a manufacturer key across a product line
It is a card skimmer	It cannot produce usable EMV transaction data
It hacks Wi-Fi	No native Wi-Fi radio; that requires an ESP32 add-on
It clones any badge	125 kHz prox and weak MIFARE Classic, not DESFire EV3, iCLASS SE, or Seos
It works from across the room	LF and NFC need near contact; sub-GHz and BLE are realistically 10 to 20 m
It can jam signals	No jamming or signal-suppression hardware
It crashes iPhones	Patched in iOS 17.2; unpatched devices remain exposed
Banning it solves the problem	Every capability exists in a Proxmark3, HackRF, ESP32, or phone app
It introduced new attacks	Every technique predates the device, several by fifteen years or more

Frequently Asked Questions

Can a Flipper Zero steal a car?

Not in the sense of driving it away. Underground firmware sold through private channels in 2025 targeted keyless-entry protocols and could unlock doors on some models, but unlocking is not starting, and engine start requires defeating a separate immobilizer. The manufacturer’s rebuttal is consistent with the hardware: the device lacks the signal-suppression capability that rolljam-class attacks need, and the techniques recycled are KeeLoq weaknesses published in 2006. Actual theft crews use purpose-built relay amplifiers and CAN injection tools.

Can it clone our employee badges?

If they are 125 kHz prox such as HID Prox, EM4100, or AWID, yes, in seconds with near-contact proximity. If they are MIFARE Classic, usually yes, in under a minute where default or dictionary keys are in use. If they are DESFire EV1 through EV3, iCLASS SE, or Seos with properly configured readers, no. Vendor advisories are explicit that AES-128 DESFire credentials are not exploitable by this device.

Is it a credit card skimmer?

No. It reads a card’s UID and certain publicly readable fields over NFC and cannot produce data sufficient for a fraudulent transaction against modern EMV. The card-skimming justification behind Amazon’s delisting is not technically supported.

Does it do Wi-Fi?

Not natively, and this is the single most common technical error in enterprise assessments of the device. Wi-Fi requires an ESP32 development board running Marauder or Deauther firmware.

Can it jam signals?

Not meaningfully. It has no wideband jamming or signal-suppression hardware. Sustained BLE advertisement flooding produces effects that resemble denial of service in the 2.4 GHz band, but that is protocol abuse rather than RF jamming.

Can it still crash iPhones?

CVE-2023-42941, the BLE advertisement flood that froze and rebooted iOS 17.x devices, was addressed in iOS 17.2. Devices that never updated remain exposed, and nuisance-level BLE spam still works across iOS, Android, and Windows. Platform mitigations are disabling Fast Pair notifications on Android, Swift Pair on Windows, and turning Bluetooth off from Settings rather than Control Center on iOS.

Is it legal to own?

In the United States, yes, with no federal ban. Canada permits ownership after withdrawing its proposed ban in March 2024 in favor of targeting illegitimate use. Brazil has effectively banned it through certification refusal and import seizure, and Amazon has prohibited sales since 2023. Possession and use are separate questions everywhere: transmitting on frequencies you are not licensed for, and unauthorized access to systems, are offenses independent of the tool.

Should we ban it in our facility?

A possession ban is defensible policy and nearly useless as a control. It is unenforceable without search, trivially evaded by a device smaller than a phone, and does not touch the capability, since a Proxmark3, HackRF, ESP32, or smartphone app covers most of the same ground. Ban the behavior, instrument the spectrum, and fix the underlying systems.

Can we detect it?

Partially. BLE detection by MAC prefix works against stock firmware and fails against firmware that randomizes the address. Reliable detection means full-spectrum passive monitoring keyed on activity signatures such as anomalous sub-GHz transmissions and BLE advertisement floods, rather than on device fingerprints.

If we cannot detect the device, what do we detect?

Activity. A sub-GHz transmission in a facility where nothing should be transmitting on 433 MHz is a finding regardless of what produced it. Signature-based device detection ages badly; anomaly-based spectrum monitoring does not.

Does custom firmware change our risk assessment?

Materially. Assume region unlock, extended frequency ranges, expanded credential key dictionaries, MAC randomization, and BLE spam applets. Any assessment based on out-of-box behavior is optimistic.

Is this actually a new threat?

No. It is a distribution and accessibility event. What changed is the size of the population able to execute these attacks and the number of casual, non-targeted attempts your environment will see. That shift is real and worth planning for even though the technique inventory is unchanged.

Assessment Questions for a Facility Review

1. What credential technology is in use at every reader, including secondary and legacy doors?
2. Are those readers configured in secure mode, or left in backward-compatible legacy mode?
3. Which sub-GHz-actuated systems are fixed-code, and what does each one protect?
4. Is PMF or WPA3 enforced across the entire WLAN, including guest and IoT SSIDs?
5. Which operational or safety systems in this facility depend on BLE availability?
6. What USB device-control policy is enforced, and on which endpoint classes?
7. What RF activity can we currently observe, with what attribution and location precision?
8. Would we know if a sub-GHz replay occurred at the loading dock gate at 2 a.m.?
9. Does our red team scope include physical and RF vectors?
10. What is our credential deprovisioning latency, in hours?

How Bastille Addresses This Threat

Bastille provides continuous visibility into the wireless environment through 100% passive monitoring of the RF spectrum, covering 100 MHz to 7.125 GHz with software-defined radios. That range spans the sub-GHz and BLE activity these devices actually use, which Wi-Fi-focused tooling never observes, and patented localization resolves a detection to a physical position so a team can respond rather than speculate.

Two honest boundaries. RF monitoring does not sense 125 kHz LF fields, so badge cloning is an access-control analytics problem rather than a sensing one. And monitoring detects activity, not intent or device model, which is precisely why it keeps working when the next device replaces this one.

The Flipper Zero did not create the wireless attack surface. It made the surface obvious, cheap to reach, and popular. See a demo to understand what is transmitting in your environment, or explore more Bastille wireless security research.