Batboard

I'm running a XPR 8300 with RAS. Our radios are all set to enhanced privacy with key ID's and Values.

Someone was able to use DSD+ and clone a radio ID with the CC and send a text message to a user through the RPT.

I tested the problem with another radio that has no RAS, Key ID values programmed. Programmed the digital frequency with the RX freq that's in our radios. Then put in the a radio ID from our system and was able to send a text message via the RPT.

I thought RAS would prevent this . Any suggestions ?

Max

Are you sure you went through the repeater and not directly to the other radio?

Programmed the digital frequency with the RX freq that's in our radios

The RPT has freq A TX and freq B RX ,so the radios would have freq B TX and freq A RX

I programmed a 4550 with with freq B Digital with the same CC , no RAS or encrypt keys but with a radio ID that's used on the RPT.

I sent a text message and the RPT did TX ,and the message went through. I know it doesn't sound right. If I'm TX on the RPT TX freq, why is it lighting up.

Let me try to explain this again. I'll use a made frequency for this example.
RPT: TX- 457.000
RX- 452.000
CC-1
Radios on the system:
TX- 452.000
RX- 457.000

All radios have a RAS Key and Enhanced Privacy on.

There are 15 radios on the system.

I took a 4550 with no RAS or Enhanced keys in it. I programmed TX: 457.000 Digital with CC-1

I used a RID in our system and sent a text to another radio on the system and the RPT lit up and the message was received on the other radio.

I don't understand how that would key up the RPT and how the radio received the text when it's didn't have the RAS or Enhanced Privacy on.

Confused.

You sent the text message directly to the radio and bypassed the repeater.

yes, i Tx on same TX that's in the RPT. So why did the RPT TX ?

The repeater didn't TX unless you were siting in front of it and disagree? You transmitted on the output of the repeater, that's why the receive radio received your text message.

Max wrote:Let me try to explain this again. I'll use a made frequency for this example.
RPT: TX- 457.000
RX- 452.000
CC-1
Radios on the system:
TX- 452.000
RX- 457.000

Why is your system configured with the frequencies in reverse (or is this just an example you made up)?

From the frequencies, this is a commercial repeater. In Canada (which you are) a 452/457 pair, the repeater will TX 452 and Rx on 457. Just curious.

"Let me try to explain this again. I'll use a made frequency for this example."

Here's my conclusion is:

I used a 4550 without the RAS key or Privacy Key and programmed a simplex with the CC and the RX freq of the radios on the system.

I sent a text message to a RID on the system and the message is received on that radio. The same radio sends an acknowledgement that the message was received and in doing so it keys up the RPT.

Make sense ??
I'm using an older version of firmware, wondering if this was fixed in a newer version.

Where in the CPS can you disable the radio from receiving test ?

RFguy wrote:

Max wrote:Let me try to explain this again. I'll use a made frequency for this example.
RPT: TX- 457.000
RX- 452.000
CC-1
Radios on the system:
TX- 452.000
RX- 457.000

Why is your system configured with the frequencies in reverse (or is this just an example you made up)?

From the frequencies, this is a commercial repeater. In Canada (which you are) a 452/457 pair, the repeater will TX 452 and Rx on 457. Just curious.

Yes, i am located in Canada, but the system in question is not in Canada. It belongs to a customer in the US that i sold a XPR 8300 to. He simply asked for my help in solving this issue. I am not the custodian for this system.

There is a security flaw in the Mototrbo system, which causes this. Not only can you spoof a radio with text from an unauthorized user, but if enable/disable is allowed on the subscriber radio, ANYONE can turn that radio on/off with a command.

This was pointed at to Motorola by another person a few years ago, and they chose to ignore the flaw. This flaw does not exist in P25 radios, which truly ignore items that don't match the encryption. This is what happens when you get engineers and code-writers who are really script kiddies and don't thoroughly vet their designs.

The 'update-a-month' syndrome is here to stay.