ring-modsresearchR12

RT11CR · re-audited October 2026

The right path changes
the question.

The earlier de-load work followed the wrong packet builder. Rechecking stock code uncovered the actual raw-stream timer and a no-flash route toward the segment display.

Offline execution verified One physical C0 read passed

One image, not every R12.

The audit targets RT11CR_1.00.08_250514, hardware family RT11CR_V1.0. Model names alone are not compatibility checks. All addresses below belong to that specific stock image.

Exact stock SHA-256

3223c2a33c9b313e53c03902ff72d9e80c21107076d5502ac09386392cf8fe28

The old “unforgeable signature, therefore SWD only” conclusion was not established by the observed rollback. Later Realtek activation work had already reopened the question. This audit follows the runtime paths independently.

The actual raw-stream producer.

The A104 command schedules a callback at 0x827d14. It builds the fixed 16-byte A101, A102 and A103 packets seen in raw streaming. A different handler at 0x82ea90 builds BC/5A TLVs—the path the old de-load patches changed.

The R12 raw producer, separated from the old TLV hypothesis A104 enters the RXTX dispatch and schedules the actual raw producer at 0x827d14, which queues A101, A102 and A103 packets. The BC/5A path uses a different TLV builder, where the old patches landed. A104RXTX command Dispatch0x827f7a Timer1000 → 24 units A1 producer0x827d14 BC / 5Aseparate protocol path TLV builder0x82ea90 A101 · A102 · A103 new canary retains only A103 old de-load patchesdo not change A104

The strict harness executes the real RXTX dispatcher, timer wrapper, packet builder and checksum. Its captured output makes the distinction visible:

Executed imageTimer unitsQueued packets / callback
Stock 1.00.081000A101 · A102 · A103
Old activated de-load1000A101 · A102 · A103
New raw24 canary24A103

Generated from fw/sim/r12_runtime.py. These are OS timer arguments and queued packets in emulation, not measured radio throughput.

The minimal new candidate changes the two genuine non-acceleration sends and the shared timer immediate. It keeps A103, leaves HID and the sensor configuration alone, bumps the version to 1.00.13, and refreshes the activation metadata.

24 units is not a measured 42 Hz stream. If the timer uses milliseconds, it schedules roughly 41.7 callbacks per second. The sensor reader can still return cached values. Fresh measurements, link stability and power have to be checked on hardware.

The candidate is review-only and generated into a new file on demand. It is not promoted into the one-click firmware catalogue.

A segment display, not a tiny phone.

The image contains the familiar decimal glyph table 3f 06 5b 4f 66 6d 7d 07 7f 6f. Startup copies it into SRAM at 0x2085e5. The renderer selects glyphs for five digit cells and sends an 18-byte frame over UART.

Stock BLE commands C0 and BF reach memory-read and memory-write handlers. The offline test reads the table through C0, changes only its ten bytes through BF, runs the real renderer and restores the original table.

HELLO from the real R12 display encoder, in emulation An offline fixture sets the decimal value to 12345 and remaps those five glyphs. Actual compiled code produces segment bytes 76 79 38 38 3f in an 18-byte UART frame. This is not a photograph or a hardware test. 76 79 38 38 3f OFFLINE FIXTURE / NOT A LIVE DISPLAY CAPTURE
The fixture’s number is 12345, and the corresponding glyphs are remapped to H, E, L, L, O. Repeated decimal digits share a glyph. This is not yet a five-cell independent text API, and it is not a live screen capture.
# Stock C0 read, executed in the offline harness
c03f065b4f666d7d077f6f00000000f4

# Actual UART frame from the HELLO fixture
55aa0301767938383f320315000000000000

The encoder also handles display orientation: it reverses the cells and swaps segment bits. Both orientations are exercised with actual compiled code.

Generic smartwatch commands were the wrong lead: on this build, 0x72 is a no-op and 0x1c music text is rejected. Setting the clock is a write, not a read-only capability probe.

What remains open.

  • One physical C0 read passed. The operator’s 30 October phone report has the exact DIS baseline, one request and the expected checksum-valid glyph table, returned 49 ms after the logged TX. The link then disconnected. Redacted operator receipt ↗. This is not an independently captured trace or full-image attestation; earlier desktop scans stopped at discovery.
  • Visible display control. A reversible glyph-table test has not run on the physical ring. No RAM write or flash was performed during this audit.
  • Fresh high-rate acceleration. Notification counts alone cannot distinguish fresh samples from repeated cached data.
  • Activated-image adoption. Correct metadata and an emulator result do not prove that the R12 loader accepts a candidate.

The former “1344 Hz ODR byte” at file 0x1a8c feeds a 9b diagnostic response. No sensor-register write was demonstrated in that path. An actual register bridge exists elsewhere, but it was not live-tested.

A memory bridge is powerful, not harmless. The BF handler has no visible address-range guard. Arbitrary writes can crash or damage a device. The original read-only helper performs only the narrow, identity-gated C0 read. The separately labelled runtime writer permits BF only inside the ten-byte glyph table, with snapshot and restoration; neither exposes arbitrary addresses.

Reproduce the evidence.

For the next operator-driven experiment, use the reversible LCD glyph writer and bounded accel polling. It preserves counters and exposes the stock digit-indexed limits: leading blanks and repeated-digit conflicts cannot be filled away. Independent five-cell text and fresh sensor Hz are not established. The original read-only test remains at the Web Bluetooth Probes page. It selects the ring afresh, checks exact DIS identity on the same connection, and exposes only the fixed C0 glyph-table read. A successful read does not change the screen or produce a phone notification.

# Offline byte/packet contracts
python3 -m unittest discover -s tests -p test_r12_runtime.py -v

# Strict ARM execution tests; no device contacted
python3 fw/sim/test_r12_runtime.py -v

# Timer, packet and UART evidence as JSON
python3 fw/sim/r12_runtime.py

# Live-helper preview: offline unless --execute is supplied
python3 fw/r12_readonly_canary.py

The harness rejects unknown calls, unmapped access, instruction-budget exhaustion and unbalanced returns. It explicitly models OS and hardware boundaries; it does not emulate the radio, loader, display electronics or physical sensors.