MD-9600: hosting the AMBE+2 codec

Status: format description and a map and install profile for each of 32 TYT and Retevis original firmware files (03.28 to 26.57, below). The codecs were run in a host instruction set emulator (measured); no MD-9600 has run any of them, the V5 (26.xx) ones included.

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. Any MD-9600 firmware version is the MD-9600's own donor; the codec is board-independent code, so a file for one board revision serves every revision.

These files are also a codec source for another radio: an open-firmware install made from this firmware leaves this codec on that radio. Its tables then move with the code (codecmap.move_window), and the open-firmware backup finds it wherever the install put it (stockfw.from_moved). The radio's own codec page lists the files and placements; codec-placement.md has the shared format.

Stock files

All 32 on hand (the 03.28, 03.29 and 04.03 ones from a dealer's page, the 06.03 ones from a community page that mirrors TYT's update, the RT90 ones from the Retevis firmware download, the others as before): TYT "OutSecurityBin" container, two segments (0x00060000, 0x59800) and (0x0800C000, app length), payload at 0x100, 0x100 trailing bytes (hardware-md9600.md 14.3).

Container and encryption

plain[i] = file[0x100 + i] ^ key[i mod 1024]; the application starts at payload offset 0x59800, so for an application address A: file offset = A - 0x0800C000 + 0x59900, key index = (A - 0x0800C000) mod 1024 (the resource segment is a multiple of 1024 long). Every 26.xx file has the same layout; V26.45's codec code starts at 0x0807537C (checked in the decoded image).

Key: SHA-256 c3d665b297651b52310ec098e87440b147136241359c1154d474e517b048c9ae, first bytes A2 FA BB 4B. The plain column vote (most common cipher byte per key column) gives it on all the files without any refinement; this is what rfoundry/stockfw.derive_key does first. No key file is needed.

Same codec, 32 builds

The codec does not sit at one address: every version and variant links it elsewhere, and the library's object code differs slightly between builds (the head of V06.09 has 0x14 extra bytes at +0x9D2 against V26.45, which moves the FEC decode; literal pools and relocations differ throughout). So no two codec windows are byte-identical: they are different links of the same library, as the reference V02.06 and V26.45 codecs are.

Functionally they are the same codec: with the same init and per-frame calls, all 32 builds and the reference V02.06 codec give bit-identical air bits and decoded PCM (below, "Verification"). The 26.xx (V5) builds use the same entry offsets as the rest, so the calls in boards/md9600/vocoder_md9600.c fit them as they are; only the FEC decode differs (+0xB64 in the 26.45 CSV builds, +0xB54 in the 26.xx REC ones), and the firmware does not call it. The three REC builds 03.28, 03.29 and 04.03 have a code window 0x1000 bytes longer than the others (0x102xx), because the library link puts more of the codec's routines past the entries; their entry offsets are the 06.09 REC build's. Checked on 03.28 by comparing each entry's first 40 bytes with the 06.09 REC build (four entries match in all 40, the other six in at least 35, the difference being literal pool offsets) and on all three by the emulator run; the map tool's carve could not place the decoder set in them, so these three maps take the entry offsets from that comparison.

Entry points

Offsets from the code start C (the first word 0x4FF0E92D, push.w {r4-r11, lr}), . The init order is encoder init, FEC init x2, decoder init, encoder parameters, encoder set, decoder set and one decode; the per-frame calls are encode, encode ECC, FEC decode and decode:

FEC decode: +0xB78 in the CSV and CSV + GPS builds of the 06.xx and 16.xx versions, +0xB68 in their REC and GPS + REC builds, +0xB64 in the 26.45 CSV and CSV + GPS builds, +0xB54 in the 26.xx REC and GPS + REC builds (the 03.28, 03.29 and 04.03 value, +0xB68, is the 06.09 REC build's and was not checked). +0x1C0 is the encoder set (its head differs from the decoder set's only in the BL target).

State: D 0x7EC, E 0x16E0, FEC 0x44 each (guard pages: 0x7E8, 0x16DC and 0x40 fault in decoder init, encoder init and FEC init); stack 3822 bytes peak; no fixed RAM address; no FPU instruction executed. Identical to the reference build. This is RadioFoundry's STM32 vocoder call interface unchanged (platform/stm32f4/codec_call.c and the boards' glue): a board only needs the code base, the FEC decode offset and the window table.

Encode flags: the shared host (platform/stm32f4/hrc/vocoder.c) passes one flags word on every encode call, the same word as on the DM-1701 and MD-380 (drivers/vocoder/ambe2_flags.h, 0x1840 by default; the bits: codec-md380.md, "Encode flags"). On the MD-9600 builds the bits are unverified: the code is the same family, but they were not measured on it.

Codec windows

Two windows per build, cut by execution (below) and checked against the literal targets: the code window from the first word to the end of the last executed instruction and literal pool; the table window from the lowest table literal to the end of the last table (14 bytes at the window's end, the same bytes the reference V02.06 table window ends with; what follows differs between builds). Both hold some vendor bytes the codec never uses. File offset = A - 0x0800C000 + 0x59900; "key phase" = (A - 0x0800C000) mod 1024.

06.09 CSV (79a561ed...), FEC decode +0xB78:

16.45 CSV(V4) (de368437...), FEC decode +0xB78:

Every other build has a map and a profile too:

Executed code in 06.09 CSV: 0x08074B18..0x08083D2A and a code island 0x080B25B8..0x080B26A0 inside the table window (reached by BL from the code window, as in the hosted builds). The code also holds two code pointers, one into each window (0x0807A40D and 0x080B01BD in 06.09 CSV).

Position dependence

As in the hosted builds: calls inside the code are PC-relative, but the code reaches its tables through absolute literals, the table window holds a short code island (executed; reached by BL from the code window), and the code holds absolute code pointers into both windows. So the windows must sit at their vendor addresses. Unlike one hosted family there are no small tables outside the two windows (every literal target lies in them).

Hosting

Decided as the MD-380 (docs/spec/codec-placement.md). The code window starts in sector 7 (0x08074B18 or 0x08075C98), which the application owns (sectors 3-8, boards/md9600/memory.ld), so the merge moves it:

Sector 10 is not used by the application or the code, and the four builds above spill into it, so the codec's flash is sectors 9 to 11 (CODEC_FLASH_LO 0x080A0000 in the firmware profiles); a plan for such a build erases and writes sector 10 as well. The application never links past 0x0809FFFF, so an update erases sectors 3-8 only and keeps the codec. Sector 8 is the application's: every feature switch on needs more than sectors 3-7. One profile per file, one codec id (md9600-s11): the tag in the descriptor says which build the radio holds. The tag is the variant in bits 16-17 (0 CSV, 1 CSV-GPS, 2 REC, 3 GPS-REC) and the version in BCD below, so 0x0609 is 06.09 CSV, 0x1645 is 16.45 CSV and 0x11645 its CSV-GPS build.

The moved codec was run on the host (Cortex-M model) against the stock-address run: the same 60-frame vector (encode and decode, tone plus noise) gives the same air bits and PCM for every build, with the code at 0x080E0000 and the table window's island calls rewritten. The placed CRC-32s are in stockfw.PROFILES and boards/md9600/vocoder_md9600.c and must match.

Supported donors: every file in the first table. 06.09 CSV (V1-V3 boards) and 16.45 CSV (V4) came first and are the default; they are the plain CSV builds (no recorder or GPS code moving the codec). The rest work the same way with their own windows from the table above. An owner of a V5 radio (the TYT 26.45 files, the Retevis RT90 26.38, 26.41 and 26.42 files, or the 26.57 V4A REC build) installs from the file the radio came with: the 26.xx codec calls are the 16.xx ones at the same entry offsets, and the tables of all but the GPS-REC builds fit sector 9; S26.45 and S26.42 run 0x7A6 and 0x6A6 bytes into sector 10. Not covered: the 05.xx files (05.02, 05.04 and 05.05), whose copies on hand are cut off at 1 MiB, short of their tables. A file whose hash is none of the above is refused, not guessed at.

Extraction recipe (06.09 CSV)

1. Check the file's SHA-256 (79a561ed...), its size 1094144, and the segment table (0x00060000, 0x59800), (0x0800C000, 0xB1800).
2. Derive the key (plain column vote) and check it by SHA-256 (c3d665b2...), or use a key file with that hash.
3. Decrypt each window: file offset = A - 0x0800C000 + 0x59900, key index (A - 0x0800C000) mod 1024. Check each window's SHA-256 and the code's first word.
4. Write them unmodified at their vendor addresses after the application image (0xFF between). On the user's machine only (make, tools/codec_extract.py or rfoundry), never in a release.

Verification

The decrypted images were run in a host emulator (Thumb, Cortex-M4 model); the per-run hash covers the 72 air bits and the decoded PCM of every frame.

The other 24 builds (all 32 in all) were run again with the vector set below, each as TYT links it and moved as the merge moves it, with only the moved windows mapped:

This second set has no injected bit errors. A decode of a frame with three injected errors gave different PCM for the 06.09 CSV and the 16.45 CSV builds in a trial run, so the cross-build identity of decoded error frames is not claimed; the placed run is bit-identical to the stock-address run of its own build, which is what the merge needs.

FEC decode results 0 and 4 as in the reference build. The minimal windows were found by bisection: each end was moved until the stress run (60 frames) changed, then the final windows were checked with 300 stress frames with the rest of the mapped pages filled three ways (0x00 and two random patterns); all three give the reference hash, so nothing outside the windows is read.

Open items

• Every file on hand has a map and a profile. The 05.xx files are not on hand in full (above).
• The RT90 files' maps were made against the 06.09 builds (the map tool's reference), not against the 26.45 ones; they carve without outside references and run to the same hash as the rest.
• The 03.28, 03.29 and 04.03 maps take their entry offsets from a comparison with 06.09 REC, and their FEC decode offset was not checked (the firmware does not call it).
• The encode flags (above) are unverified on every build, the V5 ones included.
• The DM-1701's firmware profile list (boards/dm1701/vocoder_dm1701.c) takes the 21 files before 06.03; the seven newer ones are MD-9600 sources only.

Only a radio can check

Audio level and quality through the MD-9600 path, timing at 72 MHz, and that the loader accepts the merged sectors.