slicerwizard
Member
And then the displayed network IDs for all Motorola Capacity Max systems will be wrong.
It most certainly does not.
Making our own standalone firmware update
- Thread starter gary123
- Start date
- Status
Ubbe
Member
Isn't US laws very strict about attempting to decrypt anything that are encrypted? Unidens firmwares are encrypted but if it wasn't the only way I have seen it possible to publicly have hacked code availabe are to make a patch program that users can apply to their own copy of the software, so that no modified copyrighted software are available to download.
/Ubbe
/Ubbe
Swipesy
Member
Yes Ubbe. If you recall 2 years ago or so when the GRE/Whistler 800/1080 software incident happened the repercussion to the "modifier were severe.
That would be foolish to attempt.That's a CCI and a restricted device. The only way to gain information on it's design would be to attempt to reverse engineer it. Having one in your possession, without having the proper authorization to posses a CCI, will only garner undue attention from the FBI.
Besides that, those scan terribly slow and that design would make for a horrible scanner.
Last edited:
Prepare to see a lot of "BRICKED" scanners in the classifieds! 
Haven't we been modding Uniden scanners for years? We have been adding GPS modules, speaker mods, Capacitor mods, E, G filter mods, grounding mods, and Serial to USB mods. Not one word from Uniden. Matter of fact, when asked if the SDS100 scanner would have GPS, UPMan stated that he didn't want to take from Jon W's side job.
I thought Harris made a civilian version without the CCI, is that not correct? Obviously a CCI regime has nothing to do with scanners, I was of course referring to the other notable features of Harris Falcon III radios such as ruggedness, SDR based design, dual VCO, support for multiple protocols, high quality hardware that doesn't suffer from intermod and cell tower interference etc, wide bandwidth capacity, FPP capabilities et. all. Basically all the major features minus encryption, which no one designing a scanner or ham radio product would care about.
Frankly I would think the scan speed is an extremely trivial thing that could be easily adjusted in firmware or software in my hypothetical radio.
- Joined
- Jul 1, 2016
- Messages
- 664
None of those are firmware related.
eorange
♦RF Enabled Member♦
Firmware is not the same thing as software. Writing firmware requires a deep understanding of systems architecture and the logical design of the hardware. Without that...it's a hopeless endeavor.
Well a new day has arrived and I see a lot of interesting posts. I will take this opportunity to reply to some of them. If your post is not one of the ones replied to directly please bear in mind we have read all the posts in the thread and they are appreciated.
GTR8000.
You point out one of the biggest hurdles this thread faces. Specifically getting Uniden to provide any level of support. Realistically I think everyone accepts this situation. This really leaves only two options one of which is off the table. First the option that is off the table - go ahead make and release a stand alone version despite Uniden. We are not naïve and as many including yourself have mentioned the ramifications of doing that are terrible. The other option and the one were are most interested in following is to go ahead and identify what needs updating, provide viable solutions and hope that Uniden takes the offered code/solution and uses it to create an official release. This would be more than acceptable by everyone here as that is the ultimate goal.
We am glad you brought up the Erik situation this is exactly why we are being 100% open in what we want to do. This thread was started to determine how we proceed. All the points you and others have made about how Uniden or any other manufacturer will react to a non official file are spot on. We have considered this in detail. We also know that there is no chance of a public release of source code. And yes we agree that would be foolish on Uniden's part for obvious reasons.
pcman67.
We are aware of all the technical details you mention. They have all been considered. It is important for the general membership to be aware that work on this scope is highly specialized. Thank you. If we were to actually be allowed to make our firmware.bin then yes the primary condition would be 100% compatibility with Sentinel and other manufacturers. We planned on a sequential process. First address decoding issues. Next improve existing user parameters. Last add in new user parameters. All of these being done publicly so that feedback from the community directs what is done, when and why.
werinshades.
This is a public project any results would be public and therefore free. We are not doing this for profit we are doing this to get the most out of the hardware. One major factor in getting the most out of it is having the hardware process its supported features with as few errors as possible.
GTR8000.
You point out one of the biggest hurdles this thread faces. Specifically getting Uniden to provide any level of support. Realistically I think everyone accepts this situation. This really leaves only two options one of which is off the table. First the option that is off the table - go ahead make and release a stand alone version despite Uniden. We are not naïve and as many including yourself have mentioned the ramifications of doing that are terrible. The other option and the one were are most interested in following is to go ahead and identify what needs updating, provide viable solutions and hope that Uniden takes the offered code/solution and uses it to create an official release. This would be more than acceptable by everyone here as that is the ultimate goal.
We am glad you brought up the Erik situation this is exactly why we are being 100% open in what we want to do. This thread was started to determine how we proceed. All the points you and others have made about how Uniden or any other manufacturer will react to a non official file are spot on. We have considered this in detail. We also know that there is no chance of a public release of source code. And yes we agree that would be foolish on Uniden's part for obvious reasons.
pcman67.
We are aware of all the technical details you mention. They have all been considered. It is important for the general membership to be aware that work on this scope is highly specialized. Thank you. If we were to actually be allowed to make our firmware.bin then yes the primary condition would be 100% compatibility with Sentinel and other manufacturers. We planned on a sequential process. First address decoding issues. Next improve existing user parameters. Last add in new user parameters. All of these being done publicly so that feedback from the community directs what is done, when and why.
werinshades.
This is a public project any results would be public and therefore free. We are not doing this for profit we are doing this to get the most out of the hardware. One major factor in getting the most out of it is having the hardware process its supported features with as few errors as possible.
slicerwizard.
this is they type of post we have been hoping for. i assume that neither of us want to clutter the thread with technical details yet but what you say should be discussed and clarified. First I apologize for the short simplified code segment. Allow me to expand a bit on it. Also please tolerate few generalities for the membership.
First the firmware processes each data stream separately using decoding code specifically designed for that format. We both know it does not use the P25 code for DMR packets. This is not a secret its essential for the scanner to work right. Having said that we know that a change to DMR will not affect P25 NXDN or any other format UNLESS that code is called.
looking a bit deeper at the string in question and using your post as a reference. Not to throw it in your face it is what we used to identify the issue and find a fix.
The SYSID is the 1100 in the middle of the string (12h). We know that the actual SID is 13. The scanners properly isolate and decode the binary string math as the hex value 12. Unfortunately the system math starts at 0001 and not 0000. To correct the value so it is displayed as the proper 13 we need to change a small part of the code. This code is the part that passes the read (12h) to the "display this value as the the SID" (sorry english is not good for coding). The code needed to do that is a simple add 1 to the value then display it.
NOTE: The code below is based on general programming knowledge and is in C#. We have not decrypted the firmware nor are we even going to think about that without permission.
this is they type of post we have been hoping for. i assume that neither of us want to clutter the thread with technical details yet but what you say should be discussed and clarified. First I apologize for the short simplified code segment. Allow me to expand a bit on it. Also please tolerate few generalities for the membership.
First the firmware processes each data stream separately using decoding code specifically designed for that format. We both know it does not use the P25 code for DMR packets. This is not a secret its essential for the scanner to work right. Having said that we know that a change to DMR will not affect P25 NXDN or any other format UNLESS that code is called.
looking a bit deeper at the string in question and using your post as a reference. Not to throw it in your face it is what we used to identify the issue and find a fix.
The SYSID is the 1100 in the middle of the string (12h). We know that the actual SID is 13. The scanners properly isolate and decode the binary string math as the hex value 12. Unfortunately the system math starts at 0001 and not 0000. To correct the value so it is displayed as the proper 13 we need to change a small part of the code. This code is the part that passes the read (12h) to the "display this value as the the SID" (sorry english is not good for coding). The code needed to do that is a simple add 1 to the value then display it.
NOTE: The code below is based on general programming knowledge and is in C#. We have not decrypted the firmware nor are we even going to think about that without permission.
Code:
read val; <-- actual call code not shown
val = val += 1; <-- added command
write val; <-- actual write code not shownBack to the general discussions.
NOTE: We have not and will not even attempt to decode existing firmware without specific permission. Nor do we intend to discuss anything that may compromise the integrity of the existing firmware files. This thread will not become a how to hack something discussion.
NOTE: Several have asked for a proof of concept. This we cannot provide as that would require decoding, editing and recompiling an exiting firmware. Before we get the "aahhh then your full of **** posts". go back and read all the posts in the thread about the legalities of doing just that. Everything we are doing is going to be done in the open with no BS, no games. As more members come on board with issues they will be discussed and addressed as in the post above. Remember the ultimate goal is to have the firmware updated for the benefit of everyone.
To Uniden: This is a public thread. You like anyone else can take the code posted and use it in any way you choose. We hope that you will use it as intended to upgrade an official release.
NOTE: We have not and will not even attempt to decode existing firmware without specific permission. Nor do we intend to discuss anything that may compromise the integrity of the existing firmware files. This thread will not become a how to hack something discussion.
NOTE: Several have asked for a proof of concept. This we cannot provide as that would require decoding, editing and recompiling an exiting firmware. Before we get the "aahhh then your full of **** posts". go back and read all the posts in the thread about the legalities of doing just that. Everything we are doing is going to be done in the open with no BS, no games. As more members come on board with issues they will be discussed and addressed as in the post above. Remember the ultimate goal is to have the firmware updated for the benefit of everyone.
To Uniden: This is a public thread. You like anyone else can take the code posted and use it in any way you choose. We hope that you will use it as intended to upgrade an official release.
LOL...what did you expect to happen? Lock the thread down, you have your answers, and let's see what you and the group can accomplish.
Jon did state that his GPS modification does void Uniden's warranty. I don't think Paul was concerned for Jon's GPS modification business. It was more like Uniden didn't want to pay Jon for his idea/design. It may be that Jon has a patent on it as well.
WOW. I log in here a couple of times a day and I just saw this thread. And there's already 52+ posts!
Years ago I ripped the digital logic out of a scanner and added my own CPU, firmware, etc. This was the only way back then I could get the features I wanted (still is). I have been designing products, writing firmware, and often software my entire life (well, once it was a thing). Doing this kind of thing is right down my alley. But having said that .....
If (big IF) you can get source code and permission from its owner, great. You're off to the races. I think that is highly unlikely (less than 1% chance). You've clearly stated no 'reverse engineering', so that's off the table.
That leaves you with two choices. One is to abandon the idea (yeah quite sad). The other is to write new firmware from scratch. While the coding, for someone with skills like me, is 'no big deal'; there are tons of issues that you'll encounter. If this was a private transaction among friends and not posted on a public web site, no one will know. But, well, the cat's out of the bag since we have this thread.
Writing the code from scratch, consider these things. You will inevitably have your own bugs. It's most likely you'll have it working in stages (conventional, then MOT trunking, then P25 trunking, etc.). I was working on a similar project a few years ago and what killed it was the licensing. For my project is was Dolby, DVD, TV-Guide, mpeg compression, and a host of others. You see, any licensing that is there now is extended to the present developer and is likely not transferable. You'd be surprised how many things are licensed as there's a lot of "invested interests".
Personally, I wish each Uniden and Whistler would hire dedicated capable firmware (and more) programmers. It doesn't seem to be high on their list of priorities. I think "managers" think the skills to code (low level) firmware is the same as coding a web page (html,+++); which we know is not true. Good luck.
Years ago I ripped the digital logic out of a scanner and added my own CPU, firmware, etc. This was the only way back then I could get the features I wanted (still is). I have been designing products, writing firmware, and often software my entire life (well, once it was a thing). Doing this kind of thing is right down my alley. But having said that .....
If (big IF) you can get source code and permission from its owner, great. You're off to the races. I think that is highly unlikely (less than 1% chance). You've clearly stated no 'reverse engineering', so that's off the table.
That leaves you with two choices. One is to abandon the idea (yeah quite sad). The other is to write new firmware from scratch. While the coding, for someone with skills like me, is 'no big deal'; there are tons of issues that you'll encounter. If this was a private transaction among friends and not posted on a public web site, no one will know. But, well, the cat's out of the bag since we have this thread.
Writing the code from scratch, consider these things. You will inevitably have your own bugs. It's most likely you'll have it working in stages (conventional, then MOT trunking, then P25 trunking, etc.). I was working on a similar project a few years ago and what killed it was the licensing. For my project is was Dolby, DVD, TV-Guide, mpeg compression, and a host of others. You see, any licensing that is there now is extended to the present developer and is likely not transferable. You'd be surprised how many things are licensed as there's a lot of "invested interests".
Personally, I wish each Uniden and Whistler would hire dedicated capable firmware (and more) programmers. It doesn't seem to be high on their list of priorities. I think "managers" think the skills to code (low level) firmware is the same as coding a web page (html,+++); which we know is not true. Good luck.
The last thing I would do is put a firmware made in someone’s basement into my $650.00 scanner. I am sure everyone on the project is smart, but I would not risk bricking my radio and having Uniden tell me I am SOL.
gmclam.
Nice to see your post. It is amazing to see what you miss if you do not live here on the site
We seriously discussed and are still open to the thought of writing something from scratch but realistically its a long term project and comes with its own set of issues beyond debugging and licensing. They start with warranty and go on from there. So for now that is not being perused.
We do know from Joe M's posts that Uniden has its own team of coders. It is starting to look like our best most productive path is to post our own code fixes C# or what ever language is most easily compatible with the firmware and then ask that Uniden take the work and implement it. All coders will immediately be able to understand the concept of take this string, do this with it, and return a result.
AJAT.
Exellent point. This is why everything is out in the open. Its not being done in the basement. No one is ever going to force you to install it. As you have stated " but I would not risk bricking my radio and having Uniden tell me I am SOL" . This shows that should you choose to use such a file you are aware of the risks. Your post gives us hope in the fact that the vast majority of members are fully up to speed on what the goals and pitfalls are.
Nice to see your post. It is amazing to see what you miss if you do not live here on the site
We seriously discussed and are still open to the thought of writing something from scratch but realistically its a long term project and comes with its own set of issues beyond debugging and licensing. They start with warranty and go on from there. So for now that is not being perused.
We do know from Joe M's posts that Uniden has its own team of coders. It is starting to look like our best most productive path is to post our own code fixes C# or what ever language is most easily compatible with the firmware and then ask that Uniden take the work and implement it. All coders will immediately be able to understand the concept of take this string, do this with it, and return a result.
AJAT.
Exellent point. This is why everything is out in the open. Its not being done in the basement. No one is ever going to force you to install it. As you have stated " but I would not risk bricking my radio and having Uniden tell me I am SOL" . This shows that should you choose to use such a file you are aware of the risks. Your post gives us hope in the fact that the vast majority of members are fully up to speed on what the goals and pitfalls are.
Last edited:
All the technical stuff aside, a corporate decision on Uniden's behalf would be made by executive management, and not the technical department. That said, I think Uniden would be loath to relinquish control of it's firmware, even if partially. It would amount to an admission that they lacked the resources or desire to fulfill this function on their own. That might have the effect of damaging the public's perception of Uniden's reliability as a company. The public "advising" Uniden on how they can improve their firmware is the same as your neighbor critiquing your lawn care. If you didn't ask for his advice, you'll tell him what he can do with it.
bob550.
We have been waiting for a post like yours thank you. We are aware of the corporate mentality and understand exactly the point you made and the issues they have to consider. We and we believe the vast majority of customers here and everywhere see it the opposite and they are the ones spending the money that corporate earns.
We see management benefiting from this. They can and will be able to say "we listen to our customers' we care not only about the initial sale but the future enjoyment of our products. They will have the customers support too. We see additional sales because the products are actively supported. These sales not only for Uniden but for other organizations too such as after market software, antenna, accessories even sites like RR. Its a win win for everyone not a loss.
We have been waiting for a post like yours thank you. We are aware of the corporate mentality and understand exactly the point you made and the issues they have to consider. We and we believe the vast majority of customers here and everywhere see it the opposite and they are the ones spending the money that corporate earns.
We see management benefiting from this. They can and will be able to say "we listen to our customers' we care not only about the initial sale but the future enjoyment of our products. They will have the customers support too. We see additional sales because the products are actively supported. These sales not only for Uniden but for other organizations too such as after market software, antenna, accessories even sites like RR. Its a win win for everyone not a loss.
What is the source for financing such a project? Is everyone willing to work for free? How do you protect you work?
- Status
Similar threads
BCD325P2/BCD996P2:
BC_VUP3 unresponsive when trying to update more than one 325P2/996P2
