Releases

No longer tied to one macOS build. 0.2.0 checked a SHA-1 of each bluetoothd page and did nothing on anything but 26.7.1 (25G241). 0.3.0 finds both patch sites by the code around them, with the call targets and stack offsets that move between builds masked out. The window must match exactly once in the page and only /usr/sbin/bluetoothd is touched.

Checked on 26.7.1 (25G241) and 26.7.2 (25G332): each window matches once in each build. Booted on 25G332 on the Legion 5 (MtkBt 0.2.4, BlueToolFixup 2.7.2): both patched instructions read back from the mapped pages, Bluetooth is on and bluetoothd has not crashed since boot.

If a later Tahoe update rewrites that code, the plugin patches nothing, the same as 0.2.0 on an unknown build. "When a window stops matching" in docs/HOW-IT-WORKS.md says how to find the new spot.

The kext is the exact file running on the test laptop. GPL-2.0.

sha256 LegionBtFix.kext/Contents/MacOS/LegionBtFix: 868c722b71855aedd0c96cdfb92ba88773f222ba726d8d291379cd7fc5331692

Two in-memory patches to /usr/sbin/bluetoothd on macOS Tahoe 26.7.1 (25G241) for the MediaTek MT7925 Bluetooth controller: LE Create Connection always uses the public own address (ends the bluetoothd crash loop, STATUS 718), and the A2DP Read Clock result is stored even though the controller returns handle 0 (ends "Failed to read BT clock"). Gated to that exact bluetoothd by byte windows and page hashes; on any other build it does nothing. Needs Lilu 1.7.2 or newer and MtkBt for the controller itself.

AirPods play with these patches only together with the HCI logging workaround in tools/bt-hci-logging.sh; the remaining link drop is described in the README and is not fixed here.

The kext is the exact file running on the test laptop; a clean build of this tag with tools/build-mac.sh and Apple clang 17 reproduces it. GPL-2.0.

sha256 LegionBtFix.kext/Contents/MacOS/LegionBtFix: 3c330a217c47d398a13eb70a161657f719be9b376282737b2cdf6568263d8ee5