Analog Way LiveCore

Verdict. Hardware, and not subtly. Layer count is the processing-card count, input count is the input-card count, output count is the output-card count, and the 4K variants use a physically different input card — the per-position plug list changes, which a licence cannot do. The software knows how to be every model in the family from a single encrypted package, and the reported model is even writable over the wire, but only downwards and only within a set the device itself supplies. The interesting structural fact is how little of the machine is in the update file: an x86 PC card with its own BIOS and disk-on-module runs the web interface and the Lua policy layer, and fourteen microcontrollers on the cards do the rest. The control plane recovered since sits entirely on the PC card's side of that split: 1,014 variables, no authentication, and a memory model whose stored contents are addressable field by field — none of which says anything at all about what the processing cards contain.

Method

The vendor update packages are AES-encrypted and were not decrypted. The architecture findings come instead from the vendor's own simulator appliance, whose second disk is an ext4 image of the device filesystem — read without mounting — carrying the platform's variable, enum and dimension model as JSON plus its Lua policy layer. The control-plane findings came later and differently: the Flash client the device serves was lifted out of that same image and decompiled, exercised against a simulated NeXtage 16 booted under QEMU, and then confirmed on a real NeXtage 16 on our LAN on 2026-08-06. No unit was opened and nothing about the cards was measured.

Artifacts examined

• LivecoreUpdate_04_02_77.awp and LivecoreUpdateBIOS_01_02_06.awp — encrypted; statistics only
• aw_simulator.ova — the vendor simulator appliance; disk 2 is an ext4 filesystem containing the device application, the WebRCS tree and resources/Platforms/LiveCore_4_02/
• GENERIC_DIM.json, GENERIC_ENUM.json, GENERIC_VAR.json — the platform's own dimension table, 133 enumerations and 1,014 control variables
• Lua/typedef/awLiveCore.lua — the per-model capability table, in the vendor's own source with French comments intact
• ORX_WebRCS.swf v04.02.03 — the Flash client the device serves to a browser, lifted from the appliance's ext4 image without mounting it. Its Vars_Common::awVar initialiser carries 1,014 control variables in 88 groups, each with its request and answer mnemonics, dimension list and declared range
• A golden capture of real wire bytes — the framing, the asymmetric answer mnemonics, a set and its read-back, the unsolicited push on connect and both error codes — pinned as a regression test rather than described in prose

No manufacturer firmware, binaries or documentation are redistributed here. Artifacts are referenced by name and version only. See the method and legal statement for the basis on which this analysis was performed and the boundaries it observes.

Hardware architecture

Software architecture

Update path & security model

These rows describe how a platform validates a firmware image, because that is a structural fact about its architecture. They are not a vulnerability disclosure and no exploit, bypass or circumvention technique is published here. Licensing and entitlement mechanisms are out of scope throughout — seescope boundaries.

What is programmable

1. 1The control protocol

   1,014 variables with their command mnemonics, access rights, types and ranges are all in the platform's own JSON on the appliance, and the table has since been reconstructed from the client and confirmed on a real NeXtage 16 — framing, identity, the set path, push, errors, the three preset contexts and the memory model. The stock client is a Flash applet served by the device, which is dead technology; a modern replacement controller is the obvious project and needs nothing that is encrypted.

2. 2The Lua policy layer

   Layer validity, output format management and the memory model are Lua on the device filesystem, not compiled code. That is an unusually open seam for a machine of this class — though reaching it on real hardware, rather than in the simulator, was not investigated.

3. 3Nothing in the video path

   The processing is on cards behind a backplane, driven by per-card micros, and every firmware component arrives inside the encrypted package. There is no analysable route to the picture from here.

Traps

Mistakes this analysis actually made, or came close to making. They are recorded because each one produces a plausible-looking wrong answer rather than an obvious failure.

• Reading the model number as inputs and outputs. ASC4806 looks like 48 inputs and 6 outputs; the machine has 12 inputs and 4 outputs, and the digits are 48 total layers and 6 layers per screen. SMX12x4 genuinely is 12 in by 4 out, which makes the wrong reading feel confirmed. Only the capability table settles it.
• Treating the encrypted update package as the end of the road. All three Analog Way packages examined here are AES-encrypted, which reads as a dead end — while the vendor's own simulator, already installed, ships the complete device filesystem unencrypted, including the platform's entire variable model. The locked door had an open one beside it.
• Assuming -4K is a licence because it is presented in the interface as an option slot. It changes which physical connectors are usable on which input position, so it is a different card. An "option" in the vendor's configuration UI is not evidence of a software-only difference.
• Averaging the encrypted package's statistics and stopping at "high entropy". The useful facts were the length being an exact multiple of 16 and the complete absence of repeated 16-byte blocks — which together say block cipher, chained or counter mode, a much more specific claim than "encrypted".
• Reading the appliance's inert control surface as a stubbed simulator. A session created with no options has no cards fitted, so every input reads unavailable, every screen allocates zero layers and nothing responds — which looks exactly like a simulator that models the wire and not the machine. It models both. The session has to be created with the device's own option ids, and the whole control surface then works.
• Treating the selected-layer variable as a show/hide control. It is panel selection only, it does not change on-air state with or without a take, and it is deliberately absent from what a memory stores.

Open questions

• What is actually on a processing card. The card model, the micro and the per-card FPGA or ASIC are all invisible from the appliance — it describes the machine's behaviour, not its silicon. This is the largest gap on the page.
• ORX_5, device 101 — six layers per resource but only two resources, sitting between the Ascender and NeXtage shapes. It is in the enumeration and in the capability table and appears in no catalogue.
• Whether the simulator's CARD_REF numbers are real Analog Way part references or fixtures invented for the appliance.
• The .awp key. It is on the device side; the appliance is a simulator build and does not obviously carry a production copy. Not pursued.
• How much of the appliance's Lua matches what runs on real hardware. The scripts are explicitly simulation-side (simulator_SetVarMatrixValue), so they describe the model faithfully but may not be the production implementation.
• The on-air semantics. A take is a verb on a group index and the per-layer status variables did not move under it, so nothing observed on the wire says what is actually on the programme output. It needs a monitor on the output and a signalled input, neither of which was available remotely.
• How many concurrent control sessions the frame accepts, and whether an idle socket is dropped. AWGateway implies the answer is small; it was never measured, and it decides whether a third-party controller can run alongside the vendor client.
• Whether a set outside a variable's declared range is clamped, rejected or accepted. Every range here is the client's declaration.
• The VIO 4K's own variable table. The same Flash client ships it and the same pipeline extracts it; it has not been built, so the sibling platform named above is still described only by its device descriptor.

Related entries

• Analog Way Midra series — Video presentation switcher
• Analog Way LivePremier / Aquilon — Video presentation switcher
• Blackmagic Design ATEM (switcher family) — Live production video switcher