Re: Has anyone fully decoded the X9000 memory mapping?
I sent you a private message with some brainstorming. Mostly a big old,? "can of worms" .
|
Re: Has anyone fully decoded the X9000 memory mapping?
You got it. I have been having a time trying to follow all the conversations but it seems we are on the same page. I am in no way saying my ideas are the best and I appreciate all the different view points.?
|
Re: Has anyone fully decoded the X9000 memory mapping?
In rereading your comments, I think I do have a better understanding.
1) Code plug content emulation within the radio unit.
2) Replacement control head
I agree with those premises.
Please expand on your ideas. Thanks? Joe
toggle quoted message
Show quoted text
On Sat, Jul 30, 2022 at 03:42 AM, Casey Crane wrote:
I get the feeling nobody understands what I'm trying to do.?
On Sat, Jul 30, 2022, 01:13 RFI-EMI-GUY < rhyolite@...> wrote: Apart from the lack of FPP , worn parts , bulky cable and the aged VFD display problems, the OEM control head is functionally adequate. Radio codeplug emulation would be a great ehancement if it could eliminate the DOS RSS stranglehold. It should be mentioned however, the OEM control head codeplug also requires the DOS RSS to modify labels, activate buttons, etc.? this is why I suggested an Android control head solution. Of course there are other control head projects that use Arduino, Pi, etc. Such a solution should have a form factor that facilitates the mobile environment, large screen, big buttons, durability. A tiny screen, though functional and nifty, would be a hazard in mobile use. Especially with my tired eyes.
On Fri, Jul 29, 2022 at 09:38 PM, swguest wrote:
I've not ever seen anything but pics of a KXJ or the Crypto module, but that has been my understanding as well, a properly jumpered KEJ + module installed and CP configured as such will do encryption.
I dont recall any mention of SP firmware to support encryption but I do see places in the RSS that need to configire the CP so the radio knows (and expects) that HW to be present.
The /WE confusion was mine. The KVL port /WE line signals (somehow, I dont know/never paid attn to what the KVL lines do on the radio's side of the connector) the uC of it's presence.
Re-digesting you post, the concern was the that the SB9600/CH support to indicate and control the encryption mode would be included in a CH substitution project.
I dont see the CH being eliminated, While it is lacking (from our perspective anyway) replicating it's function/compatibility to handle the workload it does just for a few wish list items would be quiet an undertaking.
OTOH, the EEPROM emulation upgrade would be a parallel system focused on controlling all combo's of tx/rx freq & PL, even scan and Zones(banks)
and
//begin mini rant
? Fix one of my biggest peaves with Moto CPS -? the ability to link/daisychain zones into a continous, dtnamic scanlist
//end mini rant ?
Anyway lots of potential/lots of ideas....hopfully we'll get something? cooking.
|
Re: Has anyone fully decoded the X9000 memory mapping?
I downloaded Mototools, but haven't done anything with it since it's a Windoze EXE file. I don't have a RIB and radio hooked up yet. I did find my RIB and a spare Spectra tray. You are correct that I don't have an X9000. I took a quick look on ebay, but didn't find anything impulsive buy worthy. Frankly I'm trying to empty my garage and not fill it. I gave away most of my Syntors years ago. 73's Skip WB6YMH p.s. swguest what's your name/handle ??? On Fri, Jul 29, 2022 at 8:35 PM swguest via groups.io <swguest@...> wrote:
I did see that GitHub page a while back. I never got around to settin up the Python VM to play around with.
I have an x86 proggy called GM1200 that the GUI looks similar to an MCS 2000 CH. Never really got the thing to behave properly.
I try to collect all related stuff I find but somehow I missed that checksum proggy of Sandy's.There was a time that finding the SB9600 command string checksum was the rage. I did put his Free Ham version SprogII proggy up on the Yahoo group. I see it made it over here.
The Mototools did post to the files and does the packet checksum. Did you ever get it?
Are you doing this via your Spectra or an X9000? I thought I saw you post you dont have an X9000. You need to remedy that Muy Pronto...lol
If you plan to reverse engineer the SB9600 R/W coms, let me suggest he following-
For an X9000, RSS R8.01, runs well on a pentium machines,even in an Win98 to Win7 cmd window. I've never tried R/W from the cmd Window, Windoze is very picky about sharing it's com ports. I think DOSbox is prolly a better platform to I/O inside of Windoze.
Anyway, If you can get any RSS to do R/W under Windoze that Mototools program is an excellent com port snoop program, with logging. You might have to config some virtual serial ports to get Windoze to let you connect 2 proggys to one com source. After a lot of trying, I made it work but but I'll be damned if I recall how. I had a free to HAMs version of VSPM. I'll try to see if I can locate it.
Dont forget to eat and maybe shave every few days............
|
Re: Has anyone fully decoded the X9000 memory mapping?
I get the feeling nobody understands what I'm trying to do.?
On Sat, Jul 30, 2022, 01:13 RFI-EMI-GUY < rhyolite@...> wrote: Apart from the lack of FPP , worn parts , bulky cable and the aged VFD display problems, the OEM control head is functionally adequate. Radio codeplug emulation would be a great ehancement if it could eliminate the DOS RSS stranglehold. It should be mentioned however, the OEM control head codeplug also requires the DOS RSS to modify labels, activate buttons, etc.? this is why I suggested an Android control head solution. Of course there are other control head projects that use Arduino, Pi, etc. Such a solution should have a form factor that facilitates the mobile environment, large screen, big buttons, durability. A tiny screen, though functional and nifty, would be a hazard in mobile use. Especially with my tired eyes.
On Fri, Jul 29, 2022 at 09:38 PM, swguest wrote:
I've not ever seen anything but pics of a KXJ or the Crypto module, but that has been my understanding as well, a properly jumpered KEJ + module installed and CP configured as such will do encryption.
I dont recall any mention of SP firmware to support encryption but I do see places in the RSS that need to configire the CP so the radio knows (and expects) that HW to be present.
The /WE confusion was mine. The KVL port /WE line signals (somehow, I dont know/never paid attn to what the KVL lines do on the radio's side of the connector) the uC of it's presence.
Re-digesting you post, the concern was the that the SB9600/CH support to indicate and control the encryption mode would be included in a CH substitution project.
I dont see the CH being eliminated, While it is lacking (from our perspective anyway) replicating it's function/compatibility to handle the workload it does just for a few wish list items would be quiet an undertaking.
OTOH, the EEPROM emulation upgrade would be a parallel system focused on controlling all combo's of tx/rx freq & PL, even scan and Zones(banks)
and
//begin mini rant
? Fix one of my biggest peaves with Moto CPS -? the ability to link/daisychain zones into a continous, dtnamic scanlist
//end mini rant ?
Anyway lots of potential/lots of ideas....hopfully we'll get something? cooking.
|
Re: Has anyone fully decoded the X9000 memory mapping?
Apart from the lack of FPP , worn parts , bulky cable and the aged VFD display problems, the OEM control head is functionally adequate. Radio codeplug emulation would be a great ehancement if it could eliminate the DOS RSS stranglehold. It should be mentioned however, the OEM control head codeplug also requires the DOS RSS to modify labels, activate buttons, etc.? this is why I suggested an Android control head solution. Of course there are other control head projects that use Arduino, Pi, etc. Such a solution should have a form factor that facilitates the mobile environment, large screen, big buttons, durability. A tiny screen, though functional and nifty, would be a hazard in mobile use. Especially with my tired eyes.
toggle quoted message
Show quoted text
On Fri, Jul 29, 2022 at 09:38 PM, swguest wrote:
I've not ever seen anything but pics of a KXJ or the Crypto module, but that has been my understanding as well, a properly jumpered KEJ + module installed and CP configured as such will do encryption.
I dont recall any mention of SP firmware to support encryption but I do see places in the RSS that need to configire the CP so the radio knows (and expects) that HW to be present.
The /WE confusion was mine. The KVL port /WE line signals (somehow, I dont know/never paid attn to what the KVL lines do on the radio's side of the connector) the uC of it's presence.
Re-digesting you post, the concern was the that the SB9600/CH support to indicate and control the encryption mode would be included in a CH substitution project.
I dont see the CH being eliminated, While it is lacking (from our perspective anyway) replicating it's function/compatibility to handle the workload it does just for a few wish list items would be quiet an undertaking.
OTOH, the EEPROM emulation upgrade would be a parallel system focused on controlling all combo's of tx/rx freq & PL, even scan and Zones(banks)
and
//begin mini rant
? Fix one of my biggest peaves with Moto CPS -? the ability to link/daisychain zones into a continous, dtnamic scanlist
//end mini rant ?
Anyway lots of potential/lots of ideas....hopfully we'll get something? cooking.
|
Re: Has anyone fully decoded the X9000 memory mapping?
I did see that GitHub page a while back. I never got around to settin up the Python VM to play around with.
I have an x86 proggy called GM1200 that the GUI looks similar to an MCS 2000 CH. Never really got the thing to behave properly.
I try to collect all related stuff I find but somehow I missed that checksum proggy of Sandy's.There was a time that finding the SB9600 command string checksum was the rage. I did put his Free Ham version SprogII proggy up on the Yahoo group. I see it made it over here.
The Mototools did post to the files and does the packet checksum. Did you ever get it?
Are you doing this via your Spectra or an X9000? I thought I saw you post you dont have an X9000. You need to remedy that Muy Pronto...lol
If you plan to reverse engineer the SB9600 R/W coms, let me suggest he following-
For an X9000,? RSS R8.01, runs well on a pentium machines,even in an Win98 to Win7 cmd window. I've never tried R/W from the cmd Window, Windoze is very picky about sharing it's com ports. I think DOSbox is prolly a better platform to I/O inside of Windoze.
Anyway, If you can get any RSS to do R/W under Windoze that Mototools program is an excellent com port snoop program, with logging. You might have to config some virtual serial ports to get Windoze to let you connect 2 proggys to one com source. After a lot of trying, I made it work but but I'll be damned if I recall how. I had a free to HAMs version of VSPM. I'll try to see if I can locate it.
Dont forget to eat and maybe shave every few days............
|
Re: Has anyone fully decoded the X9000 memory mapping?
Yes the time sink is working well I found a backup of the RSS & code plug data, but the machine I used is long gone. I was able to get RSS running under Dosbox with a dummy serial port so I could at least view the code plug data. Now I'm thinking of writing an Spectra / X9000 emulator that will talk to the Dosbox's serial port. Kind of reverse logic, but if I can make it work then it would be "easy-ish" to make one change with RSS, save it and then see what changed in the image. I know RSS was super picky about timing and clock speed so I'm not super hopeful, but I'm going to mess around with the idea for a while. I also found a couple of other SB9600 projects: (GM1200) (XTL) Checking the reverse engineered CRC against the protocol manual I found "The details of the CRC calculation is not contained in this document. Interested individuals with a ”need to know” should contact the World Wide Radio Product Group of the Land Mobile Products Sector for additional information." Got to love that one! 73's Skip On Fri, Jul 29, 2022 at 7:12 PM swguest via groups.io <swguest@...> wrote:
Well Skip,
Did that SB9600 pursuit pull you into a time dialation void as predicted?
|
Re: Has anyone fully decoded the X9000 memory mapping?
Well Skip,
Did that SB9600 pursuit pull you into a time dialation void as predicted?
|
Re: Has anyone fully decoded the X9000 memory mapping?
I've not ever seen anything but pics of a KXJ or the Crypto module, but that has been my understanding as well, a properly jumpered KEJ + module installed and CP configured as such will do encryption.
I dont recall any mention of SP firmware to support encryption but I do see places in the RSS that need to configire the CP so the radio knows (and expects) that HW to be present.
The /WE confusion was mine. The KVL port /WE line signals (somehow, I dont know/never paid attn to what the KVL lines do on the radio's side of the connector) the uC of it's presence.
Re-digesting you post, the concern was the that the SB9600/CH support to indicate and control the encryption mode would be included in a CH substitution project.
I dont see the CH being eliminated, While it is lacking (from our perspective anyway) replicating it's function/compatibility to handle the workload it does just for a few wish list items would be quiet an undertaking.
OTOH, the EEPROM emulation upgrade would be a parallel system focused on controlling all combo's of tx/rx freq & PL, even scan and Zones(banks)
and
//begin mini rant
? Fix one of my biggest peaves with Moto CPS -? the ability to link/daisychain zones into a continous, dtnamic scanlist
//end mini rant ?
Anyway lots of potential/lots of ideas....hopfully we'll get something? cooking.
|
Re: Has anyone fully decoded the X9000 memory mapping?
Here is an example of a Securenet board that would be snapped on top of the personality board and connected via ribbon cable.
I am told that the radio can be either a KXJ (Secure Capable)? or KEJ (Not Secure Capable) and it will work. I can't comment on any experience with KEJ radios. It may take a firmware change but jumpers will need to be changed and the MOD comp touched up.
|
Re: Has anyone fully decoded the X9000 memory mapping?
The specific /WE for the encryption (Securenet Board) KVL loading port is entirely independent of the radio microprocessor. It is only active when attaching a T30XX keyloader to the radio to squirt in a Key Variable.
The SB9600 does control the encryption board to satisfy the control head I/O (buttons and LEDs) , audio routing, -XL and multikey capability from the radio code plug. The radio code plug does have to be programmed to activate the encryption board and features. The radio firmware has to accept the option and if the activated board is subsequently removed, the BITE will report an error temporarily on boot up.
toggle quoted message
Show quoted text
On Fri, Jul 29, 2022 at 07:52 PM, swguest wrote:
Dennis and Joe,
?Thanks for the rundown. Even my simplistic view can make sense of the logical progression as explained.
But back to the question though, the /WE on the KVL plug is not associated with the /WE the uC uses to control writes to the onboard EEPROM, right?
So is a means to toggle it's function needed to keep encryption operational with the freq agile, CH? or other enhancement being kicked around here?
I would think the KVL/Crypto module coms are all stand alone, and could care less what the radio does, as long as it does what it is told w/regard to audio paths in/out of the encryption HW.
|
Re: Has anyone fully decoded the X9000 memory mapping?
Dennis and Joe,
?Thanks for the rundown. Even my simplistic view can make sense of the logical progression as explained.
But back to the question though, the /WE on the KVL plug is not associated with the /WE the uC uses to control writes to the onboard EEPROM, right?
So is a means to toggle it's function needed to keep encryption operational with the freq agile, CH? or other enhancement being kicked around here?
I would think the KVL/Crypto module coms are all stand alone, and could care less what the radio does, as long as it does what it is told w/regard to audio paths in/out of the encryption HW.
|
Re: Has anyone fully decoded the X9000 memory mapping?
Dennis; You are describing the Physical Security option (Syntor X, X9000, Spectra) which was popular for federal users. You are correct that the encryption module is mounted exterior to the radio in the Physical Security option. However, the basic standard secure capable radio sold to state and local and others has the module inside the can on the personality board as I describe above. It is a much simpler neater arrangement that way. The physical security option is a nightmare...
toggle quoted messageShow quoted text
|
Re: Has anyone fully decoded the X9000 memory mapping?
Joe here!
The encryption module has battery backed static ram for the keys so those KVL lines terminate at the encryption module where it writes to the SRAM. The code storage battery comes via J301 Pin 13 from the Common Circuits board where a space rated Eagle Picher lithium ion battery maintains a charge and memory contents for 15 years. If the encryption module, personality board or common circuits board are separated from themselves or from the chassis, the encryption key will be erased.
The encryption module is a daughter board to the personality board and yes the KVL signals pass through the personality board J301 (inside the shield can) and directly to the encryption module which plugs into J301. Hijacking/preferably sharing those lines can occur within an inch or two of the radio code plug.
The encryption modules do reside on the SB9600 for control of audio routing, enabling the encryption, key selection (multi key), reporting activity to the control head (flashing TX and RX indications), reporting key loss, activation of -XL mode (range extension) etc... No encrypted data or key pass through SB9600.
toggle quoted message
Show quoted text
On Fri, Jul 29, 2022 at 07:04 PM, swguest wrote:
Dennis,
? Is that? /WE tied to the EEPROM or does the encryption module have it's own memory to store keys?
If the keys are written to the EEPROM wouldnt that be a potential breach if an unauthorized person read the EEPROM and obtained the keys?
I know nothing of encryption HW or FW, but I would think the KVL would spit the keys straight into the encryption HW as the radio OS doesnt know or care, other than a "route audio circuits thru these paths" command.
Like I said, totally ignorant on the subject. I've never delved into 2 way radio encryption, never had a need to consider it.
|
Re: Has anyone fully decoded the X9000 memory mapping?
The encryption models do route the audio out through the DVP box and
back into the radio for encryption and decryption. The DVP box actually
has a Medeco lock on it, and I'm sure key storage is in there. The KVL
talks to the DVP box.
For the Syntor X, it's jumpers and lots of wires in the cable. For the
9000, I suspect it's done via the SB9600 audio routing stuff.
De
|
Re: Has anyone fully decoded the X9000 memory mapping?
Got it and replied back on the one I reg'd w/my call sign. The other is over-run w/spam. I do still try to maintain it but the weeds grow pretty quickly there these days.
Ehh...Ya get what ya pay for....
|
Re: Has anyone fully decoded the X9000 memory mapping?
 RFI-EMI-GUY OOPS! That encryption reply and question was for you, not Dennis.? Seems to be easy (at least for me) to get lost in this thread Either I've got some setting wrong or 开云体育? doesnt use a poster/reply to format I am accustomed to.
|
Re: Has anyone fully decoded the X9000 memory mapping?
Dennis,
? Is that? /WE tied to the EEPROM or does the encryption module have it's own memory to store keys?
If the keys are written to the EEPROM wouldnt that be a potential breach if an unauthorized person read the EEPROM and obtained the keys?
I know nothing of encryption HW or FW, but I would think the KVL would spit the keys straight into the encryption HW as the radio OS doesnt know or care, other than a "route audio circuits thru these paths" command.
Like I said, totally ignorant on the subject. I've never delved into 2 way radio encryption, never had a need to consider it.
|
Re: Has anyone fully decoded the X9000 memory mapping?
 For reference, the Securenet cable for a Syntor X9000. Thankfully with soft pots in the radio, the control head does not require to much in the way of circuit replication, though its disconnection will likely be detected by the BITE tests in the radio. So any solution will require spoofing the control head address.
|
RFI-EMI-GUY
