-
To anyone looking to acquire commercial radio programming software:
Please do not make requests for copies of radio programming software which is sold (or was sold) by the manufacturer for any monetary value. All requests will be deleted and a forum infraction issued. Making a request such as this is attempting to engage in software piracy and this forum cannot be involved or associated with this activity. The same goes for any private transaction via Private Message. Even if you attempt to engage in this activity in PM's we will still enforce the forum rules. Your PM's are not private and the administration has the right to read them if there's a hint to criminal activity.
If you are having trouble legally obtaining software please state so. We do not want any hurt feelings when your vague post is mistaken for a free request. It is YOUR responsibility to properly word your request.
To obtain Motorola software see the Sticky in the Motorola forum.
The various other vendors often permit their dealers to sell the software online (i.e., Kenwood). Please use Google or some other search engine to find a dealer that sells the software. Typically each series or individual radio requires its own software package. Often the Kenwood software is less than $100 so don't be a cheapskate; just purchase it.
For M/A Com/Harris/GE, etc: there are two software packages that program all current and past radios. One package is for conventional programming and the other for trunked programming. The trunked package is in upwards of $2,500. The conventional package is more reasonable though is still several hundred dollars. The benefit is you do not need multiple versions for each radio (unlike Motorola).
This is a large and very visible forum. We cannot jeopardize the ability to provide the RadioReference services by allowing this activity to occur. Please respect this.
Chinese backdoor
- Thread starter Razorback55
- Start date
I suggest you do this to have as little error as possible, capture the frequency of your radio in a capture file for the encrypted part:
450.120 = 450.120 Mhz
dsd-fme.exe -i rtl:1:450.123M:22:-2:12:0:6021 -c crypt.bin
but also try to make a clear capture (without encryption):
dsd-fme.exe -i rtl:1:450.123M:22:-2:12:0:6021 -c clear.bin
Send both files here.
This encryption is very low-end, there is no MI. In fact I've already seen this encryption, yes it uses AES128 but in the wrong way.
AES128 generates an encrypted stream in OFB mode, but the encryption is reset with each frame.
It doesn't offer any security and it can also be considered a Chinese backdoor because the security is so bad.
Claude could do the following test:
Case 1: It ranks the 5 most frequent frames of 6 bytes (we don't take care of the 7th byte) in the clear.bin file and the 5 most frequent 6-byte frames in the crypt.bin file
Case 2: It ranks the 5 most frequent 3-byte frames (starting at the beginning of the frame) in the clear.bin file and the 5 most frequent 3-byte frames in the crypt.bin file
The 5 most frequent frames will be the silence frames.
For the Case 1:
We take the most frequent frame (clear.bin) and we XOR with the most frequent frame (crypt.bin) we get 6 bytes of encrypting stream, this is the encryption key (6 bytes). we XOR the set of crypt.bin frames with this encryption key (6 bytes). We don't deal with the 7th byte.
We listen if the sound is in the clear.
if not, we take the second most frequent frame (clear.bin) and in XOR with the first most frequent frame (crypt.bin) and we do the same thing again.
if not, we take the third most frequent frame (clear.bin) and in XOR with the first most frequent frame (crypt.bin) and we do the same thing again.
if not, we take the fourth most frequent frame (clear.bin) and in XOR with the first most frequent frame (crypt.bin) and we do the same thing again.
if not, we take the fifth most frequent frame (clear.bin) and in XOR with the first most frequent frame (crypt.bin) and we do the same thing again.
And if it doesn't work, we test the 5 most frequent frames (clear.bin) with the second most frequent frames (crypt.bin)
And if it doesn't work, we test the 5 most frequent frames (clear.bin) with the third most frequent frames (crypt.bin)
And if it doesn't work, we test the 5 most frequent frames (clear.bin) with the fourth most frequent frames (crypt.bin)
And if it doesn't work, we test the 5 most frequent frames (clear.bin) with the fifth most frequent frames (crypt.bin)
It may seem confusing but Claude will understand this, it will be enough to paste here what Claude has understood from my explanation.
If this Case 1 doesn't work, we do the same thing with Case 2 where we only take care of the 3 most frequent bytes of a frame and we do the same as above.
You should know that if you decrypt only 3 bytes out of the 7, the sound will be understandable. more difficult but we will be able to recognize words.
AES128 generates an encrypted stream in OFB mode, but the encryption is reset with each frame.
It doesn't offer any security and it can also be considered a Chinese backdoor because the security is so bad.
Claude could do the following test:
Case 1: It ranks the 5 most frequent frames of 6 bytes (we don't take care of the 7th byte) in the clear.bin file and the 5 most frequent 6-byte frames in the crypt.bin file
Case 2: It ranks the 5 most frequent 3-byte frames (starting at the beginning of the frame) in the clear.bin file and the 5 most frequent 3-byte frames in the crypt.bin file
The 5 most frequent frames will be the silence frames.
For the Case 1:
We take the most frequent frame (clear.bin) and we XOR with the most frequent frame (crypt.bin) we get 6 bytes of encrypting stream, this is the encryption key (6 bytes). we XOR the set of crypt.bin frames with this encryption key (6 bytes). We don't deal with the 7th byte.
We listen if the sound is in the clear.
if not, we take the second most frequent frame (clear.bin) and in XOR with the first most frequent frame (crypt.bin) and we do the same thing again.
if not, we take the third most frequent frame (clear.bin) and in XOR with the first most frequent frame (crypt.bin) and we do the same thing again.
if not, we take the fourth most frequent frame (clear.bin) and in XOR with the first most frequent frame (crypt.bin) and we do the same thing again.
if not, we take the fifth most frequent frame (clear.bin) and in XOR with the first most frequent frame (crypt.bin) and we do the same thing again.
And if it doesn't work, we test the 5 most frequent frames (clear.bin) with the second most frequent frames (crypt.bin)
And if it doesn't work, we test the 5 most frequent frames (clear.bin) with the third most frequent frames (crypt.bin)
And if it doesn't work, we test the 5 most frequent frames (clear.bin) with the fourth most frequent frames (crypt.bin)
And if it doesn't work, we test the 5 most frequent frames (clear.bin) with the fifth most frequent frames (crypt.bin)
It may seem confusing but Claude will understand this, it will be enough to paste here what Claude has understood from my explanation.
If this Case 1 doesn't work, we do the same thing with Case 2 where we only take care of the 3 most frequent bytes of a frame and we do the same as above.
You should know that if you decrypt only 3 bytes out of the 7, the sound will be understandable. more difficult but we will be able to recognize words.
therealkf
Member
- Joined
- May 11, 2025
- Messages
- 34
I'll see what ole Claude has to say about that later this week. In the mean time I was looking into what specific silence pattern the Radtel may use, since I'm not seeing the Motorola pattern (F801A99F8CE080) in my dumps. I ran across this which may or may not be relevant for specific radio decryption attempts. As I understand the silence frame is the Lynch pin for the decryption effort sanity checks.
Likewise if anyone is familiar with is behavior, I did notice a reference to Bekens "intercom" vocoder in FM100B_V1.2.0.6_20250311.bin:
beken378\intercom\Vocode7
Likewise if anyone is familiar with is behavior, I did notice a reference to Bekens "intercom" vocoder in FM100B_V1.2.0.6_20250311.bin:
beken378\intercom\Vocode7
therealkf
Member
- Joined
- May 11, 2025
- Messages
- 34
I also ran across this post:
"From my research, I noticed that in the past year most Chinese radios have adopted the BK4819/29, which is an RF chip supporting F2D and F1W demodulation. However, in the case of the Radtel RT-4D, it uses the Horketech HF6853 as a vocoder.
The reason for this choice seems to be that the AT32F423, unlike STM32FXX, does not have a built-in I2S interface for handling audio. As a result, an external vocoder like the HF6853 is used."
And a photo of the HF6853 on the PCB.
Main point being exploiting some of these various implementations may require target specific vocoder knowledge.
Well the RT-4D is much more secure than all other Chinese radios, there are no silence frames!
You can check it by ear, you don't hear silence between words but noise, I have the impression that this noise comes from a shielding defect and that the HF goes into the audio.
Since there are no silence frames, you can't attack the RT-4D even if it has a static MI.
The advantage is that it's safer, the disadvantage is that the sound is not very good because disturbed by parasitic noises.
if you can do the same with the baofeng DM32 and post the .bin file here, I'll tell you if it can be attacked or not.
You can check it by ear, you don't hear silence between words but noise, I have the impression that this noise comes from a shielding defect and that the HF goes into the audio.
Since there are no silence frames, you can't attack the RT-4D even if it has a static MI.
The advantage is that it's safer, the disadvantage is that the sound is not very good because disturbed by parasitic noises.
if you can do the same with the baofeng DM32 and post the .bin file here, I'll tell you if it can be attacked or not.
Last edited:
Razorback55
Member
- Joined
- Mar 6, 2025
- Messages
- 27
@therealkf Was Claude able to decode the contents of the sound file?
One would think they would just use Codec 2.
I believe DSD-FME can decode codec 2 as well...
If they steal a patent to make chips, they want to be able to sell them. so they make DMR chips and the DMR only works with AMBE2+.
Codec2 chips would only be purchased by very few people.
I wouldn't say DMR ONLY works with AMBE. Codec2 can work in DMR, but as you know it's pretty niche except for the ham community and whatnot.
I kinda wish more manufactures used Codec2 though. It be a lot cheaper you'd think.
I kinda wish more manufactures used Codec2 though. It be a lot cheaper you'd think.
I don't want to offend you, but would you have the possibility to stop talking nonsense?
The DMR cannot use Codec2!
The DMR is a standard developed by ETSI, this standard provides for the AMBE2+ codec and nothing else.
The DMR converts voice in 20ms increments to 49 bits of data with a FEC, resulting in a 72-bit frame.
This is completely incompatible with Codec2 which uses 10ms, 20ms or 40ms samples.
The Codec2's 3200 mode with 20 ms produces a 64-bit frame instead of 49 bits. The DMR standard cannot work with a different data size.
Open Source DMR Radio
While ham radio operators have been embracing digital mobile radio (DMR), the equipment is most often bought since — at least in early incarnations — it needs a proprietary CODEC to con…
hackaday.com
Timing and framing may not be standard, but it apparently can be done though I guess.
Open Source DMR Radio
While ham radio operators have been embracing digital mobile radio (DMR), the equipment is most often bought since — at least in early incarnations — it needs a proprietary CODEC to con…
Timing and framing may not be standard, but it apparently can be done though I guess.
It's not DMR, it's a software and hardware digital modem, which the author named DMR, but that's all.
I too can put strawberry syrup in an empty Coca Cola bottle and say it's Coca Cola, but it won't be real Coca Cola.
There are indeed silence frames in the DM32, they look like jamesvoll's silence frames.
On the other hand, I see something extra that may have been inserted on purpose as a backdoor.
I don't want to say until I'm sure.
Could you provide two .bin files encrypted with a known key? A .bin file with ARC4 and a bin .file with AES256?
Similar threads
