Hytera Basic Privacy - Recovering Key Value

[Tarnish05]

Hi All,

I've started this NEW thread to continue discussing the possible methods of recovering/testing theory verses a method and vulnerability for recovering lost keys.

Users can choose to upgrade to higher levels of privacy modes such as Advanced or AES which are chargeable. We are just talking about Basic in this thread.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

I had misread that Hytera BP was capable of being received on a Motorola set so long as it was set to Enhanced Privacy but that's not possible so thanks to 'Forts' pointing that out.

Hytera says that Basic Privacy solution offers provides key option between 1-255 using 10, 32 or 64 characters to the transmission and receiver frequency, each of which must match up. The keys are not customized, so if a hacker was so minded they need only scan all 255 keys to potentially hit on the one you are using.

You have 1-30 Key IDs to set (as a maximum) and a Key Value.

So, if I have a radio set to set with 'Key ID 1' and '10-Characters' I only need to find the Key value field.

I'm guessing its not as straightforward as trying 1-255 under the Key Value with FFFFFFF for the rest given that the value can be 0-F.

So, what options are available to find/read/sniff/decode it? Method, Tools etc can I use with the RCDB file.

----------------------------------------------------------------------------------------------------------------------------------------------------------

I have reloaded a RCDB extraction of a codeplug into a Hex editor and I think I can see where it should show the value. Its believe given the firmware version (A7.06.01.006) it cant be read in the clear anymore.

@ 0xFF1E071F "Reveal already written basic enc keys from a Hytera Radio?" Yes, as it's not possible to copy to a Moto set, so recovering the original is now the aim.

Regards

Mike

 

[0xFF1E071F]

1. When you enter a Basic Privacy Key to Hytera, It copies the value from CPS to flash (appereantly). But, Hytera encrypts(or encodes(?) I am not sure of that) the key value and stores encrypted(encoded). Because U could not have find any trace of the actual key?

2. You said:

I have reloaded a RCDB extraction of a codeplug into a Hex editor and I think I can see where it should show the value. Its believe given the firmware version (A7.06.01.006) it cant be read in the clear anymore.

OK, I am not sure if I get you right: You use CPS and read codeplug. Then save it as RCDX file right? Then open that file in hex editor? OK; if this is the issue, than you cannot see encryption keys, in any forms. Because when you read codeplug, the firmware does not send keys to CPS. Remember that when you read codeplug your keys are shown as "********" in CPS right? Thats why! (But you can overwrite)

3. Reveal the already written keys? OK as of now it seem impossible!

OK, let's say you have all motorola basic enc keys. You enter them to hytera in the same order.(i dont know if you can, because they have to be 10, 32 or 64 chars, let's say you can). I still do not know if you can communicate in basic encryption with motorola and hytera

 

[Tarnish05]

1. I believe so yes. Any key entered overrides the existing key in the radio with the new one. This is visible when you change it but ******** out when read back by the CPS, this is normal.

If the newly entered key is written to the radio its still visible as long as the codeplug is opened and saved locally.

2. Reading the codeplug or the database file with a HEX Editor you can see the offset where the key is believed to be but the firmware prevents a clear read. So, if the key is there, I need to know what simple encryption was used to mask it and reverse it (working theory). Probably the key ID mixed with the Key Value from my understanding but I could be wrong.

3. YES. but I'm hoping its not impossible.

4. I've dismissed the prospect of having a Moto work with Hytera BP, it wont work.

 

[radioopperator]

Think you have to decode the data over the air it has to be repeated every X numbers of character data?

 

[0xFF1E071F]

Best way to decode/decrypt BP is from air! AGAIN: If you connect your hytera radio to computer and then read rcdx from it using CPS; the firmware DOES NOT send "even the encrypted(or encoded)" keys from radio to CPS. There is no key data in RCDX.

 

[Tarnish05]

Im running Airspy SDR Studio v1.0.0.1919 with a RTL-SDR Dongle R860t V3 but dont see any headers or frames to capture. Is this the path I need to be on for this?

If so, am I not seeing the right information as a result of the wrong SDR version Im running or do I need a specific plug-in.

Any guidance for the next steps would be appreciated following a few weeks of reading and forum archive posts.

MTIA.

 

[0xFF1E071F]

Im running Airspy SDR Studio v1.0.0.1919 with a RTL-SDR Dongle R860t V3 but dont see any headers or frames to capture. Is this the path I need to be on for this?

If so, am I not seeing the right information as a result of the wrong SDR version Im running or do I need a specific plug-in.

Any guidance for the next steps would be appreciated following a few weeks of reading and forum archive posts.

MTIA.

Sorry for late reply. Unfortunately I do not have a direct answer for your question. But you can read sources of these two dmr decoders to understand the frame structures and where they store relevant data:

https://github.com/f4exb/dsdcc
https://github.com/pd0mz/go-dmr

And did you check ETSI documentations?

https://www.etsi.org/deliver/etsi_ts/102300_102399/10236101/02.05.01_60/ts_10236101v020501p.pdf

 

[Tarnish05]

After reading ETSI documents and some help from some more experienced colleagues I have a been successful in achieving what I set out to do. Thanks all for the help. On to more projects and learning.

For those wanting to follow their own testing methods I will say running 'Airspy SDR Studio v1.0.0.1919' is not going to help.