450-527 cps hacking to 440?

sglass · Post by **sglass** » Tue Nov 25, 2003 10:42 pm

I'm at a loss here guys

and the page here didn't help me

Anyone hacked cps3.01 for the ht750?

trying to get a 450+ radio to go down to 440

nitornemo · Post by **nitornemo** » Tue Nov 25, 2003 11:21 pm

sglass wrote: ANyone hacked cps3.01 for the ht750

trying to get a 450+ radio to go down to 440

Heh, I asked this awhile ago and to my knowlage no one has done it yet.

I want the reverse, I can find the lower radios everywhere but would love to get them to do the T-Band like my HT1000/Visars and MTS's.

Even if I could "Squeek" 474.xxxx Tx out of them I'd be a happy camper.

If you get a positive answer on this PLEASE DO let me know.

W4WTF · Post by **W4WTF** » Wed Nov 26, 2003 8:10 am

I would love it if someone would do this. my FD has been buying his split radios (450-5whatever) and we have 6 Hams on teh department with more studying now. I would loev to be able to get our local 440 repeater in the radios.

CTAMontrose · Post by **CTAMontrose** » Wed Nov 26, 2003 8:48 am

Ill bet they went with the same scheme for all CPS... i dont have HT750 CPS, but ill fire up the hex editor and see what i can come up with for the CPS i do have.

Post by **wavetar** » Wed Nov 26, 2003 12:35 pm

Not the same scheme at all. The MTS/MCS & Astro CPS was successfully hacked...at least some of the versions were. The HT750/1250 is different, nobody can find where the darn bandsplits are located. They are almost certainly not in the main EXE file, and don't appear to be in any of the installed DLL or other files. If you find anything at all, post it here for all to know.

Todd

CTAMontrose · Post by **CTAMontrose** » Wed Nov 26, 2003 12:56 pm

ahh ok.. i dont have a copy of the 750 cps to play with.. is there a site that talks about the progress made atleast? i would like to see what all they have done, so i dont have to 'reinvent the wheel' so to speak

Sundown · Post by **Sundown** » Wed Nov 26, 2003 3:27 pm

There is a lot of radio capability information stored in the read-only memory of the waris radios. This is a 128 byte area immediately before the codeplug memory that is read by the CPS but not written. It contains things such as the model number string, serial number, number of channels, what features are installed, and I suspect bandsplits, but haven't identified them yet, as I wasn't looking for them.

10-95 · Post by **10-95** » Wed Nov 26, 2003 3:31 pm

Seth, check your PM's, I sent some interesting info for you. let me know how it goes.

Frank

CTAMontrose · Post by **CTAMontrose** » Wed Nov 26, 2003 3:33 pm

does anyone have a codeplug i can play with as well as the info on modding the XTS and MCS CPS?

did anyone submit it to the main site?

Sundown · Post by **Sundown** » Wed Nov 26, 2003 4:42 pm

grem, check PM

CTAMontrose · Post by **CTAMontrose** » Wed Nov 26, 2003 4:51 pm

what im wondering now is if there are 2 ways of doing this:

1. Modify the bandsplits in CPS (the ole fashined way)
2. If there is any bandsplit info in the raw codeplug, perhaps it would be eaiser to modify that to trick CPS into thinking its dealing with a more ham friendly split.

The Pager Geek · Post by **The Pager Geek** » Thu Nov 27, 2003 12:14 am

Post by **wavetar** » Thu Nov 27, 2003 5:07 am

The Pager Geek wrote:There HAS to be a point in the software where it checks for a vaild entry. (otherwise the freq wouldn't get rejected until you try to program the radio)

IF the band split is loaded in the radio, and NOT CPS... the CPS would read the radio and store the split internally. The CPS would have to run a compare routine with the frequency entered against the stored band split read from the radio. For this type, you need to disable the compare.. or rename it.

IF the band split is in the software somewhere, a debugger would help by tracing where in the program something occurs based on an input or memory change (those are examples, many more triggers are possible)

I dunno.. I don't deal with CPS / RSS... just basic programming...

Food for thought

tpg

I have similar thoughts. We know early versions of the CPS had the bandsplits in the GP300.EXE file, not in the radios. Modifying the file enabled you to program ham freqs in the radio, so there was no internal comparison going on within the radios themselves. Since you can still read/write just fine to an HT750 which has firmware version 1.00.00 with the latest CPS, this tells me nothing has changed in that regard...the bandsplits are still located in the CPS...somewhere. I tried using WinDASM32 (Windows debugger/disassembler) on the CPS, but it won't run the CPS after disassembly & I'm not sure why. I've successfully used it with other programs, but am not any kind of guru with it. If someone could get it to run & just see where the CPS looks in order to mark the frequencies invalid, that would be a good start.

Todd

elkbow · Post by **elkbow** » Thu Nov 27, 2003 8:48 am

Todd/TPG...I think you guys are right to a degree. I've been hacking/debugging this morning. I do not believe the bandsplit is stored in the codeplug/radio, I believe there is a translation somewhere in the CPS. I've went through each of the files trying to find a subroutine that points to some of the common, slightly changed data that the model number can be decoded from and then another subroutine to point to the bandsplit. I believe the model number is not stored in a single location, it is spread across addresses, but each model number is decoded in the same area's of the CPS .exe file, meaning that it uses 'banks' of addresses to decode the model number and then relates that to other 'banks' to pull the bandsplit.

If you look at the .exe file for the CPS, newer versions, you can see a structure throughout the program that I believe can be decoded to a model number. The model number of course is listed in the codeplug starting at address: 1C. I cannot see any structure or subroutine the could break this down to bandsplits in the codeplug itself, so the bandsplit has to be in the CPS/program.

Has anyone tried to change the model number in the codeplug and write it back to the radio. I'm only thinking in cases where you would change the whole bandsplit and not part of it and within the same type of radio, i.e. UHF or VHF. I just want to know how the radio reacts and if the bandsplit changes in the configuration menu? This will give us an idea of possible where the bandsplit is stored.

When I get a chance, I'm going to print all of these files and see where the decoding is changed. I also know that you will not see the bandsplit sticking out at you, I'm sure many of us have been through that, it is also decoded by a series of subrountine or changing of the bit structure within the program.

Post by **wavetar** » Thu Nov 27, 2003 12:30 pm

elkbow wrote:Has anyone tried to change the model number in the codeplug and write it back to the radio. I'm only thinking in cases where you would change the whole bandsplit and not part of it and within the same type of radio, i.e. UHF or VHF. I just want to know how the radio reacts and if the bandsplit changes in the configuration menu? This will give us an idea of possible where the bandsplit is stored.

Go to this older thread on the same subject. About halfway down the page, MicorRT was able to modify his codeplug & change the bandsplit (ie: 403-470 to 450-520 or whatever). The CPS didn't seem to mind it, but it gave a model mismatch when trying to write to the radio.

http://batboard.batlabs.com/viewtopic.p ... ht=softice

Todd

elkbow · Post by **elkbow** » Thu Nov 27, 2003 1:07 pm

Hmmm, okay, thanks for the link. When I read that post, I see where people tried to change the model number and where they tried to change the bandsplit, but not change both and write it into the radio. I'm guessing that you will still end up with a 'model mismatch', because the model number changed.

I'll do more searching and maybe try to disassemble the program rather than hex edit it.

jim · Post by **jim** » Thu Nov 27, 2003 3:33 pm

If one would get new (blank) radios of both bandsplits, why not read both codeplugs with hex editer and do a "compare" and find the differences? This could only work on a new radio, possibly.

Post by **wavetar** » Thu Nov 27, 2003 5:06 pm

jim wrote:If one would get new (blank) radios of both bandsplits, why not read both codeplugs with hex editer and do a "compare" and find the differences? This could only work on a new radio, possibly.

If you follow the above, that's pretty much been done. You can change the bandsplit in the codeplug, but the CPS will not dump it into the radio, it finds a mis-match.

Todd

The Pager Geek · Post by **The Pager Geek** » Thu Nov 27, 2003 6:04 pm

Sundown · Post by **Sundown** » Thu Nov 27, 2003 8:27 pm

wavetar wrote:If you follow the above, that's pretty much been done. You can change the bandsplit in the codeplug, but the CPS will not dump it into the radio, it finds a mis-match.

Todd

I believe the problem is in the read-only memory that is in the Waris radios, and I don't believe that changing the model string is sufficient.

Is posting hex values of what I mean here kosher?

sglass · Post by **sglass** » Thu Nov 27, 2003 9:52 pm

The Pager Geek wrote:
I don't have a radio to play "test rat" with... sorry!

tpg

Dude, I'll again offer my radio as the sacrifical lamb

You up for it? No hard feeelings if you kill it.

Seth

The Pager Geek · Post by **The Pager Geek** » Thu Nov 27, 2003 11:50 pm

Sundown · Post by **Sundown** » Sat Nov 29, 2003 10:36 pm

The Pager Geek wrote:Although I agree that the "read only" memory holds model, serial, options, band splits, etc.... the CPS has to have a compare routine SOMEWHERE to allow the user to enter an invalid freq, and have it get flagged as soon as they're done... otherwise you would need constant communication with the radio during CPS programming and editing which is not the case.

Agreed.

Just an FYI - most recent radios have that "untouchable" space before the codeplug. MCS, MTSX series, anything Astro. You will notice when you read the radio with RSS, it shows a certain number of "blocks." When you write to the radio (without making any changes to the codeplug), it is 2 less blocks. This area however isn't "read-only." The rss/cps just doesn't have a need to write there.

Don't suppose you know if writing to this area would doorstop a radio if what you put in wasn't compatible with the radio's firmware, or if the radio gives you a chance to rewrite to it later?

Of course!

OK... The last 40 bytes of RO memory I believe has the radio capability info in it (possibly all stored in the beginning 12 bytes, with the 13th byte being the checksum). The hex values for a 450-527 MHz 4 channel GP328 (asia pac version of HT750 are as follows...

80 09 01 04 05 10 20 00 48 00 04 00 4B 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 26

Compared to the last 40 bytes of a 16 channel GP328, same bandsplit...

80 09 01 10 1D 10 60 55 48 01 10 00 85 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 26

Number of channels is stored in either the 4th or 11th byte (or both), and the rest is capability info, such as signalling systems, emergency etc, but haven't been able to map them out.

So, do any of those values translate into anything that looks like a bandsplit?

The Pager Geek · Post by **The Pager Geek** » Sun Nov 30, 2003 5:09 am

Yes, the "front" of the codeplug is writable. Easily seen with "jamming a codeplug in" or an srecord. You may be able to modify the bits to reflect the changes you want, BUT I'm almost certain that the checksums will have to reflect the changes (obvisously.)

Unfortunately these radios will get corrupted with it's own CPS and original RIB, let alone someone screwing with it.

My guess is the first two bytes are the model reference bytes. Similar to maxtracs and Gp300's, it probably is a 2 bit hex value crossed in the CPS somewhere to diplay the rest of the info...

You will need a radio of the same EVERYTHING (options, etc) but different band split to do an easy comparison...

just a guess...

tpg

Sundown · Post by **Sundown** » Sun Nov 30, 2003 5:10 am

Hmmm... Don't actually think there's sufficient info there to include bandsplits

How about the entire RO mem of the 4 channel:

00000000 00 80 80 52 01 53 45 52 49 41 4C 2D 4E 55 4D 00 ...R.SERIAL-NUM.
00000010 00 48 32 35 53 44 43 39 41 41 32 20 20 20 20 20 .H25SDC9AA2
00000020 20 00 00 01 04 00 19 98 09 09 00 00 02 3A 98 3A ............:.:
00000030 98 76 C0 35 31 52 30 37 30 37 32 41 30 31 52 30 .v.51R07072A01R0
00000040 31 30 34 1F 00 50 4D 55 45 31 35 36 36 41 20 00 104..PMUE1566A .
00000050 00 00 00 00 00 00 04 xx 80 09 01 04 05 10 20 00 .............. .
00000060 48 00 04 00 4B 00 00 00 00 00 00 00 00 00 00 00 H...K...........
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 26 ...............&

Checksum that covers the serial num is at 0x00000057. Didn't bother recalculating with the removal of serial (not written to radio).

So... Anything in there that looks like a 450-527 MHz bandsplit?

Sundown · Post by **Sundown** » Sun Nov 30, 2003 5:22 am

The Pager Geek wrote:Yes, the "front" of the codeplug is writable. Easily seen with "jamming a codeplug in" or an srecord. You may be able to modify the bits to reflect the changes you want, BUT I'm almost certain that the checksums will have to reflect the changes (obvisously.)

Yeah... Pretty sure I've got the checksums figured out. My question was whether if you got the checksums correct, but there was just a parameter that would be valid for a 16 channel, but not for a 4 channel (if indeed they run different firmware), would the radio you write the change to barf unrecoverably if it didn't like the new parameter, or would you have a chance to correct the write, like an invalid codeplug?

Unfortunately these radios will get corrupted with it's own CPS and original RIB, let alone someone screwing with it.

Looking at how it all works, I'm pretty sure that it's recoverable without needing to send to the depot. But willing to stand corrected on this one.

My guess is the first two bytes are the model reference bytes. Similar to maxtracs and Gp300's, it probably is a 2 bit hex value crossed in the CPS somewhere to diplay the rest of the info...

Quite possibly. Or check out the last post of mine with the entire "RO" mem in it. That probably has more model info in it too.

You will need a radio of the same EVERYTHING (options, etc) but different band split to do an easy comparison...

Agreed. Finding one of a diff bandsplit is the challenge! Hoping someone might be able to make sense of what's supplied and see if it looks relevant though.

Oh... And lastly, see if anyone can make sense of the following:

E5 8E C1 54 19 9D 11 D1 80 18 00 60 B0 3C 8A FF

This is the response given by both a 4 channel and 16 channel GP328. Anything interesting (like bandsplits) in there per chance?

The Pager Geek · Post by **The Pager Geek** » Sun Nov 30, 2003 10:41 pm

A few things to help...

I need some codeplugs to compare. CDM1250's / 1550's and HT750's / 1250's / 1550's.... all splits prefered, just clue me in on the split....

tpg

The Pager Geek · Post by **The Pager Geek** » Sun Nov 30, 2003 11:09 pm

This is the top of a codeplug for a CDM1250 146-174 split:

3034 3030 3030 0100 0000 0000 C323 17A9 F07F D211
8D74 0060 B0F1 A94D 4141 4D32 354B 4B44 3941 4132
414E 2020 0000 0000 3130 3354 4441 3837 3333 0000
0000 0000 0000 0000 37

How to calc the checksum? (last byte) Use only part of the above, or all?
My initial attempts aren't producing much...

tpg

Jay · Post by **Jay** » Mon Dec 01, 2003 12:34 am

I emailed you a handful of codeplugs, hope it helps.

Jay

The Pager Geek · Post by **The Pager Geek** » Mon Dec 01, 2003 12:47 am

Following the program thru it's checking routine has been fruitless so far....

It travels thru several .dll's before the checkpoint. Quite frankly I got too tired for it to come....

Files seen:
RDB41.dll
RUD41.dll
PIP41.dll

these were the most frequented... after a brief search of thses 3 dll's.... I have yielded.... NOTHING!

The quest continues...
tpg

Sundown · Post by **Sundown** » Mon Dec 01, 2003 12:49 am

The Pager Geek wrote:This is the top of a codeplug for a CDM1250 146-174 split:

3034 3030 3030 0100 0000 0000 C323 17A9 F07F D211
8D74 0060 B0F1 A94D 4141 4D32 354B 4B44 3941 4132
414E 2020 0000 0000 3130 3354 4441 3837 3333 0000
0000 0000 0000 0000 37

How to calc the checksum? (last byte) Use only part of the above, or all?
My initial attempts aren't producing much...

tpg

OK, this is the top of the codeplug archive file from the CPS itself. This is a CPS generated summary of the RO memory, which is never rewritten to the radio when you write the codeplug.

While this might allow the CPS to select different frequencies in programming, I'm 95% sure based on what else I've seen that the CPS will complain that the radio is a different model when you go to write the codeplug.

The Pager Geek · Post by **The Pager Geek** » Mon Dec 01, 2003 1:19 am

I agree that the CPS will complain... unless you tell it not too.

either A - Jam it in another way not involving CPS, like an srecord force...

or

B - Find the compare in the CPS that bitches about model mismatch...

tpg

Sundown · Post by **Sundown** » Mon Dec 01, 2003 2:55 am

The Pager Geek wrote:I agree that the CPS will complain... unless you tell it not too.

either A - Jam it in another way not involving CPS, like an srecord force...

What's an srecord? And how do you force it?

Wrote a program that sits between the radio and the CPS, that does byte translation and checksum recalculation... Can fool the CPS that the radio is something it's not that way. It wrote the codeplug successfully (yes I checked it), but the radio didn't like it. This was the converting 4 channel to 16 channel exercise. (Suspect that either they have different firmware, or need to write the values that I had translated directly to radio memory).

Wrote another that talks directly to the radio and can manipulate memory, and if you have the raw codeplug (ie not the .cpg file) can write that to the radio itself.

or

B - Find the compare in the CPS that bitches about model mismatch...

tpg

I think there are several :/ I think it checks capability bits as well as model.

ltec123 · Post by **ltec123** » Mon Dec 01, 2003 8:28 pm

Wrote another that talks directly to the radio and can manipulate memory, and if you have the raw codeplug (ie not the .cpg file) can write that to the radio itself

Maybe this program can be used to revive a radio that has the "EEPRM CS ERROR". Since the rss would not write the file codeplug, because it has to read the radio info first then compare it to the file being written.

I would be willing to try it if you want. You will just have to help me
with this "raw codeplug". I only have the codeplug from the rss.

Thanks, LT

Sundown · Post by **Sundown** » Mon Dec 01, 2003 9:10 pm

ltec123 wrote:Maybe this program can be used to revive a radio that has the "EEPRM CS ERROR". Since the rss would not write the file codeplug, because it has to read the radio info first then compare it to the file being written.

Yup, I suspect that it might very well be able to revive a dead radio that the RSS/CPS can't. And without changing the serial number too

I would be willing to try it if you want. You will just have to help me
with this "raw codeplug". I only have the codeplug from the rss.

Currently the program is only written to run under Unix. Porting to Windows shouldn't be too much of an issue with how I've written it though.

Sundown · Post by **Sundown** » Mon Dec 01, 2003 9:15 pm

I also don't know what the legalities are of handing the program around, and it certainly would have the potential to do not very nice things to radios in the hands of someone who didn't know what they were doing...

On a side note, the program should also be able to cover other radios besides the Waris series that also use SB9600.

RADIOMAN2002 · Post by **RADIOMAN2002** » Thu Dec 04, 2003 6:10 am

If you want for comparison I have about 50 factory default codeplugs, for cdm-1550ls+ mobiles and ht-1550xls portables, they are all 450-512 mhz When our FD bought the radios new, I archived all the factory codeplugs for future use if the the radio ever got corupted somehow.

Sundown · Post by **Sundown** » Thu Dec 04, 2003 7:23 am

Sweet

Don't think they'll load in my version of the CPS though (being the AZ (asiapac) version)

But if I end up figuring out the .cpg file format, or a way to extract the raw codeplug data from them, I'll let you know!

Thanks

Sundown · Post by **Sundown** » Thu Dec 04, 2003 7:30 am

Back on topic, how would a frequency be represented in byte form in the codeplug? For example, can anyone tell me the bytes that I would search for in the codeplug that would represent 477.375 MHz?

ltec123 · Post by **ltec123** » Thu Dec 04, 2003 8:39 pm

Back on topic, how would a frequency be represented in byte form in the codeplug? For example, can anyone tell me the bytes that I would search for in the codeplug that would represent 477.375 MHz

Don't know.

You might want to try to compare the data from two different writes to the radio only changing 1 freq.

Sundown · Post by **Sundown** » Thu Dec 04, 2003 8:42 pm

Yeah I know... just had priorities in other areas and was hoping someone could save me the time with their experience of out of banding other radios

CTAMontrose · Post by **CTAMontrose** » Wed Oct 13, 2004 6:25 pm

this project dead?

Hightower · Post by **Hightower** » Thu Oct 14, 2004 3:25 am

After ripping the exe apart, I find that there is a debug mode for the CPS. The exact line for this part of the code:
"Sorry... this button only valid in debug mode. <grin>" I did not add the <grin>, but that text is in the code. hehehehe.
Also in debug mode, there is a item that looks interesting, rather that "write to radio", it says "Blast to radio". Blast to radio feature is only available in debug mode. How to access debug mode, I do not know right now. Something that should be looked into.......

There is also 3 or 4 references to min. freq. and only 1 reference to max freq. Hrmmmmm.

The codeplug is encrypted. Save the exact same read from the radio without changing the name or ANYTHING and it is completely scrambled differently for each read. I wonder what is being used as the seed key and public key, maybe the time on the computer. If this is the case, then generating a decoding algrothm would not be too difficult

Also there are a handfull of DLL's (maybe 9 or so)that are not in the CPS directory. mfc42.dll which is not in the CPS directory is used most of the time the CPS is open and running. The CPS also access the registry. but that looks like its only getting user/company information you typed in when installing the CPS. Thinking that this DLL also has to do with decrypting the codeplug so the CPS can use it.

It's looking more like the only way to hack the bandsplit will be to nop the error code that prevents a write to the radio if it has invalid fields. THis should be possable with a little work, but every version of the CPS would have a different location to nop out, but thats's how it goes.

Its late, going to bed, l8r

Hightower · Post by **Hightower** » Thu Oct 14, 2004 3:32 am

Oh ya, BTW, the bandsplit information is contained in the codeplug, not the .exe. When the CPS is started it gathers this information from the codeplug (min and Max). There is no reference actual bandsplits in the CPS, but rather it collects this informaton from the CP.

So by all rights, if you could decode the codeplug, you could make the radio any band-split you want.

CTAMontrose · Post by **CTAMontrose** » Thu Oct 14, 2004 4:31 am

very interesting..

by the way, the MFC42.dll you referenced is the Microsoft Foundation Class 4.2 dependancy DLL, which is a runtime library (meaning they used VC++ to write it).

that dll is common to other apps as well, so there wouldnt be anything useful for our purposes.

flecom · Post by **flecom** » Wed Sep 13, 2006 6:52 am

Sorry to bump such an old thread but did anyone ever get it to work? I have an HT750 UHF 450-527 that I would like to use on ham...

450-527 cps hacking to 440?

450-527 cps hacking to 440?

Re: 450-527 cps hacking to 440?

.

codeplugs