A simple idea for "safe" scanning with an EDACS radio (800 MHz)

[ElroyJetson]

I just had a thought...maybe not for the first time, hopefully not for the last time.


Though many of us know that an EDACS radio can be set to listen to a regular EDACS system
without affiliation or TX ability on any talkgroup, the possibility still remains that the system might
be able to command the radio if your LID gets hit.


I think I know a way around that.


An .sc4 file, which is custom built to offset the TX frequencies but leaves the RX frequencies alone.

The TX offset is 45 MHz on 800 systems. An .sc4 file that set a TX offset to any other value would be sufficient.


Just something to think about.


So who wants to try it?


Elroy

 

[EnidPuceflange]

If an EDACS radio doesn't affiliate (login) then the only reason that it might get disabled over the air would be if the programmed LID matched one the system admin wanted gone....so you need to program it with a LID that won't get used, or disabled. 0 is a great choice

 

[mitaux8030]

My thoughts:
How would a .sc4 file that muddles up the TX freqs prevent it from being disabled?

With my experiences, for a radio that I want to keep 'off the radar', I've done the following:
Unticked auto-login
Disabled the Individual call menus /functions. I found that with this still enabled, and accessing those functions, a brief burst of RF (suspect HSD uplink, never really investigated it) is emitted despite auto-login disabled.
Likewise, disabled the WHC list... under some circumstances, I found a brief blat of RF could be emitted when using this.

That'll keep any RF from being transmitted. But it still won't stop a terminal from hearing any disruptive downlink commands... which is why I'm wondering how muddling with the TX freqs via an sc4 file would work. I've discovered a technique where a dynamic regroup targeting an LID, either known rogue or known 'unused' LIDs, can be redirected to a dead end group... and it'll stay there indefintely - effectively disabling the radio.
Of course, unticking dynamic regroup will prevent that from happening. So add that to your list of recommendations of keeping a radio active.

 

[Radioman96p71]

Modifying the sc4 would definitely inhibit the radio from talking back to the system, but its that nasty "stolen radio" broadcast that is sent every 10 seconds on the control channel that can be a problem. Also, if the radio receives any kind of command to it, be it a remote EEPROM read, ProFile, Ping, or even OTAR, the radio will act on the command. Which I have seen first hand make a radio really upset when it hears the command but cant talk back. Setting the radio to LID 0 is an option, but then any data calls with a LID 0 destination will cause the radio to try and read them. Granted that is only if you have the data option and have it enabled for some weird reason. I guess the only true way to make these radios purely invisible would be to either find where the firmware hook is that listens for its ID and reacts, or find a way to put an impossible LID in the radio (like 16356+) so that it could never appear on the system. With hex-editing you might be able to make it happen.

For most systems and situations, simply turning all those features off and being careful will be good enuf. But if you are on a complex system or up against some good administration, you need to take extra precautions.

 

[morganAL]

I actually acquired a 500M mobile that someone had removed a resistor that was between the modulator and transmitter. Even if the Tx came up, it could NOT transmit the HSD. The only problem I can see with hex editing and assigning a LID over 16383 would be if you were monitoring an EDACS Extended Addressing system which can have over one million LIDs. However the only EA system I know is the State of Florida and it is all encrypted anyway so not really an issue.

 

[ElroyJetson]

There's a question: If you were to enable Extended Addressing while listening to a standard (Non-EA) system, would it receive properly?

I haven't tried that.

I'm not SURE about this, but my belief at the moment is that if a given radio were given an inhibit command, if it doesn't handshake with the controller and acknowledge the inhibit command successfully, it won't inhibit. That's why I'm wondering about messing with the TX frequency offset via an SC4 file. I'm THINKING that the radio's inability to actually exchange messages with the controller would keep the radio from being able to be inhibited. Can you shed any light on that?

Also, what's this about a stolen radio message every 10 seconds? Info, please.

Elroy

 

[Radioman96p71]

I can answer the last 2 questions, If you run the program TrunkMon and check the last tab for system properties. It will show all disabled radios on the system and the flag set to them, around here they are all set to STOLEN_RADIO. Maybe thats the default, not sure. But if you watch the update interval, it happens every 10 seconds.

Also, a radio programmed to the LID of a STOLEN_RADIO will become locked and start TXing with an open mic, regardless if the transmitter is enabled or not. The only way to stop it is to clear the radio with Radio Maint and start from scratch.

No idea about the EA, as its not implemented here.

 

[EnidPuceflange]

There's a question: If you were to enable Extended Addressing while listening to a standard (Non-EA) system, would it receive properly?

I haven't tried that.

I'm not SURE about this, but my belief at the moment is that if a given radio were given an inhibit command, if it doesn't handshake with the controller and acknowledge the inhibit command successfully, it won't inhibit. That's why I'm wondering about messing with the TX frequency offset via an SC4 file. I'm THINKING that the radio's inability to actually exchange messages with the controller would keep the radio from being able to be inhibited. Can you shed any light on that?

Also, what's this about a stolen radio message every 10 seconds? Info, please.

Elroy

The answer to the EA/non-EA question is "yes" - the site ID message over-the-air is the same format, but indicates the protocol, so the radios auto-detect and switch. That was needed because they rolled Florida out as regular EDACS and converted it when it was up and running.

If a radio receives the "die now" message it'll die, period. The response back to the site simply means that the site removes the "die" message from it's queue and no longer sends it out. It only sends one (unacknowledged) response back, so it's quite possible the site will miss it. And that probably explains the "stolen radio" message thing too - as part of the background messages on the control channel there are a series of radio disable messages, repeated over and over until the radio gets killed or the system admin removes the radio from the death list.

 

[ElroyJetson]

So, one way to make a radio completely "safe" for scanner use is to set up the whole (regular) EDACS system as an EA system and assign a LID above 65535. The regular EDACS system won't ever know it's there or even be able to find it. Unkillable, and unworkable. But it makes a perfect scanner.


Very interesting indeed.


Elroy

 

[edacsmaster]

radio as edacs scanner

on the J7100 that I have all I did was to disconnect the dc power to the PA deck
along with TX disable.
and using or programming the radio with systems test radio LID.
J,

 

[EnidPuceflange]

So, one way to make a radio completely "safe" for scanner use is to set up the whole (regular) EDACS system as an EA system and assign a LID above 65535. The regular EDACS system won't ever know it's there or even be able to find it. Unkillable, and unworkable. But it makes a perfect scanner.


Very interesting indeed.


Elroy

Sorry, but there are 2 LIDS - one for EA and one for EDACS. Depending on the protocol it chooses which one to use. That's not going to work.

If it were me, I think I'd chose a LID that was below 63, which is where all the system LIDs usually live.

 

[ElroyJetson]

So you're saying that an EA system MUST have a standard address LID in additional to an EA LID?


If that's how it works, I guess I should warm up the soldering iron and yank the PA driver.


Elroy

 

[EnidPuceflange]

So you're saying that an EA system MUST have a standard address LID in additional to an EA LID?


If that's how it works, I guess I should warm up the soldering iron and yank the PA driver.


Elroy

Yep, that's how it works. The reason was that the State of Florida system was rolled out as EDACS, and only later converted to EA, so the radio code had to work on both, and switch seamlessly.

If you're planning on doing some soldering to make it safe, why not remove the write enable line on the EEROM chip?

 

[mitaux8030]

why not remove the write enable line on the EEROM chip?

I guess that'd be fine if you never plan to change the config again and to never alter your scan groups or other such operator selectable variables - I'm pretty sure they get updated 'live' to the EEPROM too. Or does the EEPROM contents get dumped into a page of RAM and the RCP process operate on RAM during operation, only to later write any necessary changes to EEPROM eg during power down or a reset? Never delved that deep into the RCP/ICP or more modern equivalent processes.

One other thought... would disabling EEPROM write cause any self-diagnostic power up test to fail?

But some sort of write inhibit and some sort of TX disable (wether by the original proposal via an SC4 modification or by hardware modification) would be a robust method to keep a terminal off the radar while prolonging its utility as a receiver.