1. **The project began as an investigation of an undocumented RCA smart TV platform.** The target is an RCA RNSMU6036 “Virtuoso.” Initially, very little was known about the underlying architecture. Early work concentrated on service menus, boot behaviour, UART output, firmware layout, and obtaining a reliable normal-world shell rather than modifying firmware.
Boot evidence established an older MStar software stack using **MStar U-Boot 2011.06**, **Linux 3.10.40**, **32-bit ARMv7**, and a separate secure environment associated with **NuttX**. Boot configuration also exposed indicators such as `tee_mode=nuttx` and `SECURITY=ON`.
This established very early that the TV contained a distinct trusted-execution architecture rather than being a simple Linux-only appliance.
2. **Privileged normal-world access was established.** UART investigation and the TV's network-accessible raw shell provided a way to inspect the running Linux environment with high privilege.
This changed the project from blind firmware analysis into live examination of the actual MStar userspace, kernel interfaces, modules, libraries, device nodes, memory infrastructure, and TEE client environment.
Private LAN addressing and other operator-specific access information have been omitted from this version.
3. **Preservation became the first hard requirement.** Before substantial experimentation, the project adopted a principle that the original RCA firmware and security state should remain the authoritative baseline.
The entire accessible eMMC user area was acquired read-only:
**3,959,422,976 bytes**
Separate **boot0** and **boot1** regions were also archived and hashed.
Acquisition tooling streamed the image in chunks, retained partial files if interrupted, verified the exact expected byte count before accepting an image, calculated SHA-256 hashes, and refused to overwrite previously acquired images.
4. **The storage architecture was reconstructed.** Partition analysis ultimately produced a **16-partition map**.
Accessible filesystems were extracted and indexed rather than casually modified in place.
Bootloader data, environment material, kernel-related components, configuration partitions, root filesystems, MStar libraries, applications, customer configuration, certificate-related directories, and EEPROM-related data were preserved.
**RPMB remained intentionally untouched.**
5. **The security boundary was formally defined.** The project explicitly ruled out extracting, displaying, copying, transplanting, spoofing, or modifying protected device identity or DRM material.
That includes device-bound Widevine credentials, keyboxes, certificates, private keys, provisioning records, RPMB contents, attestation material, and secure-world identity.
Normal use of the RCA's own device-bound trust through its stock or compatible interfaces remains in scope.
This distinction has governed the secure-world work ever since.
6. **The stock operating system was identified as non-Android.** Investigation showed that the retail RCA environment is not simply a crippled Android build waiting to be enabled.
Its stock userspace is much closer to a proprietary MStar television environment involving components such as TVOS-style applications, DirectFB, Qt, MStar middleware, and other vendor-specific software.
This changed the central problem from:
**restore Android**
to:
**reconstruct an Android-compatible software environment around hardware that appears to support one.**
7. **The hardware family was identified as MStar Macan / MSD6586.** Stock RCA evidence ultimately exposed:
**SoCType: MSD6586** **SoCYear: 2017**
The SoC belongs to MStar's **Macan** family.
An important correction was made during the investigation: identifiers encountered in donor firmware such as **MSD6586-T8E2** describe particular donor board/platform configurations and should not automatically be treated as the RCA's exact board designation.
8. **The native software inventory was mapped.** Early filesystem work indexed approximately **866 RCA ELF binaries/libraries**, including dependency relationships.
This provided a usable map of the native platform rather than relying exclusively on strings searches.
Important MStar subsystems included GOP, GFX, XC, VDEC/VDEC_EX, MVOP, Utopia, MMIO, MPool, mailbox, shared-memory infrastructure, Mali graphics components, TEE clients, and DRM-related libraries.
9. **Donor-firmware archaeology began.** Related MStar Android firmware was collected and normalized so components could be compared structurally with the RCA.
One particularly important donor branch was **KIVI D003 / MS65860-ZC01-01**.
It provided an Android 6-era implementation using many of the same architectural ingredients as the RCA.
10. **The KIVI donor demonstrated how close the platform was to a genuine MStar Android television.** Relevant donor evidence included:
Android framework/runtime components, Linux 3.10.40 lineage, ARMv7, Mali `r6p1-01rel0`, API900 graphics components, `gralloc.macan.so`, `hwcomposer.macan`, `/dev/gflip`, GOP/Utopia, VDEC/VDEC_EX, MVOP, MediaCodec/Stagefright, OEMCrypto, Widevine libraries, and a compatible-looking TEE client architecture.
This provided the first strong technical basis for believing that an Android reconstruction was plausible.
11. **Wholesale donor flashing was rejected.** The similarity of the donor platform initially made a complete donor firmware flash tempting.
Static comparison showed why this was unsafe.
The RCA has its own panel definition, MMAP layout, physical memory configuration, board peripherals, Utopia registrations, provisioning state, boot environment, and trusted-world identity.
Representative RCA libraries included Widevine CDM components, OEMCrypto/CENC components, and `libTEEClient`.
The donor Android architecture followed a very similar pattern through Android's DRM service into OEMCrypto and then the MStar TEE client.
15. **The RCA and donor TEE client interfaces proved extraordinarily close.** Comparative symbol analysis found approximately **29 of 30 relevant TEE-client exports** aligned between the RCA and KIVI-derived environments.
That did not by itself prove binary equivalence.
It did establish that the two systems were speaking versions of essentially the same MStar TEEC architecture.
16. **OEMCrypto API 9 was identified as the appropriate RCA-era interface.** A major distinction had to be maintained between the RCA's **API9** environment and newer donor **API10** implementations.
Several apparently contradictory command/status interpretations were eventually resolved by recognizing that API10 donor semantics could not automatically be applied to the RCA's API9 trusted application.
17. **An Android/Bionic-side OEMCrypto execution environment was assembled.** The goal was to exercise the real RCA hardware through reconstructed normal-world Android-compatible components without replacing its trusted environment.
A physical `_oecc22`-type test succeeded.
This demonstrated that the reconstructed normal-world environment could execute meaningful OEMCrypto-side code on the television.
18. **The first serious physical initialization attempt reached the MStar hardware boundary.** `_oecc01` progressed through a substantial portion of OEMCrypto/platform initialization.
It reached the region associated with:
**`TEEC_GetPAAddr`**
and then terminated with:
**SIGSEGV / exit 139**
This was an important failure.
The reconstructed software had advanced far enough that the main question was no longer basic Android/Bionic loading. The crash occurred where physical addresses, shared memory, or genuine MStar backend state became important.
19. **The physical TV was not repeatedly crash-tested.** Instead of continuing to invoke the failing initialization on hardware, the resulting volatile core was discarded without examining protected material.
The suspect initialization sequence was moved back offline.
This became the standard philosophy for the project:
**physical result → isolate boundary → return offline → understand → only then retest.**
20. **The MStar initialization chain was decomposed.** Analysis isolated a path broadly resembling:
Equivalent donor initialization prefixes ran successfully offline.
This significantly reduced the likelihood that the donor code was simply incompatible as ordinary ARM software.
21. **The first targeted probe package contained a packaging defect and was rejected.** An early shell/probe package had a malformed script condition—the so-called `esacif`-style defect.
It was not treated as experimental evidence.
The package was corrected and regenerated as **v1b**.
22. **v1b introduced the disciplined physical-test workflow.** The corrected package was statically checked, tested offline, hash-locked, and subjected to a readiness gate before physical use.
Physical RCA readiness checks confirmed expected infrastructure such as MStar devices and volatile shared-memory support.
23. **The evidence increasingly pointed toward physical backend divergence rather than software incompatibility.** Because the same initialization path behaved normally offline but failed on the real device, investigation shifted toward physical MStar MMIO, mappings, shared-memory state, Utopia registration, or other backend interactions.
24. **The RCA's native Utopia module set was reconstructed.** Comparison of native `liblinux` registration behaviour with donor initialization revealed a smaller RCA core set.
Important RCA registrations included:
**UTOPIA, BDMA, MBX, MIU, SEM, SYS, UART, CPU**
Donor builds attempted several additional modules.
25. **Optional donor modules were isolated rather than forcing them onto the RCA.** One suspicious path involved **TVENCODER** registration.
V4 testing neutralized optional donor registration paths while retaining the RCA's core platform modules.
This led to an important design principle:
**The objective is not to recreate every donor peripheral. It is to provide the minimal legitimate Macan substrate required by the target software.**
26. **V5/V6 generalized the optional-Utopia reduction.** Additional donor-only or unnecessary registration calls were selectively suppressed.
At one stage approximately **15 optional registrations** were neutralized in the experimental branch.
Synthetic/shared-memory lifecycle tests and offline execution continued to pass.
27. **Physical MStar platform initialization became stable enough to proceed.** Successively bounded physical tests demonstrated operation through important layers including:
This represented a major change from the original `TEEC_GetPAAddr` crash.
28. **TEEC initialization and finalization were proven on the real RCA.** The reconstructed normal-world stack successfully exercised the TV's own TEE client infrastructure.
`TEEC_Initialize`-type setup and teardown operated successfully.
This established that normal-world communication with the genuine RCA trusted environment was practical.
29. **Trusted-application session creation was proven.** Bounded tests demonstrated successful:
**OpenSession** **CloseSession**
behaviour.
At this point the TEE was no longer merely inferred from boot logs or static binaries.
The reconstructed client was opening real trusted-application sessions on the physical RCA.
30. **Generic command invocation was separated from Widevine-specific behaviour.** Conservative command paths were used to determine whether `TEEC_InvokeCommand` and parameter marshalling themselves were functional.
The evidence showed that generic TEE transport was working.
That substantially narrowed subsequent failures to trusted-application state or Widevine/OEMCrypto semantics rather than a broken TEEC ABI.
31. **The real `WVCENC_ta` trusted application was reached.** Analysis mapped the relevant path through code similar to:
Physical testing successfully opened and closed the Widevine-related trusted application.
This “Open/Close Sequence” was one of the project's largest milestones.
32. **The first secure-state discriminator was identified: command 17.** Physical invocation of **cmd17** returned:
**decimal 11 / `0x0B`**
Detailed analysis established that, on the RCA API9 implementation, this represents a distinct:
**`NO_KEYDATA`**
state.
This result became an extremely useful non-destructive predicate for tracking secure-state transitions.
33. **Command 3 was investigated as a possible secure-data handoff.** A physical sequence demonstrated that a command-3-style handoff could return successfully at the transport level.
**command success did not mean secure key data had been accepted or committed.**
34. **Command 5 was reached successfully.** A later physical sequence demonstrated:
**cmd17 → 11** **cmd5 → 0** **cmd17 → 11**
So `cmd5` itself worked and returned success.
But it did not transition the trusted application out of `NO_KEYDATA`.
This eliminated a major hypothesis: command 5 was not the missing provisioning/key-state establishment operation.
35. **The project crossed from transport debugging into semantic debugging.** Once TEEC, WVCENC session establishment, command invocation, and command 5 were all functioning, the central question changed.
The problem was no longer:
**Can reconstructed Android software reach the RCA trusted world?**
It became:
**What legitimate stock sequence establishes the secure state expected by the RCA's OEMCrypto API9 implementation?**
36. **Additional safe physical OEMCrypto lifecycle operations were proven.** Subsequent bounded RCA testing validated further portions of the session lifecycle.
This included successful execution of operations corresponding to:
This further demonstrated that a significant portion of the OEMCrypto/TA state machine is already operational.
37. **The stock CDM path was traced to command 19.** Static and lifecycle analysis linked a CDM token/key-data path to an OEMCrypto operation reaching:
**cmd19**
This was a major architectural discovery.
`cmd19` is now understood as the **first proven hard secure-world dependency in the stock CDM session-initialization path**.
38. **The stock token path was mapped beyond command 19.** Analysis also reconstructed the downstream sequence approximately as:
**cmd19 → cmd9 → cmd10 → cmd11**
in the relevant post-token/session path.
That gives the project a much clearer map of what comes after successful key-data establishment.
39. **Physical command 19 remains deliberately unexecuted.** Although its role is substantially better understood, it has not yet been invoked experimentally against the live RCA.
This is intentional.
The project has been working backward from predicates, normal-world call structure, and donor semantics before crossing a new secure-world boundary unnecessarily.
40. **API10 donors became semantic references, not direct replacements.** Later donor work included **FOXTROT / MacanWVCencV10L1** and related MSD6586/T8E2/Diggio material.
These are useful because their implementations are more visible.
They are nevertheless **API10 reference implementations**, while the target RCA is API9.
The project therefore uses them to infer architecture and data flow, not to assume identical command meanings.
41. **The API10 secure-file path was reverse-engineered.** FOXTROT analysis showed that its command-3 path deals with an authenticated secure-file format rather than simply copying a raw key structure.
The path involves authenticated decoding including **AES-DMA/HMAC-SHA-style processing** before committing a secure object.
The reconstructed canonical API10 payload committed by this path is **128 bytes**.
42. **The API10 secure-file envelope geometry was reconstructed.** For that 128-byte logical WVCENC object, the donor writer emits a **256-byte canonical secure-file container**.
This gave the project a concrete model for the distinction between:
**logical secure object**
and
**authenticated/encrypted storage envelope.**
43. **The RCA's own corresponding file was examined metadata-only.** Without reading its protected contents, the RCA filesystem was queried sufficiently to establish that:
**`KeyBox.bin` is 260 bytes**
on the target.
No content was extracted.
The 260-byte RCA size versus the 256-byte API10 donor envelope is now a significant structural clue.
44. **A donor key-structure validator was mapped.** Separate donor analysis identified a normal-world validator expecting features such as:
**`"kbox"` magic** **a 0x80-byte logical structure** **CRC-32 over 0x7C bytes**
This helped separate ordinary structural validation from cryptographic trusted-world handling.
It was not used to extract or reconstruct the RCA's protected credential material.
45. **`cmd17 = 0x0B` was definitively separated from misleading API10 interpretations.** At one stage, newer-donor status meanings risked being projected onto the RCA.
Further API9 semantic work showed that the RCA's `0x0B` result should be treated specifically as the target's **NO_KEYDATA** state.
This correction matters because it changes how all previous physical tests are interpreted.
46. **An RCA OEMCrypto API9 semantic bridge was constructed.** Recent analysis has focused on translating between:
This has significantly reduced ambiguity around cmd3, cmd5, cmd17, and cmd19.
47. **Donor searching expanded beyond KIVI.** KIVI recovery and `system.ext4` material did not contain the missing secure TA implementation required to settle the API9 state transition directly.
Attention therefore expanded to additional MSD6586-era firmware.
48. **Micromax HLS71 became a particularly interesting donor candidate.** Its complete firmware package potentially contains TEE/NuttX/secure partitions absent from simpler Android system images.
The complication is that the useful payload is packaged inside an encrypted/authenticated upgrade format.
49. **The HLS71 update-container architecture was substantially mapped.** Analysis identified parts of the upgrade verification flow, including RSA-2048 / PKCS#1 / SHA-256 authentication behaviour and CustomerKeyBank-style structures.
The project did **not** bypass the authentication system merely to obtain protected material.
The useful conclusion is architectural: the potentially valuable secure components exist behind a vendor update format that is materially different from an ordinary Android filesystem image.
50. **The live RCA secure partition corresponding to the unresolved area remains untouched.** Investigation deliberately did not dump or alter the relevant live secure partition merely to shortcut donor analysis.
This preserves the integrity of the physical target and maintains the evidentiary value of subsequent tests.
51. **The project developed a formal command-classification workflow.** Instead of interpreting every failure as “DRM doesn't work,” candidate gates are now classified into categories such as:
`cmd17` serves as a useful before/after state predicate in this process.
52. **The difference between QEMU proof and physical proof is now rigorously maintained.** QEMU can prove that normal-world ARM code loads, resolves symbols, constructs data, follows control flow, and reaches the point where it would issue a TEEC operation.
It cannot prove execution inside the RCA's actual NuttX trusted application.
Consequently, logs now distinguish clearly between:
**normal-world/emulated result**
and
**physical RCA secure-world result.**
53. **Some earlier QEMU successes were explicitly reclassified to avoid overclaiming.** For example, tests that loaded CDM or TEE-related code but recorded effectively:
Ordinary test payloads are preferentially staged in volatile storage.
55. **Hash-locking and readiness manifests became standard.** Package contents are frozen and hashed before physical deployment.
Later project work begins with fresh verification against the appropriate readiness manifest rather than assuming that an old package remains unchanged.
This substantially improves reproducibility.
56. **Project logs became authoritative rather than conversational memory.** Durable project-state files, progress logs, command/action logs, audit notes, package manifests, and readiness records were established.
Significant work is synchronized into these records.
The chat ceased being the sole source of truth.
57. **Live monitoring was added.** PowerShell-style progress and status monitoring was developed to expose current phase, progress, and laboratory state.
The monitor itself experienced a quoting/parsing failure involving malformed array/string syntax.
That problem was diagnosed as a monitoring/UI problem rather than a firmware-project failure, and monitor repair became part of normal housekeeping.
58. **The project action history has advanced into the high 300s.** The synchronized work has progressed through at least **Action 376**.
That reflects not 376 irreversible experiments, but a detailed action ledger covering analysis, packaging, validation, audits, QEMU tests, donor comparisons, physical discriminators, synchronization, and cleanup.
59. **The largest completed milestone is now clear.** A reconstructed Android/Bionic/MStar environment can communicate with the RCA's authentic TEE stack and the real Widevine-related trusted application while preserving the television's original device-bound trust.
Specifically, the project has physically demonstrated substantial portions of:
60. **The present blocker has been narrowed dramatically.** The TV is no longer blocked at Android loading.
It is no longer blocked at basic MStar initialization.
It is no longer blocked at `TEEC_GetPAAddr`.
It is no longer blocked at opening a trusted application.
It is no longer blocked at generic command transport.
It is no longer blocked at OEMCrypto `Initialize`.
It is no longer blocked at creating at least the tested secure session state.
The current frontier is the legitimate **secure key-data establishment path** required before the stock CDM can progress through its first proven hard secure-world dependency at **cmd19**.
61. **What remains unproven is equally important.** There is not yet a complete start-to-finish Widevine L1 playback pipeline.
The unresolved chain still includes successfully establishing the expected device-backed key-data state, passing the `cmd19` gate through the stock semantic path, completing the subsequent token/session sequence, performing an actual license exchange, loading content keys through the legitimate interface, decrypting protected media, integrating the protected decoder path, establishing secure video buffers/output, satisfying HDCP/output requirements where applicable, integrating the Android media stack, and validating real protected playback.
62. **No Widevine security level has been falsely claimed.** The presence of a TEE, working OEMCrypto commands, a Widevine TA, or device-bound provisioning infrastructure does not by itself prove successful **Widevine L1 playback**.
That conclusion can only be made once the complete hardware-backed path is demonstrably operating.
The shortest accurate description of the state today is this:
**The project has progressed from an undocumented non-Android RCA television to a functioning reconstructed normal-world Android/OEMCrypto environment that can use the television's genuine MStar TEE, open its genuine Widevine trusted application, execute multiple real OEMCrypto/TA lifecycle commands, and observe genuine trusted-world state without extracting or replacing the television's protected identity. The remaining central problem is understanding and reproducing the legitimate stock API9 transition from `NO_KEYDATA` into the secure state required for `cmd19` and the subsequent protected-media pipeline.**
Firmware donors from the 5844-A9M02B-0P10 now prove vital to clearing what is likely the largest barrier to project success.
Файлы
Прошивки
Продажа
Литература
Статьи
