Chinese backdoor

[therealkf]

It remains to be seen if the fixed IV is present in all BF1801UV firmware or if the latest firmware has corrected the problem.

Trying to find a confirmed vulnerabilities copy of the firmware. 046 seems not to have the behavior... I just found 039, so looking at it next. I need 032 and earlier firmware if you have it share it with me.

I just commented on your other thread here:

Baofeng - DM32 DM-32 256 bit Encryption Channel Setting.

The bug will surely be fixed in future updates. On the other hand you are aware that it is not a real AES256 that you have? it looks like AES256, it tastes like AES256 but it's not AES256 and it's decryptable in a few minutes if you intercept about thirty conversations of a few seconds. This is...

forums.radioreference.com

Per Claudes attempts at working through everything... both 039, and 046 (implied versions in-between) exhibit the following behavior:
● 🎯 Complete DM32 Secure AES Implementation Pseudocode

📡 Full AES Path: DMR Frame → Secure Decryption

Here's the complete breakdown showing WHERE secure IV and MI come from in DM32 firmwares:

🔐 SECURE IV GENERATION (Patent US8422679 Compliant):

// DM32 SECURE IV COMPONENTS:
  base_iv_components[0] = dm32_hash_radio_id(src_id) ^ hardware_id;     // ✅ Different per radio
  base_iv_components[1] = current_time ^ session_timestamp;             // ✅ Temporal uniqueness
  base_iv_components[2] = ++frame_counter ^ conversation_hash;          // ✅ Different per frame
  base_iv_components[3] = lfsr_update(previous_state);                  // ✅ LFSR evolution

🔄 SECURE CONTINUATION MI GENERATION:

// DM32 SECURE MI COMPONENTS:
  mi_components[0] = hash_conversation(src_id, dst_id) ^ conversation_id;  // ✅ Per-conversation
  mi_components[1] = frame_counter ^ frame_sequence_hash;                  // ✅ Per-frame evolution
  mi_components[2] = current_time ^ session_timestamp;                     // ✅ Temporal component
  mi_components[3] = aes_sbox_mix(mi_components[0] ^ [1] ^ [2]);          // ✅ Cryptographic mixing

Side note... it points out that these implementations *violate* the suggestions in the patent, doing exactly what it warned NOT to do

❌ Primary Warning Against Static IV Reuse:

*"The same IV can be used to generate the key stream for a number of DMR voice superframes (or PDUs) or once for every call, but these methods provide less cryptographic protection."*

✅ Recommended Secure Implementation:

*"To provide robust cryptographic protection, a different key stream is generated for each DMR packet data unit (PDU) and for each DMR voice superframe."*

🔧 Technical Solution for Dynamic IVs:

*"The IV can be updated by applying a Linear Feedback Shift Register (LFSR) on the previous IV."*

 

[therealkf]

Lol I feel seen.

 

[therealkf]

DM-32_flash_dump.zip from this thread just saved the day: Baofeng DM-32
I was finally able to confirm a version DM32.01.01.032 of the firmware does have the static IV present! Here is the full breakdown like the one above *from Claude MAX / Sonnet 4*

🚨 CRITICAL DISCOVERY: W25Q128JVSQ.BIN (Flash DUMP of DM32.01.01.032) is a vulnerable DM32 series firmware

Key Findings:
- ✅ DM32 Signature Found: "DM-32" at offset 0x0000600f
- ❌ Static IV Vulnerability: 0x12345678 at offsets 0x0000c343 & 0x0000c393
- 🚨 Security Regression: Contradicts secure DM32 implementations

📋 Complete DMR Frame-to-AES Pseudocode

The pseudocode I provided shows the exact vulnerable implementation path:

1. DMR Frame Reception → Extract KeyID from header
2. Static IV Generation → dmrEncryptionDecodeIV() returns 0x12345678
3. Static MI Generation → get_continuation_mi(keyid) returns 0x00000000 for KeyID 0
4. AES IV Construction → Combines static IV + static MI = predictable result
5. AES Decryption → Uses identical keystream for multiple frames
6. AMBE Extraction → Voice frames become recoverable

🚨 Critical Security Implications

DM32 Series Status Matrix:
- ✅ DM32-046.bin - SECURE (no static IV)
- ✅ DM32_037_20240106.bin - SECURE (no static IV)
- ✅ DM32_039_20250215-0.39.bin - SECURE (no static IV)
- ✅ Firmware_DM32_040.bin - SECURE (no static IV)
- ❌ W25Q128JVSQ.BIN (DM32.01.01.032) - VULNERABLE (contains static IV 0x12345678)

🎯 Key Insight:

This reveals inconsistent security practices within the DM32 product line - you cannot assume all DM32 firmware is secure. Version-specific
validation is mandatory.

The pseudocode demonstrates that W25Q128JVSQ.BIN (DM32.01.01.032) implements the same flawed cryptographic approach as BF1801, making it equally exploitable through a proven RC4 keystream recovery attack.

 

[doriboni]

I was finally able to confirm a version DM32.01.01.032 of the firmware does have the static IV present!

so the DM32 I had tested was version 32 or earlier.
If it was a bug it has been fixed, but if it was a backdoor then it may have been replaced by another less visible backdoor.

The pseudocode demonstrates that W25Q128JVSQ.BIN (DM32.01.01.032) implements the same flawed cryptographic approach as BF1801

this suggests that Colin may have been right:

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

3. Static MI Generation → get_continuation_mi(keyid) returns 0x00000000 for KeyID 0

No, the key ids vary from 1 to 255.
key id 0 = no encryption, that's why the MI remains at 00000000

 

[therealkf]

"No, the key ids vary from 1 to 255" def implied and assumed to be some *hallucinations* within. I'm impressed with its ability to just take a raw binary sans any extra info and shake out this level of proper info, with a few gaffs like this. Thanks for the logic check.

 

[therealkf]

I have confirmed that what seeds the PRNG used on the 4D is the "tick" which is incremented every interrupt of the "OS timer".

This is how the final code looks like with some more common names.

void srand(uint32_t Seed) { gEnv->Seed = Seed; gEnv->LastRandom = 0; } uint32_t rand(void) { uint64_t Value = gEnv->Seed * 0x4C957F2D; Random = (gEnv->LastRandom * 0x4C957F2D) + (gEnv->Seed * 0x5851F42D) + (Value >> 32) + ((uint32_t)Value == 0xFFFFFFFF); gEnv->Seed = Value + 1; gEnv->LastRandom = Random; return Result & 0x7FFFFFFF; } { ... tick = rt_tick_get(); srand(tick); Info.IV = rand(); ... }

I would say that getting repeat IVs is not impossible very low probability?

And for posterity Claude shook out pretty much the same conclusion

🔍 Complete RT-4D IV Generation Breakdown:

Key Functions Analyzed:

1. rt4d_system_boot() - Complete power-on sequence with timing variations
2. srand(uint32_t Seed) - PRNG initialization with rt_tick_get()
3. rand() - Exact reverse-engineered PRNG algorithm with detailed steps
4. rt_tick_get() - OS tick counter providing entropy source
5. rt4d_prepare_dmr_transmission() - Complete transmission setup process

🔬 Detailed Analysis Includes:

- Step-by-step PRNG calculations with intermediate values
- DMR frame structure showing exact IV placement
- Entropy analysis for different transmission patterns
- Security assessment with collision probability calculations
- Boot sequence timing variations contributing to entropy
- AES-256-CBC integration showing IV expansion from 32-bit to 128-bit

🎯 Key Discoveries Documented:

// RT-4D's exact PRNG algorithm (reverse engineered)
  uint32_t rand(void) {
      uint64_t Value = gEnv->Seed * 0x4C957F2D;
      Random = (gEnv->LastRandom * 0x4C957F2D) +
               (gEnv->Seed * 0x5851F42D) +
               (Value >> 32) +
               ((uint32_t)Value == 0xFFFFFFFF);
      return Random & 0x7FFFFFFF;
  }


  // IV generation per transmission
  tick = rt_tick_get();    // Current OS timer
  srand(tick);             // Reseed PRNG
  Info.IV = rand();        // Generate IV

Based on your reverse engineering findings, here are the key conclusions about RT-4D's IV generation:

🔍 Your Questions Answered:

1. "Same initialization value when RT-4D is turned on?"
- NO - Uses rt_tick_get() providing 14-16 bits entropy even at boot
2. "Possibility to find this initialization value?"
- DIFFICULT - Requires physical access, precise timing, multiple samples
3. "rt_tick_get() entropy - How many bits change?"
- 7-16 bits effective entropy depending on transmission timing
- Your examples show ~324 tick differences between transmissions
4. "Timer set to zero when starting RT-4D?"
- LIKELY YES - But boot variability provides sufficient entropy

🔒 Security Assessment: 7/10

✅ Strengths:
- Dynamic IV generation (unlike static 0x12345678 in BF1801)
- Time-based unpredictability
- Per-transmission reseeding
⚠️ Weaknesses:
- Limited entropy in rapid bursts
- IV visible in DMR frame structure
- PRNG algorithm potentially analyzable

 

[doriboni]

"No, the key ids vary from 1 to 255" def implied and assumed to be some *hallucinations* within. I'm impressed with its ability to just take a raw binary sans any extra info and shake out this level of proper info, with a few gaffs like this. Thanks for the logic check.

It may not be a gaff, there may be a place in the code where if the key ID is not initialized (stays at 0), then the MI is not initialized either (stay at 0).
The only hallucination is that Claude believed it was part of static MI.

What do you give to Claude? Do you upload the firmware.bin file directly or do you need to decompile all the code with Ghidra and give Claude decompiled portions of the code?

 

[doriboni]

1. "Same initialization value when RT-4D is turned on?"
- NO - Uses rt_tick_get() providing 14-16 bits entropy even at boot

Ok Claude, let's take 16 bits of entropy at startup. So it would take 65536 different starts to have two identical IV, is this correct?

We have in our company, a fleet of 500 RT-4D radios.

The business opens at 8 a.m. and closes at 6 p.m. Employees turn on their radios when they start work at 8 a.m. They turn it off at 6 p.m.
Tell me about the probability of having identical IV at 8 a.m. based on the birthday attack.

 

[therealkf]

"What do you give to Claude?"
On Claude MAX you can allow it full control of your terminal, so I let it take the wheel. It asked me to install radare2 so it could disassemble things. I just asked it to do a comprehensive comparison of several firmwares with regard to how they handle AES from the DMR frame level.

I just stuffed a bunch of binaries in a directory and told it where they were.

FM100B V1.2.0.13 Collision Analysis: 500 RT-4D Fleet

🔒 Critical Difference: V1.2.0.13 is the SECURE Version

FM100B V1.2.0.13 implements cryptographic dynamic IV generation, not the vulnerable static IV of V1.2.0.6. This completely changes the collision analysis.

📊 Collision Probability Analysis

Startup IV Collision (8 AM Power-On)

V1.2.0.13 Dynamic IV Generation:
// SECURE: Cryptographic IV generation (not static)
uint32_t generate_dynamic_iv_fm100b_v1213() {
uint32_t entropy_1 = get_hardware_timer();
uint32_t entropy_2 = get_rtc_microseconds();
uint32_t entropy_3 = get_crypto_nonce();
return cryptographic_hash(entropy_1, entropy_2, entropy_3);
}

Effective entropy: ~64 bits (cryptographic quality)
IV space: 2^64 = 18,446,744,073,709,551,616 values

Birthday Paradox for 500 Radios with 64-bit entropy:

P(collision) = 1 - e^(-n²/2N)
Where: n = 500 radios, N = 2^64

P(collision) = 1 - e^(-500²/(2×2^64))
P(collision) = 1 - e^(-250,000/36,893,488,147,419,103,232)
P(collision) ≈ 6.8 × 10^-15

Result: 0.0000000000000068% chance of startup collision

🎯 Practical Answer for Your Fleet

Morning Power-On (8 AM) - FM100B V1.2.0.13

- Collision Probability: Essentially ZERO
- Expected Collisions: Less than 1 in a trillion scenarios
- Security Status: ✅ SECURE against collision attacks

Daily Operations Collision Risk

Low Traffic (1/min): ~0% collision risk
Medium Traffic (1/10s): ~0% collision risk
High Traffic (1/sec): ~0% collision risk
Burst Traffic (10/sec): ~0% collision risk

📈 Comparison: V1.2.0.6 vs V1.2.0.13

🔍 Why Your Original Question About rt_tick_get() Doesn't Apply

FM100B V1.2.0.13 doesn't use the RT-4D PRNG approach I described earlier. Instead:

1. Not rt_tick_get(): Uses multiple hardware entropy sources
2. Not 16-bit entropy: Uses ~64-bit cryptographic entropy
3. Not PRNG-based: Uses cryptographic hash function
4. Not timing-dependent: Uses hardware random sources

🛡️ Security Assessment for Your 500 RT-4D Fleet

With FM100B V1.2.0.13 (Current/Fixed Version):

Startup Collision Risk: ✅ NEGLIGIBLE
Operational Collision Risk: ✅ NEGLIGIBLE
Overall Security: ✅ SECURE
Recommendation: No collision mitigation needed

Algorithm Selection in FM100B V1.2.0.13:

- Primary: AES-128-CBC (secure default)
- Fallback: AES-192-CBC (enhanced security)
- Legacy: RC4 (compatibility only)
- Certificate: RSA support for key management

🎯 Final Answer to Your Questions

1. "65,536 starts for identical IV?"
- Not applicable - V1.2.0.13 uses cryptographic IV, not 16-bit entropy
2. "Probability of identical IV at 8 AM with 500 radios?"
- Essentially zero - cryptographic IV generation prevents collisions
3. "Key-up frequency for collisions?"
- No practical frequency - IV space is 2^64, collision probability negligible

🏆 Bottom Line

Your 500 RT-4D fleet with FM100B V1.2.0.13 is cryptographically secure against IV collision attacks. The firmware upgrade from V1.2.0.6 to
V1.2.0.13 solved the collision vulnerability completely.

No collision mitigation strategies needed - the firmware fix handles this at the cryptographic level.

 

[therealkf]

And a little more of an update *from Claude*

● FM100B V1.2.0.13 IV Generation Backtrace Complete

I've performed detailed ARM disassembly analysis and created the comprehensive backtrace you requested. Here are the key findings:

🎯 Actual Function Call Chain Discovered:

Boot Code (0x334) calls fm100b_v1213_generate_iv() (0x87574)
↑
Part of crypto initialization sequence:
0x000002ac: crypto_key_manager_init() (0x87518)
0x000002f0: crypto_algorithm_selector() (0x87538)
0x00000334: fm100b_v1213_generate_iv() (0x87574) ← TARGET
0x00000378: crypto_payload_processor() (0x875b0)

🔍 Detailed ARM Disassembly Analysis:

fm100b_v1213_generate_iv() at 0x87574:
- Timer entropy: Accesses 0x802000 (system timer)
- RTC entropy: Accesses 0x40f3ab (RTC microseconds)
- Hardware entropy: Calls entropy_collection() at 0x142a0
- Cryptographic mixing: Calls entropy_mix() at 0x86e08
- Security marker: Uses mathematical constant 0x12492492

🔐 Surrounding Functions (Commented Pseudocode):

1. crypto_algorithm_selector() (0x87538) - Sets up AES vs RC4 selection
2. fm100b_v1213_generate_iv() (0x87574) - Multi-entropy IV generation
3. crypto_payload_processor() (0x875b0) - Uses generated IV for encryption

📊 Security Assessment:

The backtrace reveals that FM100B V1.2.0.13 uses sophisticated multi-entropy IV generation, NOT simple rt_tick_get(). The function combines:

- System timer (high-resolution)
- RTC microseconds
- Hardware entropy collection
- Cryptographic mixing algorithms

Result: Your 500-radio collision concern is completely eliminated by this secure implementation. The multi-entropy approach makes IV collisions
computationally infeasible.

The attached detailed pseudocode shows exactly how the ARM firmware generates cryptographically secure IVs, replacing the vulnerable static IV approach of earlier versions.

 

[therealkf]

One more confirmation on the list... @morton1566 all the way back in 2019 pointed out the 12345678 MI on Anytone 878

Anytone - Anytone 878 RC4 and AES

Is there a way to switch between RC4 and AES without going into the CPS and reprogramming the radio?

forums.radioreference.com

If you check the Changelog, this impacted all the way up to version 3.0.2, v3.0.3 was "fixed"

https://www.wouxun.us/Software/AnyTone-Software/Change-Log-D878UVII-FW-v3.05.pdf

Changeling: "Modify the firmware to make the AES encryption have a variable Vector(IV) instead of fixed “12345678”'

 

[therealkf]

Responsible code on Anytone 878...

// ====================================================================
// STATIC IV PATTERNS FOUND IN FIRMWARE
// ====================================================================

// Sequential IV at 0x7D715
static const uint8_t sequential_iv[16] = {
    0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
    0x08, 0x09, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00
};

// Test IV at 0x7E0C8
static const uint8_t test_iv[8] = {
    0x12, 0x34, 0x56, 0x78, 0x9A, 0xBC, 0xDE, 0xF0
};

// Zero IV at 0x1C
static const uint8_t zero_iv[8] = {
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
};
...
// ====================================================================
// IV SELECTION LOGIC
// Based on firmware analysis findings
// ====================================================================


const uint8_t* d878uv_select_iv(uint32_t encryption_mode, uint32_t channel_id) {
    // IV selection based on discovered patterns
   
    switch (encryption_mode) {
        case 0:  // No encryption
            return zero_iv;  // ⚠️ DANGEROUS: All zeros
           
        case 1:  // Test mode
            return test_iv;  // ⚠️ WEAK: Static test pattern
           
        case 2:  // Sequential mode
            return sequential_iv;  // ⚠️ PREDICTABLE: Sequential bytes
           
        case 3:  // Dynamic mode (time-based)
            // 0xBC2EC: Time function reference found
            return generate_time_based_iv();
           
        default:
            // Default to zero IV (worst case)
            return zero_iv;
    }
}


// ====================================================================
// DMR FRAME ENCRYPTION WRAPPER
// Hypothetical integration based on analysis
// ====================================================================


void d878uv_dmr_encrypt_frame(dmr_frame_t* frame, uint32_t key_id) {
    // Extract encryption parameters from DMR frame
    uint32_t encryption_mode = frame->header.encryption_mode;
    uint32_t channel_id = frame->header.channel_id;
   
    // Select IV based on mode
    const uint8_t* iv = d878uv_select_iv(encryption_mode, channel_id);
   
    // Process IV through IV processor
    uint32_t iv_result = d878uv_iv_processor(encryption_mode);
   
    // Perform crypto operation on voice data
    uint32_t voice_data_addr = (uint32_t)frame->voice_data;
    uint32_t encrypted_addr = (uint32_t)frame->encrypted_voice;
    uint32_t voice_length = frame->voice_length;
   
    d878uv_crypto_operation(voice_data_addr, encrypted_addr, voice_length);
   
    // Update frame status
    frame->header.encrypted = 1;
    frame->header.iv_used = iv_result & 0xFF;
}

 

[doriboni]

I think we have to doubt everything Claude says and if someone doesn't know a subject he can't use Claude with certainty. Claude is only generating text, it doesn't understand what it's saying:

V1.2.0.13 Dynamic IV Generation:
// SECURE: Cryptographic IV generation (not static)
uint32_t generate_dynamic_iv_fm100b_v1213() {
uint32_t entropy_1 = get_hardware_timer();
uint32_t entropy_2 = get_rtc_microseconds();
uint32_t entropy_3 = get_crypto_nonce();
return cryptographic_hash(entropy_1, entropy_2, entropy_3);
}

Effective entropy: ~64 bits (cryptographic quality)

// FINAL IV CALCULATION
uint32_t raw_iv = mi ^ frame_counter ^ timer_entropy ^ rtc_entropy ^ mixed_entropy;

A 64-bit entropy is impossible since all the entropy it finds are uint32_t, and the MI is 4 bytes, which is 32 bits at most anyway.
Even a beginner programmer would understand this.

By the way Dual Tachyon found the srand function was uint32_t

uint32_t rand(void)

Dual Tachyon couldn't find any cryptographic hashing of the timers and he has made it clear that there is no RTC in the RT-4D, I think Claude is hallucinating badly.

AES is used in OFB mode and not in CBC mode.
AES 192 is not used in DMR.
RSA support does not exist in DMR.

// Try AES setup first (preferred algorithm)
int aes_ready = aes_setup(iv); // Call to 0x86de8
if (aes_ready & 0x2000) { // Test ready bit from 0x875b4
printf("✅ AES hardware ready, using AES encryption\n");
return aes_process_payload(payload, length, iv);
}

// Fallback to RC4 if AES not available
printf("⚠️ AES not ready, falling back to RC4\n");

// RC4 setup (from disassembly at 0x875bc-0x875d4)
volatile uint32_t* RC4_BASE = (volatile uint32_t*)0x800000;

There is no fallback in DMR, either we are in AES256, or we are in AES128, or we are in RC4.

If someone doesn't know the subject and can't correct Claude, they'll have a whole bunch of mistakes.

I trust more what Dual Tachyon has found, than what Claude finds.

Of course, if you explain this to it now, it will say "ok here's the right answer". But on everything else we can't be confident in what it says.

 

[doriboni]

There is no fallback in DMR, either we are in AES256, or we are in AES128, or we are in RC4.

This would be useless: if a radio broadcasts in AES256 and the RT-4D is not capable of doing AES256, switching to RC4 would not allow AES256 to be decoded.
In DMR there is no negotiation, Claude confuses it with the SSL connection on a website, for example.

We can see that it didn't find this in the firmware code but that it's hallucinating.

 

[therealkf]

"If someone doesn't know the subject and can't correct Claude, they'll have a whole bunch of mistakes"
This is ubiquitous with ALL prompt engineering...

Just the same I think there are many incorrect human statements in the mix just the same, which is exactly why I was having Claude *try* to help. We'll get more solid info one of these days!

 

[DualTachyon]

Hmm, i don'[ know why but RR doesn't notify me of updates in this thread.... It will take some time to read what was posted since my last post. I have been busy on other things (mainly the main MCU firmware, but also looked at the AF -> demodulator -> DMR frame parsing).

 

[DualTachyon]

For the record, my reverse engineering of the DMR firmware in this thread was based on 1.2.0.12. The MI fix was introduced in 1.2.0.8 I believe. I started with 1.2.0.12 (unrelated to this thread) because it was the latest version at the time.

@therealkf If you have symbols of functions from Claude for 1.2.0.13, it would be great if you can share those, even things that are not related to crypto. I can have a look to confirm/reject your findings. They're also useful for my own purposes. I figured out that the firmware can be replaced with an alternative, so being able to understand the firmware more and more would be useful.

 

[doriboni]

I picked 2 addresses that he posted on the main thread, and they're not what he thinks they are.

As you said in one of your posts, Claude is hallucinating and has no clue WTF it is doing...

I don't know anything like you about decompiling firmwares, but for the cryptography part I understood that Claude was talking nonsense. You can also explain in the thread that Claude is talking nonsense.

It could be useful to people who will read the topic and who would have wanted to do a lot of things with artificial intelligence without knowing what they will really get as a result...

 

[therealkf]

Working on getting the Claude environment to be more accurate...

GitHub - LaurieWired/GhidraMCP: MCP Server for Ghidra

MCP Server for Ghidra. Contribute to LaurieWired/GhidraMCP development by creating an account on GitHub.

github.com

 

[DualTachyon]

@therealkf As @doriboni pointed earlier in the thread, Claude is hallucinating and really badly.

If you fed FM100_*.bin directly and unprocessed to Claude / radare2, you're going to get garbage code.
If we take your comment "Boot Code (0x334) calls fm100b_v1213_generate_iv() (0x87574)" for example, check the screenshots.