Two containers, different rules.
Standard BlueX
Older R02 and R06 images in this repository begin with 0x12345678. Their application follows a 0x100-byte header. The body length and CRC32 can be checked directly against the stored fields.
Nested Realtek / QRing
RT02R/RT02CR, RY02, RT09, RY03CR, RT03CR and RT11CR images use a QRing wrapper beginning 0x81bdc3e5. The wrapper is 0x50 bytes, followed by a 0x400-byte nested image header. The application payload starts at 0x450.
The activation correction.
The public RT02R/RT02CR work documents three metadata changes for an edited image: clear the nested not_ready bit, refresh the payload SHA-256, then recompute the outer byte sum. Transfer uses app-level DFU init type 4.
| File offset | Field | Activated candidate |
|---|---|---|
| 0x52 | Nested control flags | 0x0981 → 0x0901 |
| 0x1c4 | 32-byte payload field | SHA-256(file[0x450:]) |
| 0x0c | Outer byte sum | sum(file[0x50:]) & 0xffffffff |
Earlier candidates refreshed only the outer sum. Rollback was observed, but that did not prove an unforgeable signature. The old negative hash searches did not establish the correct payload boundary.
Do not overcorrect the conclusion. The stock field does not equal this raw-payload SHA, while the activated public images do. The working recipe on one family is evidence to investigate another—not a guarantee that every loader accepts it.
Nosh118’s byte-level findings ↗ supplied the important external lead. R12 adoption remains a separate hardware question.
Checked against the repository’s bytes.
This table is generated from the actual stock images. The build verifies the appropriate outer checksum and length fields, and checks the nested marker and stock flags where present. It fails if those checks stop matching.
| Stock image | Container | Bytes | Verified at build |
|---|---|---|---|
R02_3.00.06_240523 | Standard | 117,516 | CRC32 + length ✓ |
R06_1.00.06_240921 | Standard | 118,688 | CRC32 + length ✓ |
RT03CR_1.00.02_260319 | Nested Realtek | 137,020 | sum32 + lengths ✓ |
RT09_3.10.21_251107 | Nested Realtek | 137,492 | sum32 + lengths ✓ |
RY02_3.00.38_250403 | Nested Realtek | 118,116 | sum32 + lengths ✓ |
RY03CR_1.00.06_241212 | Nested Realtek | 110,848 | sum32 + lengths ✓ |
RT11CR_1.00.08_250514 | Nested Realtek | 141,268 | sum32 + lengths ✓ |
A green checksum verifies these fields only. It is not a loader, silicon, safety or live-performance test. Raw firmware payloads are not hosted by this site.
Make each test answer one question.
- Identify. Record exact DIS firmware/hardware strings, stock image hash and recovery path. A retail model name is insufficient.
- Trace. Follow the command into the code that builds the observed wire packet. A nearby constant or a plausible source filename is not enough.
- Execute offline. Use explicit boundary models; fail on unknown calls, faults and incomplete runs. Record what the harness observes, not what the hardware might do.
- Distinguish adoption. A reviewed candidate needs a different version string. Stock flashed over stock is not a discriminating test.
- Measure behaviour. Capture packet subtypes, changing samples during motion, uptime and power. More packets alone do not establish a faster sensor.
Physical flashing stays device-specific and explicitly gated. A stock recovery image reduces risk; it does not make arbitrary firmware changes safe.