Flipper Firmware on the T-Embed CC1101 Plus
A technical assessment of Sor3nt's Flipper Zero ESP32 port running from main on the LilyGo T-Embed CC1101 Plus.
The T-Embed CC1101 Plus is sold as an ESP32-S3 development board, but its hardware is close to a compact radio workstation: Wi-Fi, Bluetooth LE, Sub-GHz, NFC, infrared, a color display, storage, audio, and an integrated nRF24L01. The missing piece was a single firmware architecture capable of exposing those peripherals without reducing the device to a collection of unrelated demos.
Sor3nt’s Flipper Zero ESP32 Port supplies that architecture. We run it on a T-Embed CC1101 Plus built from the repository’s main branch rather than the latest tagged binary. The result is good firmware, not because it copies the Flipper Zero interface, but because it preserves enough of Furi’s application model while using the ESP32-S3 hardware for capabilities the original device does not provide on its own.
That distinction also defines the limits of this assessment. The project is an active port, main moves ahead of stable releases, and hardware compatibility varies sharply by board. It should be evaluated as an embedded red-team platform under development, not as a drop-in replacement for every Flipper Zero function.
The Device on the Bench#
The LilyGo T-Embed CC1101 Plus uses a dual-core Xtensa LX7 ESP32-S3 running at up to 240 MHz. The board provides 16 MB of flash, 8 MB of PSRAM, a 320 by 170 ST7789 color display, 2.4 GHz Wi-Fi, Bluetooth 5 LE, a CC1101 Sub-GHz transceiver, a PN532 NFC controller, infrared transmit and receive, audio hardware, a microSD slot, and a rotary encoder. The Plus model adds the nRF24L01 used by the firmware’s 2.4 GHz tooling.
Those components matter more than the processor clock. A radio tool spends much of its time moving frames through DMA-capable buffers, holding protocol state, writing captures, and keeping several services alive. The port deliberately moves larger allocations, task stacks, Bluetooth buffers, application code, and read-only data into PSRAM so internal SRAM remains available for DMA and time-sensitive controller work.
The input model is different from the five-button Flipper Zero interface. Sor3nt maps directional navigation and confirmation onto the rotary encoder and its button. Most scenes remain recognizable because the port keeps the original 128 by 64 logical framebuffer, then scales it into RGB565 for the wider color display. The panel is sharper and more colorful, but ported applications still think in the original canvas dimensions.
The physical package is the first practical benefit. A base T-Embed CC1101 was listed at USD 49.38 during this review, while the Plus model was USD 60.65. The official Flipper Zero was listed at USD 199. Those prices exclude regional shipping and taxes, and the devices are not feature-equivalent, but the T-Embed gives researchers a lower-cost route into a broad ESP32 radio platform.
What Sor3nt Ported#
This project does not run the STM32 firmware image through emulation. It rebuilds the useful architectural contracts around ESP-IDF. Furi-style threads, mutexes, events, records, message queues, the loader, storage, GUI, desktop, input, and Bluetooth services run on top of FreeRTOS. Applications retain familiar APIs while a replacement hardware abstraction layer talks to ESP32 peripherals.
The HAL maps display work to esp_lcd, touch and PN532 communication to I2C, infrared timing to RMT, Bluetooth to Bluedroid, and USB HID, CDC, and mass storage to TinyUSB. Sor3nt also redefines malloc to calloc because code written for the original environment can assume zeroed allocations. That small compatibility decision prevents a class of state bugs that would otherwise appear far above the allocator.
The architecture is easier to understand as a set of preserved contracts over replaced hardware:
flowchart TD
A["Flipper apps and UI"] --> B["Furi compatibility layer"]
B --> C["FreeRTOS services"]
C --> D["ESP-IDF hardware layer"]
D --> E["Wi-Fi, BLE, RF, NFC, IR"]
This is why the firmware feels coherent. The Wi-Fi scanner, NFC reader, Sub-GHz analyzer, file browser, Bad USB runner, and system settings do not behave like separate sketches. They participate in one loader, one storage model, one event system, and one user interface.
Building from Main#
The latest tagged release during this review is v1.1.6, published on July 31, 2026. The current source tree identifies itself as 1.1.7, and its latest observed commits were dated September 2. We use the latter, which gives us access to recent work but also means the firmware state is not represented by a stable release tag.
The build requires ESP-IDF v5.4.1. Sor3nt provides target scripts for Linux, macOS, and Windows. The following commands clone the repository, record the exact revision, load the ESP-IDF environment, and produce a T-Embed build without flashing it automatically.
git clone https://github.com/Sor3nt/Flipper-Zero-ESP32-Port.git
cd Flipper-Zero-ESP32-Port
git switch main
git pull --ff-only
git rev-parse HEAD
source "$HOME/esp/esp-idf/export.sh"
./buildAndFlash_T-Embed.sh --build-onlyRecording the commit is essential. Calling a build “1.1.7” is not precise while development continues on the same branch. A reproducible report should include the full Git commit, the ESP-IDF version, the board revision, and whether the image came from the web flasher, a release asset, or a local build.
The Plus model uses the same T-Embed target while exposing the additional nRF24L01 hardware. Most applications and assets also require a FAT32-formatted microSD card populated from the project’s sdcard.zip. Flashing only the firmware produces an incomplete environment because protocol databases, FAPs, scripts, animations, and application data live under /ext.
The Radio Surface#
The port is strongest when the integrated radios are treated as one platform. The CC1101 application receives and decodes known Sub-GHz protocols, stores unknown waveforms as .sub files, sweeps frequencies with live RSSI, transmits saved signals, creates manual frames, runs playlists, and includes several TPMS decoders. Its usable frequencies still depend on the CC1101 front end, antenna design, firmware policy, and local regulation.
Wi-Fi is native to the ESP32-S3, so network operations do not require a separate development board. Current firmware includes access-point discovery, WPA-family connections, packet capture to PCAP, EAPOL handshake capture, deauthentication, beacon generation, LAN discovery, common-port probing, a web crawler, and an Evil Portal with optional upstream internet forwarding through NAPT and DNS forwarding.
The PN532 path covers reading, saving, emulating, and writing supported NFC cards and tags. It includes MIFARE dictionary workflows, FeliCa inspection, DESFire application inspection, ISO15693 operations, EMV transaction history, and card-specific parsers. Infrared supports decoded and raw learning, stored remotes, universal databases, and common protocols such as NEC, Samsung, RC5, RC6, SIRC, Kaseikyo, RCA, and Pioneer.
The Plus board’s nRF24L01 expands the 2.4 GHz surface. The application exposes activity scanning, a spectrum view, MouseJack testing, and configurable channel-selection and transmission strategies. Some modes intentionally generate interference, so a shielded or isolated lab is the correct environment for validation.
| Interface | Main hardware | Useful output | Key limitation |
|---|---|---|---|
| Sub-GHz | CC1101 | Decoded records and .sub captures | Encrypted manufacturer keystores are unavailable |
| Wi-Fi | ESP32-S3 radio | PCAP, EAPOL, LAN and portal data | Memory pressure varies by target board |
| NFC | PN532 over I2C | Saved card and protocol records | Not identical to the Flipper ST25R3916 path |
| Infrared | ESP32 RMT | Decoded or raw remote signals | Pin and RX support depend on the board |
| 2.4 GHz | nRF24L01 | Spectrum data and test transmissions | Present on the Plus model or external hardware |
Mesh Turns ESP32 Boards into Sensors#
The Buddy subsystem is one of the port’s more useful departures from a single-device workflow. A T-Embed acts as the master while inexpensive headless ESP32 boards advertise capabilities over ESP-NOW. The master discovers, pairs, identifies, starts, and stops features through the same interface used by local applications.
The current Buddy firmware exposes device identification and passive Wi-Fi handshake capture. A buddy stores beacon and EAPOL frames per BSSID in RAM and NVS. Once it has the required handshake state, it fragments the result, sends it to the master, waits for acknowledgment, and removes the stored record only after delivery succeeds.
That store-and-forward behavior changes the operational model. A capture node can remain powered without a display, SD card, or buttons while the T-Embed is elsewhere. When the master returns, the buddy delivers a complete record that is written as a PCAP on the T-Embed’s SD card.
The protocol is intentionally small. ESP-NOW messages carry discovery, pairing, capability, feature control, status, fragmented results, and acknowledgments. The design is not a general mesh framework yet, but it provides a clean path for adding remote sensors without duplicating the complete user interface on every board.
FAP and Script Compatibility#
FAP support is valuable, but the compatibility boundary needs precise wording. Official Flipper Zero application packages contain code compiled for an ARM Cortex-M target. The T-Embed uses Xtensa, while supported Waveshare boards use RISC-V. An arbitrary precompiled ARM .fap cannot be treated as a portable binary.
Sor3nt supplies buildFap.sh to compile application source against the port’s headers and API table. The active target in the current script is the Xtensa ESP32-S3 T-Embed build. The Waveshare RISC-V entry is commented out. In practice, FAP support means the architecture can dynamically load packages built for this port and target, not that every file from the official Flipper catalog can be copied unchanged.
The source-porting story is still good. Keeping the framebuffer, application manifest format, Furi records, loader behavior, storage paths, and broad API shape reduces the work required to adapt an application. The shipped SD package demonstrates this with tools, protocol applications, authenticators, and games compiled for the ESP32 target.
The mJS runner covers a second extension path. Scripts can use modules for GUI, notifications, math, storage, the event loop, Sub-GHz, infrared, Bad USB, and BLE beacons. Serial, GPIO, I2C, and SPI JavaScript modules are excluded because their HAL bindings have not been ported.
Main Is Moving Beyond the Stable Release#
The source after v1.1.6 adds more than radio work. Web Filesystem exposes the microSD card through an HTTP interface over either the existing Wi-Fi connection or a dedicated WPA2 access point. The SMB browser discovers servers on TCP port 445, authenticates against SMB2 or SMB3 shares, navigates directories, and downloads files to the SD card.
Android TV support implements the Remote v2 protocol. It discovers compatible Android TV and Google TV devices on the LAN, uses TLS ports 6466 and 6467 for control and pairing, accepts the PIN displayed by the target, and retains client credentials for subsequent sessions.
The streaming application contains local playback plus AirPlay, Google Cast, and DLNA control paths for audio and video. Firmware and SD-content update code is also present, including an ESP OTA write phase and a separate delta synchronization phase for SD assets.
These additions make the current build more useful, but they also increase the test surface. Wi-Fi, Bluetooth, PSRAM, flash writes, filesystem access, and long-running worker tasks interact in ways that a tagged release normally stabilizes. Building from main is appropriate for active testing, provided the exact revision is retained and regressions are expected.
Why This Firmware Is Good#
The firmware is good because it makes the hardware understandable. It replaces a pile of peripheral examples with a consistent operating model. Storage, background services, navigation, application loading, and radio data all follow recognizable Flipper patterns, which reduces context switching when moving between tools.
It also uses the ESP32-S3 for more than basic compatibility. Integrated Wi-Fi supports local capture, network discovery, portals, file serving, OTA work, media control, and ESP-NOW companions. PSRAM is treated as an architectural resource rather than unused capacity. TinyUSB allows HID, CDC, and mass-storage roles to share the same device.
The project remains unusually inspectable for firmware with this feature density. The repository contains the master firmware, Buddy implementation, board targets, build scripts, tests, FAP tooling, SD layout, release binaries, and asset digests. A researcher can trace a menu action into a scene, service, HAL function, and peripheral driver without relying on an opaque mobile application.
The value is strongest for engineers who already understand the difference between capability and authorization. The port provides a compact environment for protocol study, device testing, capture pipelines, and application development. It is less suitable for someone expecting a supported consumer appliance with fixed behavior and full parity with an official Flipper Zero.
The Boundaries Still Matter#
The T-Embed is not a complete hardware clone. It has no dedicated 125 kHz LF RFID front end and no iButton 1-Wire interface comparable to the official device. Missing hardware paths can be represented by compatibility stubs, but a stub preserves compilation rather than physical capability.
The port also lacks the Flipper Enclave key used with encrypted Sub-GHz manufacturer keystores. The README states that keeloq_mfcodes, nice_flor_s, and alutech_at_4n cannot be decrypted. Only the plain-text keeloq_mfcodes_user path is documented as usable for Keeloq decoding.
Board support is not uniform. The Waveshare C6 1.47 target is documented as having insufficient memory for heavy Wi-Fi capture because it has 512 KB of SRAM and no PSRAM. The DIY ESP32-S3 target remains work in progress, and the public web flasher exposes fewer complete choices than the source tree.
The issue tracker contains reports involving handshake-file persistence, infrared freezes, MIFARE workflows, and input navigation. We did not reproduce those reports for this article, so they are maintenance signals rather than universal failure claims. They still reinforce the need to preserve captures, record revisions, and test changes before relying on the device during an engagement.
There is also a documentation conflict around AirSnitch. The README calls it an automatic password-list brute-forcer. Current source comments describe a read-only test for client-isolation failures using local ARP discovery and gateway-routed probes. The implementation should be treated as authoritative until the maintainer reconciles the description.
Use It as a Lab Instrument#
Several applications can transmit, impersonate, interrupt, capture, or inject. Deauthentication, Evil Portal credential collection, Bad USB, MouseJack testing, Sub-GHz transmission, NFC emulation, and radio jamming can affect systems beyond the device running the firmware. The correct test boundary is equipment you own or a scoped environment where the operator has explicit permission.
The repository carries a separate warning about firmware distributed under the names L15Dev or Bitwire, which the maintainer reports as containing malware and a backdoor. That claim was not independently validated here. The practical control is still clear: build from the official Sor3nt repository or use its official release assets and web flasher, then verify the published SHA-256 digest where one is available.
The repository currently has no root license detected by GitHub, while the upstream Flipper firmware is GPL-3.0 and bundled components contain their own licenses. Running the firmware is separate from redistributing a modified build. Anyone shipping binaries or derived source should resolve the licensing status instead of inferring a blanket license from individual files.
Verdict#
Sor3nt’s port turns the T-Embed CC1101 Plus into a credible embedded red-team platform. It provides a strong Flipper-style application model, integrated Wi-Fi, useful radio coverage, an extensible ESP-NOW companion design, and enough memory to run workloads that would be uncomfortable on smaller targets.
Its best feature is not any individual scanner or transmitter. The best feature is the compatibility layer that makes all of them participate in one system. That foundation is why the project can absorb new network clients, storage services, applications, and board targets without becoming an unmaintainable firmware menu.
We will keep running builds from main because that is where the interesting engineering lands first. We will also treat every build as a specific commit, preserve the stable release distinction, and test only inside controlled environments. With those constraints, this is good firmware on hardware that gives the port room to grow.