Understanding Hytera XPT

[DSheirer]

Building on Ian and Eric's threads for 'Understanding ...' other DMR/NXDN formats, I didn't see one for Hytera XPT.

A local DMR Hytera XPT system is broadcasting encrypted group calls and it appears like the Short Link Control (SLC) contents are also being encrypted while the call is in progress.

Has anyone seen this before?

Denny

[F-] C05C8 TS:1 CC:1 IDLE  [20MB/252MB 8%]
[--] 866C0 TS:0 CC:1 TERMINATOR FLC HYTERA GROUP VOICE CHANNEL USER FM:49 TO:11 SERVICE OPTIONS [ENCRYPTED] UNK:203  [20MB/252MB 8%]
[--] C00F0 TS:1 CC:1 IDLE  [20MB/252MB 8%]
[-L] E9FB0 TS:0 CC:1 TERMINATOR FLC HYTERA GROUP VOICE CHANNEL USER FM:49 TO:11 SERVICE OPTIONS [ENCRYPTED] UNK:203  [20MB/252MB 8%]
SLC MSG:980B900 CRC-8 RESIDUAL: 245 TS:0 [CRC ERROR] SLC MOTOROLA CON+ TRAFFIC CHANNEL NETWORK:2059 SITE:144 MSG:980B900  [20MB/252MB 8%]
[F-] C05C8 TS:1 CC:1 IDLE  [20MB/252MB 8%]
[--] 866C0 TS:0 CC:1 TERMINATOR FLC HYTERA GROUP VOICE CHANNEL USER FM:49 TO:11 SERVICE OPTIONS [ENCRYPTED] UNK:203  [20MB/252MB 8%]
[--] C00F0 TS:1 CC:1 IDLE  [20MB/252MB 8%]
[-L] E9FB0 TS:0 CC:1 TERMINATOR FLC HYTERA GROUP VOICE CHANNEL USER FM:49 TO:11 SERVICE OPTIONS [ENCRYPTED] UNK:203  [20MB/252MB 8%]
SLC MSG:980B900 CRC-8 RESIDUAL: 245 TS:0 [CRC ERROR] SLC MOTOROLA CON+ TRAFFIC CHANNEL NETWORK:2059 SITE:144 MSG:980B900  [20MB/252MB 8%]
[F-] C05C8 TS:1 CC:1 IDLE  [20MB/252MB 8%]
[--] 866C0 TS:0 CC:1 TERMINATOR FLC HYTERA GROUP VOICE CHANNEL USER FM:49 TO:11 SERVICE OPTIONS [ENCRYPTED] UNK:203  [20MB/252MB 8%]
[--] C00F0 TS:1 CC:1 IDLE  [20MB/252MB 8%]
[-L] E9FB0 TS:0 CC:1 TERMINATOR FLC HYTERA GROUP VOICE CHANNEL USER FM:49 TO:11 SERVICE OPTIONS [ENCRYPTED] UNK:203  [20MB/252MB 8%]
SLC MSG:980B900 CRC-8 RESIDUAL: 245 TS:0 [CRC ERROR] SLC MOTOROLA CON+ TRAFFIC CHANNEL NETWORK:2059 SITE:144 MSG:980B900  [20MB/252MB 8%]
[F-] C05C8 TS:1 CC:1 IDLE  [20MB/252MB 8%]
[--] 866C0 TS:0 CC:1 TERMINATOR FLC HYTERA GROUP VOICE CHANNEL USER FM:49 TO:11 SERVICE OPTIONS [ENCRYPTED] UNK:203  [20MB/252MB 8%]
[--] C00F0 TS:1 CC:1 IDLE  [20MB/252MB 8%]
[-L] E9FB0 TS:0 CC:1 TERMINATOR FLC HYTERA GROUP VOICE CHANNEL USER FM:49 TO:11 SERVICE OPTIONS [ENCRYPTED] UNK:203  [20MB/252MB 8%]
SLC MSG:980B900 CRC-8 RESIDUAL: 245

Sometimes the repeater keys up with what appears to be malformed Empty/Null SLC messages:

[F-] A0000 TS:0 CC:1 IDLE  [21MB/252MB 8%]
[--] C0000 TS:1 CC:1 IDLE  [21MB/252MB 8%]
[--] A0000 TS:0 CC:1 IDLE  [21MB/252MB 8%]
[-L] C0000 TS:1 CC:1 IDLE  [21MB/252MB 8%]
SLC MSG:80C2808 CRC-8 RESIDUAL: 250 TS:0 [CRC ERROR] SLC UNKNOWN OPCODE:8 MSG:80C2808  [21MB/252MB 8%]
[F-] A0000 TS:0 CC:1 IDLE  [21MB/252MB 8%]
[--] C0000 TS:1 CC:1 IDLE  [21MB/252MB 8%]
[--] A0000 TS:0 CC:1 IDLE  [21MB/252MB 8%]
[-L] C0000 TS:1 CC:1 IDLE  [21MB/252MB 8%]
SLC MSG:80C2808 CRC-8 RESIDUAL: 250 TS:0 [CRC ERROR] SLC UNKNOWN OPCODE:8 MSG:80C2808  [21MB/252MB 8%]

or

[F-] C0000 TS:1 CC:1 IDLE  [22MB/252MB 8%]
[--] A0000 TS:0 CC:1 IDLE  [22MB/252MB 8%]
[--] C0000 TS:1 CC:1 IDLE  [22MB/252MB 8%]
[-L] A0000 TS:0 CC:1 IDLE  [22MB/252MB 8%]
SLC MSG:8008801 CRC-8 RESIDUAL: 110 TS:0 [CRC ERROR] SLC UNKNOWN OPCODE:8 MSG:8008801  [22MB/252MB 8%]
[F-] C0000 TS:1 CC:1 IDLE  [22MB/252MB 8%]
[--] A0000 TS:0 CC:1 IDLE  [22MB/252MB 8%]
[--] C0000 TS:1 CC:1 IDLE  [22MB/252MB 8%]
[-L] A0000 TS:0 CC:1 IDLE  [22MB/252MB 8%]
SLC MSG:8008801 CRC-8 RESIDUAL: 110 TS:0 [CRC ERROR] SLC UNKNOWN OPCODE:8 MSG:8008801  [22MB/252MB 8%]

 

[thewraith2008]

Hi Denny,
All your ShortLC are reporting [CRC ERROR], I would think you would need to correct this first before believing the information it is presenting.

 

[DSheirer]

Good point Ian. That's what got me looking into the issue. For all times when there is not an encrypted call ongoing, I get good SLCs with good CRC-8 checks. But, when there's an encrypted call in progress, I get consistent CRC-8 failures.

So, I decided to investigate and see if perhaps Hytera was using some form of alternate CRC initial fill or mask. As you can see from what I posted, I'm getting consistent SLC fragments and the reassembled, deinterleaved SLC values are consistent. So with this consistency, I'm less inclined to brush this off as bad decodes.

The problem is that I'm not seeing a consistent CRC-8 checksum residual across the message-type sequences that would indicate a consistent mask or fill value.

 

[DSheirer]

Just to followup in case anyone else is writing a DMR decoder and encounters this anomaly with Hytera XPT repeaters.

This post is not about encryption, but rather the effect that scrambling/encryption in this case has on the correct function of a software decoder.

A local Hytera XPT system appears to be scrambling the contents of the Short Link Control (SLC) bits during encrypted calls.

This can be seen in the example that I posted above where SLC payload fragment values C0000 and A0000 should both have been all zeros to produce an all-zeros SLC that would indicate an IDLE state on both timeslots, but the SLC was apparently being scrambled or encrypted in anticipation of a call that never materialized:

[F-] C0000 TS:1 CC:1 IDLE  [22MB/252MB 8%]
[--] A0000 TS:0 CC:1 IDLE  [22MB/252MB 8%]
[--] C0000 TS:1 CC:1 IDLE  [22MB/252MB 8%]
[-L] A0000 TS:0 CC:1 IDLE  [22MB/252MB 8%]
SLC MSG:8008801 CRC-8 RESIDUAL: 110 TS:0 [CRC ERROR] SLC UNKNOWN OPCODE:8 MSG:8008801  [22MB/252MB 8%]
[F-] C0000 TS:1 CC:1 IDLE  [22MB/252MB 8%]
[--] A0000 TS:0 CC:1 IDLE  [22MB/252MB 8%]
[--] C0000 TS:1 CC:1 IDLE  [22MB/252MB 8%]
[-L] A0000 TS:0 CC:1 IDLE  [22MB/252MB 8%]
SLC MSG:8008801 CRC-8 RESIDUAL: 110 TS:0 [CRC ERROR] SLC UNKNOWN OPCODE:8 MSG:8008801  [22MB/252MB 8%]

What this can also affect is the timeslot identifier bit in the CACH This can cause havoc depending on how you're doing your burst framing and identifying/tracking each timeslot.

What's curious is that since both timeslots share the CACH, if the CACH is scrambled for a user on one timeslot, then it's also scrambled in the same fashion for any potential users on the other timeslot. I found some Hytera documentation that indicates that Hytera systems support repeater-level scrambling or encryption. So, maybe that's what going on with this system.

cheers,
Denny

 

[thewraith2008]

The problem you see with the "timeslot identifier" (TC), could this be related to the use of reverse channel. (not the voice superframe(F) one)
The reverse channel is sent in place of the SYNC for a idle block.
see "5.1.5.2 Dedicated outbound Reverse Channel (RC)" on page 35/36 of TS102-361-1

 

[Forts]

Hytera has options to encrypt just about every aspect of a DMR transmission. There are systems on the air around me that DSD+ doesn't even acknowledge the presence of a signal. Nasty tricks!

 

[DSheirer]

The problem you see with the "timeslot identifier" (TC), could this be related to the use of reverse channel. (not the voice superframe(F) one)

The sync patterns don't seem to be affected. Each of the bursts have a good sync pattern using either BS VOICE or BS DATA. The scrambling is applied to just the CACH (and voice frame contents). This makes it difficult to identify and track the timeslot (1 or 2) from the CACH and in turn the SLCs are scrambled.

 

[thewraith2008]

The use of the reverse channel would give the appearance of a missing timeslot during a voice bursts because the second timeslot would not be detected via the BS VOICE or BS DATA SYNCs.

Because the RC is embedded, the idle burst it occupies does not contain the BS DATA SYNC therefore you would miss that burst and the CACH that is preceding it.

While I'm sure you have your own way of detecting the SYNC and framing, I know that the current DSD code cannot detect this RC because it relies on a SYNC for framing, any embedded data is seen as a bad SYNC.
The exception is when a voice SYNC ( and superframe) is seen via one timeslot.

Anyway, just a thought.