• Effective immediately we will be deleting, without notice, any negative threads or posts that deal with the use of encryption and streaming of scanner audio.

    We've noticed a huge increase in rants and negative posts that revolve around agencies going to encryption due to the broadcasting of scanner audio on the internet. It's now worn out and continues to be the same recycled rants. These rants hijack the threads and derail the conversation. They no longer have a place anywhere on this forum other than in the designated threads in the Rants forum in the Tavern.

    If you violate these guidelines your post will be deleted without notice and an infraction will be issued. We are not against discussion of this issue. You just need to do it in the right place. For example:
    https://forums.radioreference.com/rants/224104-official-thread-live-audio-feeds-scanners-wait-encryption.html

MotoTRBO Restricted Access to System (RAS)

Status
Not open for further replies.

inigo88

California DB Admin
Database Admin
Joined
Oct 31, 2004
Messages
1,698
Location
San Diego, CA
#1
I figured I would spin-off what has been posted about RAS in the "Understanding Capacity Plus" thread into its own thread where we can continue discussion. I don't have much to contribute yet since I don't think I've come across any RAS enabled systems, but I've been really interested in RAS as well - particularly in its ramifications to using DMRDecode and DSD. Like Forts, I suspected it was similar to EDACS ESK.

The applicable posts from the "Understanding Capacity Plus" thread are below:

TampaTyron said:
I setup the same equipment for another event previously, when I worked at this specific radio shop. I have acquired one of their portables and read it as well. No privacy, but has RAS enabled. RAS is a weird animal because DMR decode displays the proper system details, but the headers or packets must be different because half a dozen TRBO radios cant decode it. Can't wait until someone figures out how to figure it out ......TT
IanWraith said:
Hi All

Another board member who I believe wants to remain anonymous recently sent me some logs from a couple of RAS 'protected' systems. The common element in both of them was this PDU ..

11:28:17 DMR Data Frame
CACH : TACT Ch 1 First fragment of LC
Slot Type : Colour Code 3 Terminator with LC
Unknown Full Link Control LC : FLCO=36 + FID=16 00000000000000000000001110100101000000000000011100 101011

My guess is that RAS is a simple system. The base sends a hashed (basically a type of encryption) value of the RAS password every so often. The Moto radios compare this with a hash they have created of the RAS password they have been given and if they are different they won't do anything. That will be programmed into the firmware of the Moto sets and unless you fancy rewriting the firmware (which will probably be stored in an encrypted form within the radio) there isn't much you can do I'm afraid. One reason I would keep away from expensive proprietary hardware and stick to open source software.

Regards

Ian
Forts said:
I suppose if one could figure out the hash then you might be able to determine the RAS password from that. Which of course opens up another can of worms. Is RAS considered encryption, making it a no-no to mess with, or is it more along the lines of EDACS ESK which was used to 'encrypt' the control channel?
kmoe said:
RAS is akin to a system ID (like on Privacy Plus and Smartnet trunked systems) and is not related to encryption in any way. The TRBO "control channel" data can still be decoded with DMR decode.
Forts said:
I suppose it coule be viewed like a system ID, but I agree it's not encryption. But.. it is obviously a method to keep unauthorized users out, so it is a security feature as well. If anyone has any hopes of determining how it works you would really need a log from a system with a known key.
TampaTyron said:
On the LCP system that I am monitoring, I get the following:
CSBKO=59 + FID=16 11100111000110110001001000100010010000110000000000 00000000000000
and
CSBKO=59 + FID=16 11000111000110110001001000100010010000110000000000 00000000000000
as a pair every 15 seconds. Then both repeat individually every 10-15 seconds. TT
IanWraith said:
Hi All

My apologies for the rushed post earlier I had meant to say that the CSBKO=59 PDUs as seen by TampaTyron possibly contain a hashed (or encrypted) version of the RAS key.

As I said before I think that mobiles on a RAS system listen out for this PDU. They compare a hashed version of the RAS key they have been sent to the contents of the CSBKO=59. If they match then they proceed as normal.

Regards

Ian
TampaTyron said:
Per Mototrbo CPS , RAS ID is 6-24 unicode characters including 0-9, A-Z, a-z, hyphen, underscore, dollar, and pound sign. TT
I believe that's everything. Hopefully we can continue discussing RAS in this thread!
 

inigo88

California DB Admin
Database Admin
Joined
Oct 31, 2004
Messages
1,698
Location
San Diego, CA
#2
Just to add, I only learned about RAS a few months ago in this thread (about a Capacity Plus system installed at the Squaw Valley Ski Resort near Lake Tahoe in California):
http://forums.radioreference.com/ca...53-trying-listen-ski-patrol-squaw-valley.html

The following posts are relevant:

com501 said:
Good luck. Trbo requires a Motorola MotoTrbo radio programmed on their system with the correct trunking information. Squaw is running syswatch so if your ID doesn't match an authorized radio on the system, bye bye. It's also going to have RAS before the ski season starts, which will pretty much lock everything out. PS - syswatch will kill BOTH radios if a duplicate ID pops up simultaneously with another radio when they register on the system.

You could just join the ski patrol.... ;)
com501 said:
Squaw Valley is running Enhanced Encryption with RAS. They purchased RAS at the beginning of the year for their system. Encryption will prevent DSD and DMRDecode. RAS will completely circumvent even a properly programmed two way radio, unless you have the correct and matching RAS key and a valid ID.

Really, you should just become an authorized user.
Exsmokey said:
It would be interesting to hear why a ski area would need to encrypt their communications. I've lived next to a big one for 25 years and have monitored their radio system for all of that. I haven't heard anything that would need to remain confidential.
com501 said:
Because its free. And because it keeps people from listening and protects their business operations.

Oh, and because they can.

Every radio system I install, I encrypt if it has the capability.
I suspect com501 was involved with the install, given his knowledge of the details. But I think he is incorrect about motoTRBO Enhanced Encryption being able to block DMRDecode. Yes it encrypts the voice traffic, but not the DMR data packets. I was originally concerned RAS could be a way to encrypt the data as well (similar to how TETRA and Opensky systems encrypt their control channels), but that's clearly not the case based on what we've seen so far.
 
Last edited:

Forts

Mentor
Database Admin
Joined
Dec 19, 2002
Messages
5,500
Location
Ontario, Canada
#5
Dmrdecode still works fine on systems using RAS as far as I know... As well as DSD. It just keeps out the interlopers with real radios.
 
Joined
Feb 1, 2010
Messages
563
Location
Tampa, FL
#6
I can confirm that DMRdecode does in fact work on a RAS enabled system. It is very effective at keeping interlopers from TXing or RXing anything on the system. TT



Dmrdecode still works fine on systems using RAS as far as I know... As well as DSD. It just keeps out the interlopers with real radios.
 
Joined
Dec 25, 2013
Messages
3
#7
Ras bypass

Hi has anyone tried to use the input freq rather than the output freq to get around the ras system. You would need to be in range of the tx freq to be able try this.
 
Joined
Sep 19, 2002
Messages
5,114
Location
Toronto, Ontario
#9
Can you please elaborate more on this method?
My understanding is that TRBO radios with up to date firmware won't monitor (unmute on) RAS systems without the correct key in their codeplug; the suggestion is to monitor the inbound frequencies instead on the assumption that there will not be any RAS data to trigger muting. I have my doubts about getting a TRBO radio to monitor trunking inputs though, as the sync patterns do not match what the radio would be looking for.
 

RyanRox099

Member
Premium Subscriber
Joined
Dec 9, 2007
Messages
59
Location
Tampa, FL
#10
My understanding is that TRBO radios with up to date firmware won't monitor (unmute on) RAS systems without the correct key in their codeplug; the suggestion is to monitor the inbound frequencies instead on the assumption that there will not be any RAS data to trigger muting. I have my doubts about getting a TRBO radio to monitor trunking inputs though, as the sync patterns do not match what the radio would be looking for.
Yes I don't think that'll work it all. When a subscriber transmits, the subscriber uses its configured RAS key to encode the bursts.When a repeater receives the bursts, the repeater also uses its configured RAS key to decode the bursts. If the RAS keys in the subscriber and repeater are the same, the repeater decodes and repeats the bursts successfully.
 
Joined
Dec 25, 2013
Messages
3
#11
Use a mototrbo radio and input the tx freq in the rx freq, then you monitor in input channel. As you are getting the data before it hits the repeater. Colour codes and groups etc are still required
 

mikewazowski

Forums Manager/Global DB Admin
Staff member
Joined
Jun 26, 2001
Messages
10,702
Location
Central Ontario
#12
Use a mototrbo radio and input the tx freq in the rx freq, then you monitor in input channel. As you are getting the data before it hits the repeater. Colour codes and groups etc are still required

As the two posts above yours have mentioned, it's almost a sure thing that it will not work.
 
Joined
Dec 25, 2013
Messages
3
#13
Sorry was replying to a post asking to elaborate. Well I will be able to tell you if it works or not by the weekend. The reason. I believe it will is the ras key only stops rouge access to the repeater, hence monitoring the input freq. the ras key does not encrypt the message only the key, as dsd proves no encryption set and you can hear the conversation
 

RRR

Member
Premium Subscriber
Joined
Dec 6, 2005
Messages
1,111
#14
My understanding is that TRBO radios with up to date firmware won't monitor (unmute on) RAS systems without the correct key in their codeplug
What about receiving RAS enabled transmissions with a radio with older (pre-RAS) firmware?
 
Joined
Feb 1, 2010
Messages
563
Location
Tampa, FL
#16
Is there a modification to DSD or DMR decode to show full frames? Asked another way, is there a program to view the full voice frames? I am thinking that the RAS modifies the voice (and idle) frames just enough to prevent legit TRBO radios with current firmware from following the traffic. I do not know where in the frame it does this. Once you type a key into the CPS, the CPS hashes (for lack of a better word) the unicode text to a 7 byte "key" that gets written to the radio. This key is located between "28 00" and "52 00" and can be located if you search a Wireshark dump of a codeplug write using the Wireshark FIND command, string of "RAS" without quotes and SEARCH IN set to "Packet bytes." I think if I can view the voice frames on systems with RAS and compare them to those without, then we would be moving towards success. There will be the next step of understanding how the CPS converts unicode to the hex key, then understand what the radio does with this key. I am contemplating purchasing RAS and experimenting on my repeater here. TT
 
Joined
Nov 10, 2009
Messages
71
Location
Ontario, Ca.
#17
I was thinking about first putting the letter A in the RAS and looking what the output looks like using DMR and DSD. The the next letter and so on. I'm thinking I can figure out the code that is being used.
 
Joined
Dec 19, 2002
Messages
14
#18
Is there a modification to DSD or DMR decode to show full frames? Asked another way, is there a program to view the full voice frames? I am thinking that the RAS modifies the voice (and idle) frames just enough to prevent legit TRBO radios with current firmware from following the traffic. I do not know where in the frame it does this. Once you type a key into the CPS, the CPS hashes (for lack of a better word) the unicode text to a 7 byte "key" that gets written to the radio. This key is located between "28 00" and "52 00" and can be located if you search a Wireshark dump of a codeplug write using the Wireshark FIND command, string of "RAS" without quotes and SEARCH IN set to "Packet bytes." I think if I can view the voice frames on systems with RAS and compare them to those without, then we would be moving towards success. There will be the next step of understanding how the CPS converts unicode to the hex key, then understand what the radio does with this key. I am contemplating purchasing RAS and experimenting on my repeater here. TT
I know when you READ a radio with CPS it does NOT populate the RAS key in the software. But have you looked in Wireshark while READing a radio to see if the RAS key passes thru to the computer anyway?
 
Joined
Feb 1, 2010
Messages
563
Location
Tampa, FL
#19
Yes. RAS key and Privacy key show as FFFFFFFFF's when read. Also tried the old "increment by 1" method, and found "000000" hex output to be drastically different than "000001" etc. TT
 
Status
Not open for further replies.
Top