MD-UV380 / MD-UV390: hosting the AMBE+2 codec

Status: format description, against the reference build (codec-placement.md). The codec of every build below was run in a host instruction set emulator (measured); nothing has run on a radio.

Rule: the radio runs exactly the codec its own TYT firmware shipped. The user's machine extracts it from a firmware file the user supplies. No codec bytes go in this repository or in released binaries.

Stock files

Published by TYT and Retevis and mirrored by dealers. The 19.26 builds are the first supported and the ones described in detail below; every other build has the same shape at its own addresses. Retevis ships TYT's 18.11 and 18.16 files under its own names (RT3S(CSV)-V18.11.bin and so on), byte for byte, and builds of its own for 19.06 and 219.60. Every file, TYT's and Retevis's, is encrypted with the same key (below).

TYT's 19.74 and 219.74 come in 5 W and 10 W ("Plus") builds; the 219.xx line is the AES build with 255 groups. The header carries no model string, so a user must pick the file for their radio; for RadioFoundry any of them is only a codec donor and works on any MD-UV380 family radio, because the codec behaves identically in every build (below).

Container and encryption

The "OutSecurityBin" two-segment form, as for the reference build:

Application lengths: V19.26 0xE0C00, D19.26 0xE3C00, P19.26 0xE3000, S19.26 0xE6000 (every build's: stockfw.py PROFILES, "segments"). The application starts at file offset 0x5D500. The payload is XORed with the MD-UV380 bootloader key (SHA-256 739ce35cc8db6e72f95598effac1a01ae71dbe2a5792c1a69acaee5dbf634991, first bytes 00 AA 89 89, the mduv380 model of tools/stm32_dfu.py):

plain[i] = file[0x100 + i] ^ key[i % 1024]

For an application address A: file offset = A - 0x0800C000 + 0x5D500, key index = (file offset - 0x100) % 1024.

Key recovery (measured). rfoundry/stockfw.derive_key(stock, <the hash above>) recovers the key from each of every file and checks it by that hash: in 0.1 to 5 s per file. No key file is needed.

Decrypted application vector tables of the 19.26 builds: SP 0x20002848 in all four; reset 0x080E8A09 (V19.26), 0x080EB999 (D19.26), 0x080EAE69 (P19.26), 0x080EDE39 (S19.26).

Codec in the vendor images

Code windows (decrypted):

Table windows (decrypted). Every file's is 0x12850 bytes. The codec's own data ends earlier; the merge cuts to it:

First word of every code window: 0x4FF0E92D, as in the reference build. The code-window SHA-256 alone tells the builds apart: no two builds share one.

• Code window (V19.26). Execution covers 0x0807B830..0x0807C872 and 0x0807DD4C..0x0808ACEA; the gap between holds other code that the codec never executes, carried to keep the window contiguous. The window end is the last executed byte.
• Table window (V19.26). The constant tables at the reference table window's layout shifted by +0x72A4 (start) to +0x7340 (most tables), plus one codec code island at 0x080DFF3C..0x080E0024 (the reference build's is at 0x080D8BFC). Starting the window at 0x080D8C98 changes the output. The other three builds have the same shape at the same offsets from their window start.

Entry points and calling convention

All AAPCS, Thumb, the reference build's argument lists and semantics ("Per-frame calls" in its codec page). The offsets from the code start are the reference build's (another hosted family has different ones):

Every other build has the same offsets, except FEC decode: +0xB78 in the CSV and CSV-GPS builds of 18.11, 18.16 and 19.06, +0xB68 in their REC and GPS-REC builds. RadioFoundry never calls FEC decode (the air frame FEC is its own), so one offset table serves every build.

All four columns have been executed (and the other builds' entries, at the same offsets). The init sequence is the hosted builds': encoder init (E, 1, 1), FEC init (each FEC block, 1), decoder init (D, 1), encoder parameters (E, -22, 20, -10, stack: -40, 0x4000, 3276, 3276, 1310, 10, 20), encoder set (E, 128, -20), decoder set (D, 128, -20), one decode of an all-zero frame with flags 8. The sequence is the reference build's, and the output matches it.

State sizes

With every block ending at an unmapped page: encoder state 0x16E0, decoder state 0x7EC, FEC state 0x44 each run without a fault (the sizes of the hosted builds; smaller sizes were not tried). Stack peak 3822 bytes from the entry. No fixed RAM address is touched.

Checks (measured)

In a host emulator (Thumb, Cortex-M4) with only the two windows (or the codec as the merge places it), the state blocks, the I/O buffers and a stack mapped. For a 1 kHz tone (30 frames) and a 300 frame stress run (noise, silence, full scale sweeps, injected bit errors, random frames, flags 8), the codec's air bits and decoded PCM are bit-identical to the reference codec's and to the DM-1701 V02.06 codec's, for every build listed: run from the whole image, from the windows only and from the placed layout (same 300 frame hash). The FEC decode results agree (0 and 4).

Hosting

The merge places the codec like the DM-1701's (codec-placement.md): the tables at their stock address, cut to the codec's own data, the code right after them (word aligned) and the descriptor at 0x080FFF80, the end of sector 11. Where the code doesn't fit between the codec's data and the descriptor (the 219.xx builds, S19.74 and 10 W S19.74, whose tables sit higher), it goes to the start of sector 10 instead, below the tables. The code reaches its tables through absolute addresses, which don't move; the merge rewrites one pointer into the code and the 12 calls from the code kept in the table window back into the code (the codec map, tools/rfoundry/rfoundry/codec_maps/mduv380/).

• The codec lives in sectors 10 and 11 (0x080C0000..0x080FFFFF). The application has sectors 3-9 (0x0800C000..0x080BFFFF), and an update that writes only those keeps the codec ("keep codec" works).
• One codec id for every build, mduv380-1926-s11 (named after the first build supported); the descriptor's tag tells the builds apart: the build letter and version in BCD, 0x40000000 for a 10 W build, 0x80000000 for the AES 255 line. Each build has its own placed addresses, in boards/mduv380/vocoder_mduv380.c:

• The CRCs are CRC-32 (IEEE 802.3) of each part after the rewrites. The descriptor must carry exactly these.
• Every build holds the same codec, bit-identical in behavior to the DM-1701 V02.06's (above).
• Boot check: the descriptor, then the CRC of both parts; otherwise FM only.
• Older releases: the id is the same for every build, but a release accepts only the tags it was built with. Releases before the one that added the other builds' maps accept the four 19.26 tags only. A radio whose codec came from any other build and is flashed with such a release, keeping the codec, finds no codec and is FM only. Going back to it needs the codec merged again from a 19.26 file (codec-placement.md, "One id, many builds").
• Identifying a radio still on TYT firmware: a program flash readout (rfoundry, codec_extract, the web flasher library) hashes the code window with SHA-256 and so knows the build. The application is plain in flash from 0x0800C000, so a readout equals the decrypted application by address.
• Maps exist for every build in the tables above.

Extraction recipe

1. Check the file's SHA-256 against the table above and the two-segment header.
2. Get the key: derive it from the file (above) or a key file checked by its SHA-256.
3. Decrypt the code and table windows (file offset = address - 0x0800C000 + 0x5D500). Check the first word and both SHA-256 values.
4. Place them as the table in Hosting says. The merge happens on the user's machine, never in a release.

Open items

• 19.03 and 19.06 from TYT, the 119.xx line, and REC / GPS-REC builds of Retevis 19.06 and 219.60: named in release notes or expected, no file found.
• On a radio: TX and RX voice through the codec as placed.