DevLabs.cz

Firmware / radio / protocol research

Reverse
engineering
lab notes

DevLabs.cz collects hands-on findings from static analysis, embedded firmware extraction, serial protocol review, and radio tooling experiments.

Read the UV-4R findings
Current focus
iRadio UV-4R
Artifact type
Vendor updater and firmware
Approach
Static-first, reproducible notes

Current research

iRadio UV-4R / DM-UV4R firmware study

We inspected the February 2026 vendor update bundle around the UV-4R family: the radio firmware updater, the slower updater variant, the Unicode/resource loader, the matching CPS, and the separate DMR-side upgrade tool.

Host tools

Small .NET serial utilities

The Windows tools are compact WinForms applications. The observed host-side behavior is local UI plus COM-port I/O; no network activity, persistence, or process-launching behavior was found in the decompiled updater logic.

Firmware image

Embedded Cortex-M payload

The V3.25 image dated 2026-02-05 is embedded as Intel HEX, extracts cleanly, and looks like an ARM Cortex-M application beginning after a bootloader region at 0x08002800. Strings identify a 400-480 MHz build.

Update path

ACK-driven block transfer

The updater streams a fixed padded buffer over serial in 1 KiB payload blocks. The protocol is simple and practical for the vendor bootloader, but the host tool relies on weak checksums, minimal retry logic, and no visible firmware signature verification.

Programming data

CPS and resource compatibility

The matching CPS V2.06 works with a 1 MiB codeplug and the vendor notes warn against reusing old saved files after the update. The Unicode loader writes resource tables so text features keep working after firmware migration.

What we learned at a high level

  • The updater is more of a fixed-image serial flasher than a general firmware manager.
  • The clean firmware extraction can be reproduced from the embedded Intel HEX records.
  • The radio firmware is analyzable with normal Cortex-M tooling once loaded at the right base address.
  • The update ecosystem includes both application firmware, DMR-side firmware, CPS data, and Unicode resources.
  • The security model appears to depend heavily on the device bootloader, not on strong host-side validation.

Lab style

How notes are kept

Reproducible artifacts

Prefer extracted binaries, checksums, decompiler output, and scripts over screenshots or one-off observations.

High-level public summaries

Publish the shape of what was learned while keeping risky operational details out of the landing page.

Embedded context

Track firmware layout, bootloader boundaries, serial behavior, and vendor tooling assumptions together.

.NET decompilation

Short field note on turning vendor WinForms binaries into readable C# projects.

Read article