Reverse Engineering the Baofeng dm1702 codeplug - M0YNG.uk

Created 2020-06-17

Modified 2020-08-03

Tagged

Amateur Radio

DMR

Codeplug

A note from the future that goes at the start

I started working on this nearly two month ago, and I've not had time to get any further with it. So I'm going to post this now, incomplete as it is, in the hopes it might be useful to someone else, or my future self if I get back to it at some point.

Some background

Recently I was too tempted by the seemingly very good price of the Baofeng dm1702 DMR radio.

I paid £65 for the radio, which included delivery, which seemed reasonable considering the features

2m + 70cm

Tier II DMR

Analogue FM

GPS

5w output

Programming over standard USB!

I didn't do enough research though, I just assumed that there would be tools available to help me code it up in Linux, as there are for so many DMR radios, but sadly all I can find right now is some stuff to write data to and from the radio[1], which works, but doesn't help me change any settings like dmrconfig[2] does for my Anytone.

1: https://github.com/OK2MOP/MD1702-tools

2: https://github.com/sergev/dmrconfig/

So I resorted to the official software, which only works in windows, which means I had to kick my offline VM into gear. But oh my, is that software bad, like, really, really bad.

When editing a table of channels, you can't tab between them, it sorts by name so adding a new row goes wherever the default text fits in the sorting order, etc. etc. etc.

It is so bad I decided to break out a hex editor and try to work out what is going on in the codeplug itself.

An initial look

Now, I'm not an expert at reverse engineering anything, so I don't expect to be able to actually do this task…

A first look wasn't promising, there is lots of empty space, lots of `FFFF`, lots of repeating data that doesn't appear to store anything meaningful.

Next I made one small change to the codeplug, and tried to diff it, here I have changed my hotspot frequency from `438.8MHz` to `136.12345MHz` on RX and `444.67899` on TX:

Thanks to a great tip from SP6MR[3] who identified the values as being stored as `unsigned 32bit` I started to get somewhere. Maybe.

3: https://mastodon.radio/@sp6mr/104358359395259741

A change of tense

You might notice a tense change now, as I'm writing this post as I work, mostly to keep notes for myself!

We can also see that changing the TX power level from low to high changes the value after the frequency from `40` to `42`

Changing the timeslot from `2` to `1` and the last chunk changes from `11` to `10`

But wait! changing the colour code from `1` to `2` makes that `11` or `10` into `12` or `02`, so we must be storing the timeslot in one bit, counting from zero

Which makes me wonder about our conclusion for the TX power…

Based on that, the `40` is actually `4` for DMR/Digital and `0` for analogue, with the other bit storing the TX power level as `0` or `2`.

We also see another line change much further through the file:

Only one bit seems to change though, so I don't know what it's for (yet?)

Next I changed it back to a digital channel, and set the "TX Contact Name"

It seems that the 6th chunk has some bits that changes to a number referring to the contact (somehow).

Around `0001F000` we see what looks like the name of contacts

Each Name seems to be 16 characters long, and have something after the text. This repeats for 800 calls, ending at `00023B40`, where we have `FF` until `00024000` where we get `00` until `00025020`.

Changing the call ID causes a change, but it's not clear how the data is stored, it doesn't appear to be `unsigned 32bit`. Here I've changed the ID from `310` to `111`

Based on Andy Valencia's keen eyes[4] the ID is being stored in "endian shuffled order", as can be seen here with the ID `11111111` as `c7, then 8a, and a9`, read each two together, but backwards and we get `0xa98ac7`

4: https://mst.vsta.org/@vandys/104360442782305975

If we change the ID to `11111113` we have even more confidence we're doing it right

Structure of a contact

At this point, I think the structure of a contact is:

16 bytes text (Name)

1 byte padding/space (`FF`)

3 bytes in "endian shuffled order" (call ID)

1 byte either `03` (Private Call) `04` (Group Call) or `05` (All Call)

3 bytes padding/space (`FF FF FF`)

Making 24 bytes in total per contact.

Structure of a memory

4 bytes unsigned 32bit (RX Frequency)

4 bytes unsigned 32bit (TX Frequency)

`0` for analogue, `4` for digital.

Add `2` if "RX Only" (`2` or `6`) * Add `1` if Squelch is "Stringent"

A bit for power, Channel Spacing, and "Lone Worker"

`0` for low power, `4` for high power. * If "Lone Worker" `8` for low and `a` for high power. * `0` Low + Narrow spacing (Analogue) OR Low Digital Power * `1` Low + Wide spacing (Analogue) * `2` High + Narrow spacing (Analogue) * `3` High + Wide spacing (Analogue) * `4` High Digital Power * `8` Low + Narrow spacing (Analogue) + Lone Worker OR Low Digital Power + Lone Worker * `9` Low + Wide spacing (Analogue) + Lone Worker * `a` High + Narrow spacing (Analogue) + Lone Worker OR High Digital Power + Lone Worker * `b` High + Wide spacing (Analogue) + Lone Worker

`8` for "Auto Scan Start", or `0` for not (only used if scan list set)

`1` for the "Scan List" reference, or `0` if none

`00` Is for "TX Admit"

`00` "Always" (Analogue or Digital) * `01` "Analogue Channel Free" * `02` "Analogue CTCSS/CDCSS Correct" * `03` "Analogue CTCSS/CDCSS Incorrect" * `08` "Digital Channel Free" * `10` "Digital Color Code Free"

`8` for "Emergency Alarm Indication", `c` if also "Emergency Alarm ACK", `e` if also "Emergency Call Indication", `2` if not "Alarm" but "Call"

`1` for the "Emergency System" reference, or `0` if none

`0` - Doesn't appear to change

`0` - Doesn't appear to change

`0` for "Private Call Confirmed" off, `2` for on. `3` for "Short Data Significance Bit" in "Confirming Mode", `1` if "Private Call Confirmed" is off

`0` - Doesn't appear to change

`0` for Slot 0, `1` for Slot 2, `3` for "Double Capacity Mode"

`0` - `f` for the colour code

`0` for no encryption, `8` for encryption on

`0` - `f` for the Encryption Key reference

3410 offset

`00` - `ff` "GPS System" reference

`00` - `ff` "RX Group List" Reference

`1` - Doesn't appear to change

`0` or `8` ??

`ff ff` "CTCSS/CDCSS Decode" in endian shuffled order (e.g. `70 06` for `67.0`, `41 25` for `254.1`) `ffff` if none.

`ff ff` Same again for Encode.

`1` for VOX, `0` if not

`0` - Doesn't appear to change

`8` for "PTT ID Display", `0` for off

`000` - Doesn't appear to change

`0` if "Talk Around Status" is OFF, `1` if OFF. Add `4` if ENABLED (`4` and `5`)

`000` - Doesn't appear to change

`0000 0000` - Doesn't appear to change

0001e020 offset

3 bytes `0`

`0100`

`0000`

`0`

`0`

`00` - `ff` "TX Contact Name" reference

Make a memory by hand

In theory we know enough to try making a memory by hand now, I'm going to try GB3CG[5], a local analogue repeater on 2m.

5: https://www.grg.org.uk/gb3cg/

145.725MHz TX

145.125MHz RX

‘J’ 118.8 Hz CTCSS

Analogue

High Power + Narrow spacing

TX admit always

everything else off

I think it will look like this:

I manually edited the codeplug in Okteta and wrote it to the radio, and it half worked!

CTCSS was wrong, it was enabled but had the wrong value, so I changed it on the radio and read back the changes

When I remove just the RX CTCSS we get

When I remove just the TX CTCSS we get

This suggests that I've not got the CTCSS structure quite right, but what's really happened is I've messed up understanding the structure. The one above is actually the revised version, not what I originally had. Byte 3 on this line needs to be something else, and I'd missed it completely so everything was offset.

-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-

🖤 Black Lives Matter

💙🤍💜 Trans Rights are Human Rights

❤️🧡💛💚💙💜 Love is Love

Copyright © 2024 Christopher M0YNG - It is forbidden to use any part of this site for crypto/NFT/AI related projects.

Code snippets are licenced under the Hippocratic License 3.0 (or later.)

Page generated 2024-03-24 by Complex 19