Chinese backdoor

[doriboni]

Hello, I emailed Radtel regarding this vulnerability and they replied:
"The current version has been fixed
https://cdn.shopify.com/s/files/1/0564/8855/8800/files/RT-4D_20250505_Upgrade.zip?v=1746493058"
Could you please update the radio firmware and the DMR chip to versions "V3.16 2025-05-05" and "01.02.00.13" respectively, and check if the vulnerability still exists? Unfortunately, I do not have an SDR or any other means to analyze DMR traffic.
Thank you!

i hope Razorback will test this update...
In any case, if it's fixed, we can say thank you to Radtel, they are very responsive.
Anytone had taken several years to fix the same problem after hundreds of customer requests.

I did some research and maybe in the end this problem of fixed MI is not voluntary on the part of the Chinese.

I found the MI 0x12345678 in an example of the P25 standard.
So it's possible that Motorola provides the same example for the DMRA and that the Chinese are just programming the example without understanding what they're programming.

 

[RaleighGuy]

Unfortunately, I do not have an SDR or any other means to analyze DMR traffic.
Thank you!

If they don't have a way to check the fix, how do they know they fixed it?

 

[doriboni]

If they don't have a way to check the fix, how do they know they fixed it?

I understand that only Fordin can't check the fix, not the Chinese.

Fordin, are you the ones who write this or are they the Chinese :

Unfortunately, I do not have an SDR or any other means to analyze DMR traffic.

because if it's really the Chinese, it's scary about their way of programming and testing

 

[fordin]

I understand that only Fordin can't check the fix, not the Chinese.

Sorry, this is my first time using this forum, and I made some formatting mistakes.

This is Radtel’s reply to my email regarding the vulnerability fix:

The current version has been fixed
https://cdn.shopify.com/s/files/1/0564/8855/8800/files/RT-4D_20250505_Upgrade.zip?v=1746493058

I also mentioned that I don’t have an SDR and was hoping someone on the forum could verify whether the fix actually works.

 

[therealkf]

Looks like we can programmatically check too... I spoke to DualTachyon about this last night on his repo for REing this radio. This was the end result:

The actual DMR firmware is where the flaw resides:
Flawed version <= FM100B_V1.2.0.6_20250311.bin
Fixed version = FM100B_V1.2.0.13_20250430.bin

One more flawed variant also found on the iRadio DM-UV4R version of this radio DM-4R,Two-Way Radios, Rechargeable, 1024 Channel, SMS, 2000mAh, Black-Iradio Electronics Co., Ltd.:
FM100B_V1.2.0.12_20250422.bin

Any visibility into the AES 256 Static IV / MI ? · Issue #59 · DualTachyon/rt-4d-fw-beta

Do you have any visibility into the AES256 vulnerabilities in the RT-4D? That something you can see as part of this RE effort?

github.com

Who actually wrote this DMR stack? Do we know? Do we know the significance of the FM100B prefix on the firmware naming?

 

[therealkf]

On a related note... I was looking into the other radios with this bug, and they seem to often use Auctus A6/A7/A8/A9 chipsets. The of course have their own DMR stack, so I wanted to see the logic that created the flawed static IV's. Finding firmware was a pain, but a random Russian forum had it here: https://4pda.to/forum/index.php?showtopic=1097462 (scroll to bottom)

I've attached the python code to make firmware_bao_dr1801uv_BF1801_DMR_AES256V001.05.lod from firmware_bao_dr1801uv_BF1801_DMR_AES256V001.05.zip (linked above) into a readable format that one could analyze.

Beware the header was pretty stern:

"This software is Auctus AM6102 module standard DMR SDK. <CFS> = 0x00000000A00800000000000000000000.


Auctus Authentication Boot, V0.8, 20221212 Build.


COPYRIGHT (C) 2022 Auctus Technologies Ltd. All rights reserved.


The AMBE+2(TM) voice coding Technology embodied in this product is protected by intellectual property rights including patent rights, copyrights and trade secrets of Digital Voice Systems, Inc. This voice coding Technology is licensed solely for use within this DMR Commu


nications Equipment. The user of this Technology is explicitly prohibited from attempting to extract, remove, decompile, reverse engineer, or disassemble the Object Code, or in any other way convert the Object Code into a human-readable form. U.S. Patent Nos. #8,595,002


, #8,359,197, #8,200,497, #6,912,495 B2, and #6,199,037."

 

[DualTachyon]

Someone came to my GitHub regarding the AES issue, which is fixed in DMR firmware 1.2.0.8 and beyond.

See the following GitHub thread for details:

Any visibility into the AES 256 Static IV / MI ? · Issue #59 · DualTachyon/rt-4d-fw-beta

Do you have any visibility into the AES256 vulnerabilities in the RT-4D? That something you can see as part of this RE effort?

github.com

For that Baofeng, this might be a good start:

40d18: 3c1f1234 lui ra,0x1234
40d1c: 36100002 ori s0,s0,0x2
40d20: 37e45678 ori a0,ra,0x5678
40d24: 7478040c jalx 0x1e01031
40d28: 00000000 nop

 

[therealkf]

Someone came to my GitHub regarding the AES issue, which is fixed in DMR firmware 1.2.0.8 and beyond.

See the following GitHub thread for details:

Any visibility into the AES 256 Static IV / MI ? · Issue #59 · DualTachyon/rt-4d-fw-beta

Do you have any visibility into the AES256 vulnerabilities in the RT-4D? That something you can see as part of this RE effort?

github.com

I'd have tagged you above if I knew you were here! Thanks again for the assistance!

 

[doriboni]

. I was looking into the other radios with this bug, and they seem to often use Auctus A6/A7/A8/A9 chipsets.

Colin said :

by G4EML » Fri May 17, 2024 9:14 am

Retevis doesn't write the firmware for its DMR radios. Most of the low cost Chinese radio companies use firmware written by the same third party company. This company is unknown but we suspect it is connected to the chip manufacturer or government.

About the only Chinese company that seems to write it's own firmware is Anytone.

Colin G4EML

DMR SMS support? - OpenGD77

 

[doriboni]

Someone came to my GitHub regarding the AES issue, which is fixed in DMR firmware 1.2.0.8 and beyond.

Would you have the possibility to check how the PRNG is initialized on the RT-4D when turn on?
Is it with the date and time? or other?
Are there any other resets of the PRNG when the radio is on?

Can you tell if the PRNG was created by the programmer or if the programmer simply used the random() function of his programming language?

Have you found out if the 4 bytes are directly used as IV/MI from the uint32_t GetRandom(void) function or if the uint32_t is modified by another function first?

For my part, I notice that this function reduces the number of starting IVs/MIs by half. According to the Motorola DMRA standard there should be 4 billion different starting IVs/MIs (32 bits), this feature only offers 2 billion (31 bits).

return Result & 0x7FFFFFFF;

Would you have the possibility to modify the function in your beta firmware so that the IV/MI is 32 bits as would be expected?

 

[DualTachyon]

Would you have the possibility to check how the PRNG is initialized on the RT-4D when turn on?
Is it with the date and time? or other?
Are there any other resets of the PRNG when the radio is on?

There is no RTC in this radio. While looking at the IV for Kevin yesterday, I saw that the PRNG function is reseeded "here and there". I don't know the exact conditions because I haven't done much RE to the DMR firmware, but it is not a run-once-and-forget PRNG. It is initially seeded by some function that has the string "TZ" as a parameter, so I suspect it is trying to do the right thing (TZ) by getting the time, but there is no time on this radio.

Can you tell if the PRNG was created by the programmer or if the programmer simply used the random() function of his programming language?

I can't tell one way or the other, but it seems to be based on a known PRNG algorithm.

Have you found out if the 4 bytes are directly used as IV/MI from the uint32_t GetRandom(void) function or if the uint32_t is modified by another function first?

I have not gone that far. The firmware structure is based on queues of messages and it is bouncing buffers around left and right in the queues, it is not trivial to trace. One of the queues has a switch case with > 40-50 cases, and half of those end up bouncing the message data to another queue.

For my part, I notice that this function reduces the number of starting IVs/MIs by half. According to the Motorola DMRA standard there should be 4 billion different starting IVs/MIs (32 bits), this feature only offers 2 billion (31 bits).

Would you have the possibility to modify the function in your beta firmware so that the IV/MI is 32 bits as would be expected?

That's not possible. The beta firmware I wrote is for the main MCU. That's where most things not DMR are running. DMR is a separate chip and communications run over a UART. The MCU sends a small packet "call TG91" over the UART and the DMR responds "sure!". It's very high level. The DMR chip runs its own RTOS, and this is the chip that is secure boot enabled. A friend of mine had his DMR chip bricked (would not respond to recovery commands anymore) with a failed firmware update, so that's why I have been unwilling to probe the chip.

Basically, the DMR chip is a black box and there's little I can do from the main firmware point of view. I attached a screenshot of a sample command. The submit function is just simple loop to send the buffer over the UART and wait for a response + timeout checks.

Worthy of note, the DMR chip is not a "DMR" chip. It is random MCU that does SDR for reception and transmission. PWM is used for modulate the analogue signal that goes into the BK4819 RF chip, and ADC is used to get the analogue signal. There are mentions to multiple opensource components, one of which is WebRTC that handles the voice codec. To me, it looks like a 99% software-DMR implementation.

 

[DualTachyon]

After some tracing, I found the general location of where the 4 bytes are used.

The following function seems to be encoding bits into a buffer.

undefined4 FUN_0003a8f8(astruct *param_1,byte *param_2,undefined4 *param_3) { uint Ofs; undefined4 Ofs_; int Ofs__; Ofs = bitstream_set_X(param_2,0,param_1->field0_0x0,0x10); Ofs_ = bitstream_set_X(param_2,Ofs,param_1->field1_0x2,0x10); Ofs_ = bitstream_set_X(param_2,Ofs_,param_1->field2_0x4,0x10); Ofs_ = bitstream_set_X(param_2,Ofs_,param_1->field3_0x6,0x10); Ofs_ = bitstream_set_X(param_2,Ofs_,param_1->field4_0x8,0x10); Ofs__ = bitstream_set_Y(param_2,Ofs_,(uint)(byte)param_1->field5_0xa,1); Ofs_ = bitstream_set_Y(param_2,Ofs__ + 1,(uint)(byte)param_1->field7_0xc,6); Ofs_ = bitstream_set_Y(param_2,Ofs_,(uint)(byte)param_1->field8_0xd,8); Ofs_ = bitstream_set_Y(param_2,Ofs_,(uint)(byte)param_1->field9_0xe,1); Ofs__ = bitstream_set_Y(param_2,Ofs_,(uint)(byte)param_1->field10_0xf,1); Ofs_ = bitstream_set_Y(param_2,Ofs__ + 2,(uint)(byte)param_1->field11_0x10,1); Ofs_ = bitstream_set_Y(param_2,Ofs_,(uint)(byte)param_1->field12_0x11,1); Ofs_ = bitstream_set_Y(param_2,Ofs_,(uint)(byte)param_1->field13_0x12,2); Ofs_ = bitstream_set_Z(param_2,Ofs_,param_1->field15_0x14,0x18); Ofs_ = bitstream_set_Z(param_2,Ofs_,param_1->field16_0x18,0x18); Ofs__ = bitstream_set_Y(param_2,Ofs_,(uint)(byte)param_1->field17_0x1c,8); Ofs__ = bitstream_set_Y(param_2,Ofs__ + 2,(uint)(byte)param_1->field19_0x1e,1); Ofs_ = bitstream_set_Y(param_2,Ofs__ + 2,(uint)(byte)param_1->field21_0x20,3); Ofs_ = bitstream_set_Y(param_2,Ofs_,(uint)(byte)param_1->field22_0x21,8); Ofs_ = bitstream_set_Y(param_2,Ofs_,(uint)(byte)param_1->field23_0x22,8); Ofs_ = bitstream_set_Z(param_2,Ofs_,param_1->IV?,0x20); Ofs_ = bitstream_set_Z(param_2,Ofs_,param_1->field26_0x28,0x18); Ofs_ = bitstream_set_X(param_2,Ofs_,param_1->field27_0x2c,0x10); *param_3 = Ofs_; return 1; }

The integer as the last parameter seems to be the number of bits. You can see in the 3rd-from-last function call, it is passing the 4 bytes IV and 0x20 = 32 bits.

Param_2 is the output buffer and this is yet again posted into another queue for processing.

 

[DualTachyon]

I found a link on GitHub with the codec source code: webrtc/modules/audio_processing/legacy_ns/nsx_core.c at 7abfc990c00ab35090fff285fcf635d1d7892433 · HackWebRTC/webrtc

The firmware includes that function name and a few others.

 

[doriboni]

Thank you for all this information regarding the IV/MI.

Worthy of note, the DMR chip is not a "DMR" chip. It is random MCU that does SDR for reception and transmission. PWM is used for modulate the analogue signal that goes into the BK4819 RF chip, and ADC is used to get the analogue signal. There are mentions to multiple opensource components, one of which is WebRTC that handles the voice codec. To me, it looks like a 99% software-DMR implementation.

Does this mean that if you could manage to modify the DMR software, you could create any mode with this radio? dPMR, NXDN, P25, ProVoice...?

 

[DualTachyon]

I believe so. It was my secondary intention with this radio to at some point demodulate POCSAG, since I get a constant stream of such messages here.

I have also figured out a path where the RF input/output can also be routed with some tweaks to a MCU pin that can do both ADC and DAC. The MCU runs at 96MHz, theoretically can run at 150MHz and is a Cortex M4F with the nice floating point instructions set. If the DMR could be unlocked and exploited, wonderful things are theoretically possible. The DMR chip has on-chip flash of 2MB (with partitions and a simple filesystem), 256KB of SRAM and is a proper ARM instruction set CPU, not an M class.

 

[doriboni]

The DMR chip has on-chip flash of 2MB (with partitions and a simple filesystem), 256KB of SRAM and is a proper ARM instruction set CPU, not an M class.

and the MCU chip, what are its specifications?

 

[DualTachyon]

and the MCU chip, what are its specifications?

It's an Arterytek AT32F423 for which plenty of documentation, SDK and tools are available. The link below has all of it. The one on the RT-4D has the full internal flash and SRAM possible: 256KB and 48KB.

雅特力科技 Artery :: Usher in a new era of 32-bit microcontrollers

Artery Technology Company, specializing in ARM® Cortex®-M4 MCU, is committed to take the lead in the 32-bit MCU industry with the support of high-end R&D technology, comprehensive silicon IP and professional integration experience.

www.arterychip.com

 

[doriboni]

The one on the RT-4D has the full internal flash and SRAM possible: 256KB and 48KB.

Would it be possible to recreate DMR mode in the MCU by making DMR function calls to the DMR chip, which would allow you to add new features ?

 

[DualTachyon]

Would it be possible to recreate DMR mode in the MCU by making DMR function calls to the DMR chip, which would allow you to add new features ?

The MCU already controls the DMR chip via the UART protocol, but this is high level. The MCU controls the DMR in terms calls and notifications, but the DMR chip does all the processing. For comparison, the DMR firmware is around 1.5MB in size. The MCU firmware is ~ 200KB, and just over 1/3 of that is just data tables (e.g. UTF16<>Chinese conversion table is 64KB alone).

Sample from my code:

DMR_CMD_WakeUp(); if (gUpdateDmrSettings) { gUpdateDmrSettings = false; DMR_CMD_SetRxVolume(gSettings.DmrSpeakerGain); DMR_CMD_SetMicGain(gSettings.DmrMicGain); DMR_CMD_SetRxSquelchLevel(gSettings.DmrSquelchLevel); DMR_CMD_SetSmsType(gSettings.DmrSmsFormat); DMR_CMD_SendDtmf(gSettings.bDmrSendDtmf ? 0x01 : 0x00); } if (pChannel->Modulation == 1) { DMR_CMD_SetLocalId(pChannel->D.CustomId); } else { DMR_CMD_SetLocalId(gSettings.DmrId); } DMR_CMD_SetChannel(pChannel); DMR_CMD_SetChannelKey(pChannel->D.Encryption); DMR_CMD_DigitalMonitor(true, pChannel->D.Promiscuous); DMR_CMD_SetPowerSavingMode(0);

The DMR_CMD_* calls are wrappers to the UART protocol. There are no commands get lower level / raw access to the DMR data stream I would love to decode Tier 3 commands on the 4D (what I was hoping I could do before buying the radio).

 

[doriboni]

While looking at the IV for Kevin yesterday, I saw that the PRNG function is reseeded "here and there". I don't know the exact conditions because I haven't done much RE to the DMR firmware, but it is not a run-once-and-forget PRNG. It is initially seeded by some function that has the string "TZ" as a parameter, so I suspect it is trying to do the right thing (TZ) by getting the time, but there is no time on this radio.

So it would still be the same value of initialization of the PRNG when the rt-4D is turned on? Do you have the possibility to find this initialization value of the PRNG?