# ESP32-Sour-Apple ports an iOS 17 Bluetooth crash exploit to cheap hardware

> SourApple is a port of ECTO-1A's Bluetooth Low Energy crash exploit to ESP32 boards, Raspberry Pi and other Python-capable devices, spamming pairing requests until an iOS 17 device freezes and restarts. It is a research artefact with a stated permission warning, and the affected iOS versions have since been patched.

**RapierXbox/ESP32-Sour-Apple** — Crashes iOS 17 Devices wirelessly using really any device

- Repository: https://github.com/RapierXbox/ESP32-Sour-Apple
- Stars: 627 · Forks: 57
- Language: Python
- License: GPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/rapierxbox-esp32-sour-apple

## A denial of service against iOS 17 over Bluetooth

SourApple is described in the repository as crashing iOS 17 devices wirelessly using really any device, and the README calls it the iOS 17 BLE Crash Exploit. The mechanism is a denial of service rather than anything subtler. The iPhone starts to freeze after a few seconds of it getting spammed with BLE pairing requests. After a random looking amount of time the iPhone turns completely black, and you can then force restart it with Volume UP, Volume Down and holding the power button, or alternatively wait for it to restart by itself. The README adds a practical note about the hardware: while testing on an ESP32-S3 it reaches stable temps at around 57c, so heat should not be of concern, though some Pi models report getting a little bit hotter than that and it still should not be an issue. The exploit was originally developed and discovered by ECTO-1A, and this repository is a port of that work rather than the discovery itself, which is the correct attribution for anyone reading the project history.

## Ports to three different hardware families

The engineering contribution here is the porting, not the bug. The author states that the exploit was ported to the ESP32 and to Raspberry Pi, and to any devices that can run python. The scripts are meant for the ESP32, and the reason given is practical: the ESP8266 does not have BLE. The contributor list makes the scope clearer. ECTO-1A found the exploit. @WillyJL ported the exploit to Flipper Zero. @Amachik helped make the RPi script. @N1-TR0 made the micropython script and @FLOCK4H made the circuitpython script. So the repository carries at least four distinct implementations, targeting a microcontroller, a Linux single board computer, and two Python dialects for microcontrollers, plus the Flipper Zero port. The repository layout is minimal by design, with a LICENSE, the README and a scripts/ directory. There are no GitHub releases, so the scripts directory is where the variants live, and the last push to the repository was on 2026-06-03.

## The tested device matrix, and what it tells you about scope

The README publishes exactly which combinations were tested and, importantly, at the time of writing. On an ESP32-S3, iPhone 14 Pro on iOS 17.2 build 21C5029g and iPhone 14 Pro on iOS 17.1 builds 21B506 and 21B74. On an ESP-WROOM-32, iPhone 12 Pro on iOS 17.0 build 21A329. On a Raspberry Pi 4, iPhone XS on iOS 17.0, iPhone 12 Pro on iOS 17.1 Beta 2, and iPhone 11 Pro on iOS 17.1.2 build 21B101. On a Raspberry Pi Pico W, iPhone 13 Pro on iOS 17.2.1 build 21C66 marked as patched, iPhone 13 on iOS 17.0.3, iPhone 12 on iOS 17.0 and 17.0.1, and iPhone 11 on iOS 17.0 build 21A326. The matrix is the most useful part of the documentation for an engineer, and one entry in it is the one to notice first. The iPhone 13 Pro on iOS 17.2.1 is labelled patched, which tells you the vendor shipped a fix and the behaviour no longer reproduces there. Every other entry sits on iOS 17.0 through 17.2. If you are evaluating this for research, that matrix is the boundary of what was ever demonstrated.

## Firmware variants and the esp_fill_random build error

The build problem the project documents is worth understanding, because it is the kind of thing that eats an afternoon. If you get a compilation error telling you esp_fill_random was not declared, there is an easy fix. esp_fill_random is a hardware random generation function and is available on most ESP32 boards. There are two ways forward. The first is to choose another ESP32 board and just compile for it and hope that it works. The second is to add these lines of code, which supply a software implementation that fills a buffer with random values.

```c
void esp_fill_random(uint8_t* buf, size_t len) {
  for(size_t i = 0; i < len; i++) {
    buf[i] = random(0, 1000);
  }
}
```

The tradeoff is visible in the code. The hardware generator exists because the ESP32 has a true random number source, and a software substitute built on random(0, 1000) is a different quality of randomness, and a different distribution. For a BLE pairing request spammer the entropy quality is not the interesting part, but for anyone reusing this pattern elsewhere it is worth knowing that the workaround is a stand-in rather than an equivalent. The first fix, compiling for a different board, keeps the hardware path intact, which is the better default when you have the choice.

## The project ships as scripts, and the README says where to get it

There is no install procedure in the documentation, and there is no package to install. The repository is a LICENSE file, a README and a scripts directory containing the ports, and the intended workflow is that you pick the script matching your hardware and Python environment, then flash or run it. The variants named in the contributor list map onto that: a MicroPython script, a CircuitPython script, an RPi script for a Linux board, and a Flipper Zero port. There is no reference to a package index, no dependency list and no version pinning, so the project expects the reader to know which runtime they need and to bring their own toolchain. The licence is GPL-3.0, which for a repository of exploit scripts distributed under the hood of a warning about legal use is a reasonable choice, since it keeps derivatives under the same terms. The README also carries a funding and responsibility note, telling readers everything is provided as-is and has no warranty, so if you break any of your devices that is on you.

## The permission warning, and what it means for use

The README opens with a warning that is worth taking at face value rather than as boilerplate. Only use this on devices you own or when you have permission to use it, and the project is made for educational purposes only and is not made to break laws or for personal gain. That framing is consistent with the rest of the repository. The behaviour is a denial of service, so the only thing a successful run produces is a frozen phone that has to be force restarted, and the affected versions are old. The same properties that make this useful for research, which is that the reproduction is cheap, repeatable and hardware independent, are the properties that make it a nuisance if pointed at someone else's phone. Bluetooth Low Energy has a short range, but short range is not the same as no effect in a room, an office or a café. The honest way to work with this project is to reproduce it in a lab with your own hardware, which is also what the tested device matrix implies, since every entry there is a paired board and phone the author controlled.

## Why a hardware port of a BLE crash is still worth reading

The reason this project deserves an engineer's attention is not the crash itself, it is the portability argument. The original exploit was written by a security researcher, and this repository demonstrates the same bug reproduced from four different hardware and software combinations: an ESP32 running firmware, a Raspberry Pi running a Linux Python script, a MicroPython implementation, and a CircuitPython implementation, plus a port to the Flipper Zero. That spread is a teaching artefact about how much of a Bluetooth attack depends on the platform. The chips involved are inexpensive commodity hardware that anyone can buy, which is exactly why the ecosystem cares about Bluetooth Low Energy handling on iOS, and why a patched iOS 17.2.1 build appearing in the tested matrix is the single most consequential line in the README. For anyone working on BLE protocol handling, the port shows how the same trick is reproduced with different radio stacks, and the matrix shows the window in which it worked.

## Conclusion

Adopt ESP32-Sour-Apple if you are researching Bluetooth Low Energy protocol handling on iOS, reproduce the crash on hardware you own, or need a reference port that shows how the same exploit was moved from a researcher's original implementation to microcontroller firmware and to Python. Do not adopt it if you need a working attack against current iPhones, since the affected versions are iOS 17.0 to 17.2 and a patched build is listed among the tested devices, and do not adopt it without a lab of your own, because the documented behaviour is that nearby phones freeze and force restart. Verify two things before you wire anything up: that you have hardware with Bluetooth Low Energy, since the ESP8266 does not have it and the scripts are written for the ESP32, and that the board you compile for provides esp_fill_random, since the project documents a compilation error when it is missing. The practical first step is to read the tested device matrix in the repository and pick the board and phone combination you intend to reproduce.

## FAQ

### What does ESP32-Sour-Apple do?

It is a port of ECTO-1A's iOS 17 Bluetooth Low Energy crash exploit, running on ESP32 boards, Raspberry Pi and other devices that can run Python. It spams BLE pairing requests until the iPhone freezes and then force restarts.

### Which iPhones and iOS versions were tested?

The README lists iPhone 14 Pro on iOS 17.1 and 17.2, iPhone 12 Pro on iOS 17.0, iPhone XS on iOS 17.0, iPhone 11 Pro on iOS 17.1.2, iPhone 13 and 13 Pro on 17.0.3 and 17.2.1, and iPhone 12 and 11 on 17.0 and 17.0.1, across ESP32-S3, ESP-WROOM-32, Raspberry Pi 4 and Raspberry Pi Pico W.

### Can I run SourApple on an ESP8266?

No. The scripts are meant for the ESP32, and the README gives the reason directly: the ESP8266 does not have BLE, which the exploit depends on.

### How do I fix the esp_fill_random compilation error?

The function is a hardware random generation function available on most ESP32 boards. You can either choose a different ESP32 board and compile for it, or add a software implementation of esp_fill_random that fills the buffer with random values.

### How hot does the hardware get?

While testing on an ESP32-S3 it reaches stable temps at around 57c, so heat should not be of concern. Some Pi models report getting a little bit hotter than that, and the README says it still should not be an issue.

## Sources

- [Issues](https://github.com/RapierXbox/ESP32-Sour-Apple/issues)
- [License: GPL-3.0](https://github.com/RapierXbox/ESP32-Sour-Apple/blob/main/LICENSE)
- [RapierXbox/ESP32-Sour-Apple on GitHub](https://github.com/RapierXbox/ESP32-Sour-Apple)
- [README](https://github.com/RapierXbox/ESP32-Sour-Apple/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rapierxbox-esp32-sour-apple