FAQ
TL;DR: This FAQ helps WB2L and BK7231 developers start BLE work fast. It highlights 3 reversed link-layer functions and one core lesson: "details help beginners ask the right questions." Use it to bring up a simple BLE device, compare BK7231T versus BK7231N, and choose between OpenOCD/JTAG and the serial bootloader for faster reverse-engineering work. [#20742145]
Why it matters: The thread shows a practical path from a minimal BLE demo to structured library reverse engineering on real BK7231 hardware.
| Topic |
BK7231T / WB2L |
BK7231N |
| BLE register map |
Original project target |
Different map and different registers |
| BLE cell generation |
Older baseline in this thread |
Described as newer and similar, but not the same |
| Function prototypes |
Existing work and examples available |
Different prototypes |
| Reverse-engineering status |
Several functions already reversed |
BLE library work still pending |
Key insight: The fastest route is to start with the simple BK7231T BLE project, then use structured disassembly and OpenOCD to validate behavior. The thread’s later updates show that rebuilding and checking vendor BLE libraries can move the work from guesswork to repeatable engineering.
Quick Facts
- The first release was posted on 2023-07-14, and a newer tutorial update arrived on 2023-09-21 with 3 reverse-engineered link-layer functions and added training material. [#20742145]
- The shared OpenOCD/JTAG setup uses 4 GPIO lines for JTAG, 1 reset line, an adapter speed of 100, and a 200 ms SRST delay. [#20654215]
- On WB2L, pins 20-23 plus reset are exposed as test pads, and the datasheet explicitly says they can read and write flash. [#20654654]
- The published OpenOCD workflow reads flash-chip data through the telnet interface on port 4444 and uses the expected TAP ID 0x15968001. [#20654215]
- By 2026-02-24, the project included a custom Perl disassembler for libble.a and rwnx.a on both N and T chips, plus ELF and DWARF parsers up to DWARF v4. [#21847848]
How do I initialize a simple BLE device on a WB2L module using BK7231T without relying on Tuya libraries?
You start from the shared WB2L/BK7231T example project, which initializes a simple BLE device without Tuya libraries and sends data to the host. The author states it is not a full product yet, but it is enough for bring-up and study. Extract the archive with
tar xzvf bk_ble.tar.zip, then use the documentation in the
doc directory for the BLE overview and project setup.
[#20653571]
What is a transparent UART in the context of Beken BLE profile APIs, and how would it work on BK7231 chips?
A transparent UART is a BLE-to-serial data bridge that forwards bytes with minimal application logic.
"Transparent UART" is a BLE profile pattern that transports serial-style host data, a key characteristic being that the device mainly relays payloads instead of interpreting them. In this thread, it is a planned next step using Beken’s BLE profile API, followed by reverse engineering of the lower-level register calls on BK7231 chips.
[#20654018]
Which differences between BK7231T and BK7231N matter most when working with their BLE subsystems and register maps?
The biggest differences are the register map, the registers themselves, and the BLE function prototypes. The 2023 update says BK7231N uses a newer BLE cell, so the N chip looks similar to T at a high level but does not match register-for-register. That means code and notes from BK7231T cannot be copied blindly to BK7231N during BLE reverse engineering.
[#20742145]
How can OpenOCD and JTAG be used to confirm register changes while reverse engineering BLE behavior on BK7231T?
Use OpenOCD over JTAG to halt the chip, read memory-mapped registers, and compare values before and after BLE actions. The posted configuration lets you connect through shared SPI/JTAG pins, then inspect state through the OpenOCD telnet server on port 4444. The thread also notes this path would make GDB use practical and remove the need for a second serial port for prints during development.
[#20654311]
What is the step-by-step process for setting up the shared SPI/JTAG pins on a BK7231T or WB2L for OpenOCD debugging?
Use the posted OpenOCD configuration and wire the shared SPI/JTAG pins directly. 1. Map CEN, SCLK, CSN, SI, and SO to Raspberry Pi GPIO 22, 11, 8, 10, and 9. 2. Set JTAG mode, adapter speed 100, SRST-only reset, and a 200 ms SRST delay. 3. Start OpenOCD with the BK7231T config, then use telnet on port 4444 to read registers or the flash ID.
[#20654215]
Why are the SPI flash pins on WB2L harder to access in practice, and what workarounds are available when the module is glued to the main PCB?
They are harder to access because the needed WB2L pads are exposed as test points on the back, but the module may also need desoldering and can be glued to the main PCB. The thread says pins 20-23 and reset are available for flash access, yet the physical rework is the real obstacle. A practical workaround is to postpone SPI access until code experiments are done, then remove the module only if bootloader recovery or deeper flash work becomes necessary.
[#20654654]
What is the wireless arbiter on BK7231 devices, and why is it important for running BLE and Wi-Fi on the same antenna at the same time?
The wireless arbiter is the control logic the authors want to enable so BLE and Wi-Fi can share one antenna concurrently.
"Wireless arbiter" is radio-control logic that coordinates access between BLE and Wi-Fi, a key characteristic being that it manages coexistence on shared RF hardware. The stated goal is practical home automation, such as changing lighting based on the nearest BLE device while Wi-Fi remains active.
[#21848239]
How does the BLE library on BK7231N differ from BK7231T in function prototypes, code organization, and reverse engineering difficulty?
BK7231N differs mainly in function prototypes and hardware details, while the overall code organization stays broadly similar. The thread says the N chip has a different register map and different registers, but the authors still describe the global software structure as not that different from BK7231T. The reverse engineering work for the N BLE library had not started by 2023-09-21, so it remained less mature than the T-side work.
[#20742145]
What are the practical applications of reverse engineering libble.a and rwnx.a on BK7231N and BK7231T?
The practical uses include instrumenting vendor code, understanding kernel behavior, and porting libraries to newer toolchains or RTOS versions. By 2026-02-24, the team had disassembled libble.a and rwnx.a for both N and T chips and made the output easy to modify. They specifically mention inserting
printf calls, saving registers, and exploring future ports to a newer GCC and a recent FreeRTOS.
[#21848239]
How do you verify that a rebuilt BK7231 BLE library is functionally identical to the original binary, including .text, .rodata, and relocations?
You verify it by recompiling the disassembled library and comparing key binary sections against the original. The authors wrote a script that checks whether the
.text sections match, the
.(ro)data sections match, and the relocations match as well. They report that the BLE project also works with the rebuilt library, which adds a practical runtime check beyond the binary comparison itself.
[#21847848]
What is the KE kernel mentioned in BK7231 reverse engineering work, and why are its functions considered easier to analyze?
The KE kernel is the internal kernel layer the authors identify as relatively accessible during reverse engineering.
"KE kernel" is a software kernel component that provides internal runtime services, a key characteristic being that its functions appear simpler to trace than the BLE libraries around it. The thread says those functions are relatively easy to reverse engineer, making them a useful next target after basic BLE library analysis.
[#21848239]
OpenOCD vs the serial bootloader on BK7231T: which approach is better for flashing, debugging with gdb, and development speed?
OpenOCD is better for interactive debugging speed, while the serial bootloader remains the simpler existing path. The thread says OpenOCD with JTAG would speed work up tremendously because you could use GDB and avoid dedicating a second serial port to debug prints. The serial bootloader is still referenced in Tuya’s original Makefile, so it remains a known baseline for flashing when JTAG is not wired.
[#20654311]
How could replacing or reconstructing the BK7231 bootloader improve development, and what known alternatives or recovery methods are available?
Replacing or reconstructing the bootloader could make recovery safer and development more flexible after flash mistakes. The thread asks about better-known replacements, but the concrete recovery method provided is SPI flashing. A linked SPI-flashing guide is cited in the discussion as a way to reconstruct the bootloader if it was overwritten, though WB2L pad access can complicate that process.
[#20654334]
What does a structured disassembly with ELF and DWARF parsing add to BK7231 BLE reverse engineering compared with raw assembly dumps?
It makes the output easier to modify, verify, and teach from than a raw dump. By 2026, the project’s disassembler produced structured output for libble.a and rwnx.a, added BLE register names, listed C prototypes and local variables, and included ELF plus DWARF parsers up to v4. The authors also removed hard-coded offsets, which they describe as common in assembly and a barrier to experimentation.
[#21847848]
How might BLE and Wi-Fi coexistence on BK7231 be used in real projects such as proximity-based lighting control or other home automation features?
It can support automation that reacts to nearby BLE devices while keeping Wi-Fi connected on the same antenna. The thread gives a concrete example: changing lighting according to the nearest BLE device. That matters because the stated goal is not only library analysis, but also enabling the wireless arbiter so BLE and Wi-Fi can run together instead of forcing a one-radio-at-a-time workflow.
[#21848239]
AI summary based on the discussion. May contain errors.
Comments
Very impressive documentation. Comprehensive and well written. I will have to find some time to analyze it. Are you planning to support N platform as well (BK7231N)? [Read more]
We are. I think we have transparent UART' and reverse engineer the lower level calls (setting registers, basically). We try to write about details, we found that it helps beginners ask the right ques... [Read more]
Hi Andy, That writeup looks very, very nice and thank you for sharing it with us! Disclaimer - haven't read the paper yet so ignore the question if irrelevant. Have you considered using OpenOCD... [Read more]
There was a JTAG config by @xabean somewhere. [Read more]
Hi! Thanks for the question and the info about JTAG. No, we have not done anything with it but OpenOCD with jtag would be fantastic. If I understand correctly this requires access to SPI pins and a few... [Read more]
Here is a guide for SPI flashing of BK7231. It can be used to reconstruct bootloader if it was overwritten: https://www.elektroda.com/rtvforum/topic3931424.html I will, however, note here that WB2L may... [Read more]
Yes, we have seen the guide (excellent work by the way) and judging by the datasheet for WB2L pins 20-23, as well as reset are exposed as test pins on the back of the pcb. The datasheet also explicitly... [Read more]
Hi everyone! Here is a new version of the tutorial and the project. Not much new code, although we have reverse engineered three somewhat large functions in the link layer driver. There is a detailed... [Read more]
Hi Everyone! Just wanted to share updates for this project. It was used to teach a reverse engineering lab at a local college, some student projects have been incorporated. The manual is included, as before.... [Read more]
Interesting, keep us posted. What would be the practical applications of that? We didn't really touch internal drivers in OBK yet. [Read more]
Our original goal was to reverse engineer the libraries and we noticed that the disassembly was a bit laborious so we wanted something intermediate between a full C source and the machine code. This does... [Read more]