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:
I believe that's everything. Hopefully we can continue discussing RAS in this thread!
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!