an open-source toolkit to patch, modify, and enhance the firmware of soundcore q-series headphones, with future support for other models planned.
note: this project is my personal journey into the world of hardware reverse-engineering and embedded systems. it was created by a teenager and i'm learning as i go. expect bugs, mistakes, and lots of fun. all contributions and advice are welcome!
this project is divided into two parts:
- openqore SDK - firmware SDK for soundcore headphones based on the bes2300p SoC
- qorepatcher - a patcher for the stock firmware of the headphones (this repository)
i also created a demo project - a DOOM port based on the DOOMBuds project. check that out too! =)
📚 read the full documentation 📚
this project was started with the soundcore life q35. if you want to help test or add support for a new model, please open an issue!
| model | chipset | status |
|---|---|---|
| soundcore life q35 | bes2300p | ✅ supported |
| soundcore space one | bes1502x | ❌ testing |
| soundcore life q30 | bes2300p | ❌ WIP |
| soundcore life tune pro | bes2300p | ❌ WIP |
| soundcore life tune | bes2300p | ❌ WIP |
support for other models is a future goal!
note: devices based on the
bes2300pchipset are the most likely candidates for future support.
openqore is just getting started. here's a rough plan of what's coming next:
- initial firmware patcher for sound replacement.
- unlock 48khz audio support for system sounds.
- investigate and unlock stereo support for system sounds.
- make patcher to work with all (or the most) bes chipsets
- implement patches for headphone name and mac address modification.
- remove the low volume limiter/gate on the aux input on some models (jack connection).
- create a user-friendly gui for the patcher.
- reverse-engineer the ota (over-the-air) update protocol for wireless flashing. (read faq)
- document the firmware structure and key functions.
- develop a library of community-created sound packs.
this guide assumes you have python and git installed on your system.
1. clone the repository
open your terminal and run this command:
git clone https://github.com/nnonickreal/open-qore.git
2. install dependencies
the patcher requires ffmpeg for audio conversion:
windows: download here or:
winget install ffmpeg
macos:
brew install ffmpeg
ubuntu/debian:
sudo apt install ffmpeg
3. get your firmware file
this is the hardest part. currently, you need to dump the flash memory using a hardware method. a detailed guide for connecting a uart adapter is available here:
➡️ hardware guide: connecting via uart
reading the flash via ota (over-the-air) is planned for a future update. (if it's possible :D)
4. congrats!
you can find usage instructions here
1. why i can't flash the firmware via ota (over-the-air)?
whilst the protocol for the over-the-air update was being examined, a related vulnerability was discovered, which has now been reported to Anker. once Anker gives the go-ahead to publish the final script, it will be posted here! i should point out that if you want to keep your headphones customisable via the openqore, you shouldn’t update. but it’s your choice – whether to remain vulnerable or enjoy full customisation. i’d also like to add that i wanted to implement vulnerability protection in the openqore SDK. keep an eye on the status of the one-click ota firmware script on the openqore discord server!
2. which option of the firmware (w/o ota boot or with it) in the qorepatcher i should select?
if you're patching the flash dump of the headphones, select the "with ota boot" option.
if you have downloaded the ota update image from the official update servers, select the "without ota boot" option
note: if you have patched the firmware without ota boot, you need to add it on the header of the patched firmware before flashing
nerd stuff ahead: click to expand...
this section contains some of the initial findings from reverse-engineering the q35 firmware.
the headphones have several hidden test modes. some of them could be useful for future updates or debugging.
-
engineering mode: to enter this mode, hold the power button, connect the headphones to a pc via usb-c before they turn on, and wait for them to power up.
-
rfcomm: the headphones have two serial com ports. one of them is writable. so far, the only function i've managed to trigger through this port is a UFR (explanation below). this seems to be a security measure, as it was triggered by brute-forcing various hex codes rather than a specific command. interestingly, this is not the standard reset (power + vol+) but something different.
-
testing mode: this mode is entered similarly to engineering mode, but you need to release the power button immediately after the white led flashes for the first time, before the blue light. the headphones will then appear on the pc as a device with a "device descriptor request failed" error. you can confirm you're in this mode by the white led, which blinks faster than usual. its purpose is likely related to firmware flashing. also, in this mode, the headphones can be powered on while charging!
-
undocumented factory reset (UFR): a hidden factory reset can be triggered by rapidly pressing the power button multiple times while the headphones are powered on or sending something on virtual com port (above). this will cause the firmware to hang and then force a reboot after about 30 seconds. note that this action will erase all user data, including equalizer settings, bluetooth pairings, and other configurations.
the firmware appears to be a monolithic binary divided into multiple sections. each critical section is protected by a crc32 checksum. future patchers will automatically recalculate these checksums after any modification to prevent boot failures.
- stock: the original system sounds are stored as
16khz, mono, SBCaudio streams. - modded: by patching the functions responsible for initializing the audio dac, it's possible to force the system to play back audio at
48khz, stereo. this significantly improves the quality of custom sounds.
- chipset: the heart of the q35 is a bestechnic (bes, best)
bes2300psoc. a datasheet can be found with searching. - debug port: a
uartserial port is available on the pcb, which was used for initial debugging and is the primary method for unbricking a device after a bad flash. thebes2300pchip itself has two uart ports, but only one of them is exposed as easily accessible pads on the pcb.
contributions are what make the open source community such an amazing place to learn, inspire, and create. any contributions you make are greatly appreciated.
if you have a suggestion that would make this better, please fork the repo and create a pull request. you can also simply open an issue with the tag "enhancement". don't forget to give the project a star! thanks again!
- fork the project.
- create your feature branch (
git checkout -b feature/amazing-feature). - commit your changes (
git commit -m 'feat: add some amazing feature'). - push to the branch (
git push origin feature/amazing-feature). - open a pull request.
if you find this project helpful and want to support its future development, you can treat me to a coffee or some snacks via boosty! every contribution is greatly appreciated and helps me dedicate more time to openqore.
this project was brought to life with the extensive use of ai-powered coding assistants (like claude and chatgpt). while the core reverse-engineering, research, and architectural decisions were made by the author, ai played a crucial role in accelerating the development process, writing boilerplate code, and debugging.
this is a modern project built with modern tools.
this project is licensed under the mit license. you can find the full license text in the license file.