N8LHG
Member
- Joined
- Dec 6, 2019
- Messages
- 70
ROFL.... Yer' so funny...
Making our own standalone firmware update
- Thread starter gary123
- Start date
- Status
I think thats enough on the encryption issue plus and minus. That is a topic for another and potentially interesting thread. It is off topic for this one.
Last night our group discussed the thread and everything mentioned in it. We have decided to do two things.
One- make a realistic wish list for Uniden of the features we all would like to see. Yes we know its long shot for it to to happen but if you do not put it out there it will never happen.
Two - We are going to move forward on creating a from scratch firmware. For this to happen we need more people. We know our current skill base is not wide enough. So again we ask anyone interested to PM or post interest.
As I have said this is a public thread and to show that we are serious. Here are some of the basics that are being worked on already. Again we thank Mr G for reviewing this list.
- identify the processor used (not hard looking at the hardware will reveal that) 100% legal
- identify the OPcodes used by the processor (computer language) app notes and technical spec sheets will provide that.
- create a block diagram of the code segments needed this is in progress
- write code to execute those steps as a proof of concept using linux or C# (demonstrate that publicly)
- convert the code to the processor commands
- and trouble shoot specifics
The starter plan is not going to look as pretty as the current operation. We intend to literally have a 'turn on in a specific state' with hopefully direct keypad navigation. The same for display. From this we will have basic frequency entry and PL/DPL detection. From there we will be able to build on detecting other wave forms.
One huge note. If the processor is a custom made one of a kind chip used only in scanners and is not available for purchase on the open market we are stopped. Any work on such a chip possibly be considered reverse engineering.
Last night our group discussed the thread and everything mentioned in it. We have decided to do two things.
One- make a realistic wish list for Uniden of the features we all would like to see. Yes we know its long shot for it to to happen but if you do not put it out there it will never happen.
Two - We are going to move forward on creating a from scratch firmware. For this to happen we need more people. We know our current skill base is not wide enough. So again we ask anyone interested to PM or post interest.
As I have said this is a public thread and to show that we are serious. Here are some of the basics that are being worked on already. Again we thank Mr G for reviewing this list.
- identify the processor used (not hard looking at the hardware will reveal that) 100% legal
- identify the OPcodes used by the processor (computer language) app notes and technical spec sheets will provide that.
- create a block diagram of the code segments needed this is in progress
- write code to execute those steps as a proof of concept using linux or C# (demonstrate that publicly)
- convert the code to the processor commands
- and trouble shoot specifics
The starter plan is not going to look as pretty as the current operation. We intend to literally have a 'turn on in a specific state' with hopefully direct keypad navigation. The same for display. From this we will have basic frequency entry and PL/DPL detection. From there we will be able to build on detecting other wave forms.
One huge note. If the processor is a custom made one of a kind chip used only in scanners and is not available for purchase on the open market we are stopped. Any work on such a chip possibly be considered reverse engineering.
Here is a far fetched possibility. Considering this project is an attempt to right some wrongs or correct some errors and defects could it fall under the recently "Right To Repair" efforts?
N8LHG
Member
- Joined
- Dec 6, 2019
- Messages
- 70
AMEN!
iMONITOR.
That is the umbrella that makes such a project possible IF we fall under the provisions of the "Right to Repair ' and not the reverse engineering laws. We brought up that exact question with Mr G. disclaimer for the sidewalk laywers. ***this is not a legal fact its a general informed opinion. many of these laws are stull being defined.
Right to repair currently applies to individuals working on their own property (licenced or not).
Reverse engineering is when a group of individuals get together to change something in a product. Not repair it.
Discussions; 100% legal you can talk about anything you want in generalities and even specifics provided you do not deliberately and with forethought violate or entice other to break known laws. The one exception to this is the small print exception?? You cannot be held liable if you are in violation of some obscure paragraph or legislation not normally in the 'public eye'. For example page 1,537 section 7 subsection 11 paragraph 67 part b... You shall not French kiss a light socket.
That is the umbrella that makes such a project possible IF we fall under the provisions of the "Right to Repair ' and not the reverse engineering laws. We brought up that exact question with Mr G. disclaimer for the sidewalk laywers. ***this is not a legal fact its a general informed opinion. many of these laws are stull being defined.
Right to repair currently applies to individuals working on their own property (licenced or not).
Reverse engineering is when a group of individuals get together to change something in a product. Not repair it.
Discussions; 100% legal you can talk about anything you want in generalities and even specifics provided you do not deliberately and with forethought violate or entice other to break known laws. The one exception to this is the small print exception?? You cannot be held liable if you are in violation of some obscure paragraph or legislation not normally in the 'public eye'. For example page 1,537 section 7 subsection 11 paragraph 67 part b... You shall not French kiss a light socket.
I was looking at writing, from scratch, firmware for an early trunk-tracking hand-held. If I remember correctly, the CPU was WinBond and the units were mass produced with a mask for programming. No field updates.
Identifying the CPU is certainly first. Next is a complete schematic of the hardware. Are there peripherals (like display controller or USB?) and get spec sheets for each of those. This is embedded code, something I usually write in assembly unless it has a great C compiler. If you plan to "update" existing SDS models, you need to seriously look at the boot loader and what's required for the update process to function. Heck, they attempted to keep GRE and Radio Shack code from being interchanged on models which were virtually identical.
Just developing code from scratch that interacts with each IC in the design, and can be uploaded to existing h/w is a huge hurdle. Then add code to make the radio work.
Identifying the CPU is certainly first. Next is a complete schematic of the hardware. Are there peripherals (like display controller or USB?) and get spec sheets for each of those. This is embedded code, something I usually write in assembly unless it has a great C compiler. If you plan to "update" existing SDS models, you need to seriously look at the boot loader and what's required for the update process to function. Heck, they attempted to keep GRE and Radio Shack code from being interchanged on models which were virtually identical.
Just developing code from scratch that interacts with each IC in the design, and can be uploaded to existing h/w is a huge hurdle. Then add code to make the radio work.
gmclam.
Based on general electronics experience. Yes there will be peripherals such as the display diver/bit matrix addressing. It is currently assumed that the CPU passes the desired data either on a parallel set of lines or as a serial stream. We are of the opinion its a stream that is only sent on a 'change of display'. As you have indicated we would have to generate our own output to the display circuitry. That is why I stated the initial offering would not be that pretty. We had already assumed only addressing the minimal display bits until a fully functional set of display criteria were discovered and created.
Another input we are going to have to know is the detected audio and waveform. Again we are assuming its being detected analog and then digitized rather than passing the analog signal directly to the CPU.
Sadly we have to do some of this based on older hardware. Doing too much tracing might be considered reverse engineering. The schematics would certainly be copyrighted. However the basic principals of a receiver are not.
FYI for those not technical these things are used in anything with a display or receiver from your TV to cell phone to a LCD thermometer. Nothing new here.
Based on general electronics experience. Yes there will be peripherals such as the display diver/bit matrix addressing. It is currently assumed that the CPU passes the desired data either on a parallel set of lines or as a serial stream. We are of the opinion its a stream that is only sent on a 'change of display'. As you have indicated we would have to generate our own output to the display circuitry. That is why I stated the initial offering would not be that pretty. We had already assumed only addressing the minimal display bits until a fully functional set of display criteria were discovered and created.
Another input we are going to have to know is the detected audio and waveform. Again we are assuming its being detected analog and then digitized rather than passing the analog signal directly to the CPU.
Sadly we have to do some of this based on older hardware. Doing too much tracing might be considered reverse engineering. The schematics would certainly be copyrighted. However the basic principals of a receiver are not.
FYI for those not technical these things are used in anything with a display or receiver from your TV to cell phone to a LCD thermometer. Nothing new here.
eorange
♦RF Enabled Member♦
This will be the number one hurdle to overcome, especially if there's encryption involved which is very probable. That would mean finding the key from within Sentinel. You should focus on the Hello World test to prove feasibility.
I agree 100% on this.
Sentinel doesn't contain any encryption keys for the firmware. All Sentinel does is retrieves the firmware file from the Uniden server and puts it in the scanner "firmware" folder so when the scanner reboots, the scanner boot loader will read the firmware file.
eorange
♦RF Enabled Member♦
Ah ok. So if the firmware payload is encrypted...then the hardware is doing the decryption. That significantly raises the challenge level to near impossible.
This is not news but thanks for pointing it out. This type of read/decrypt/process is common in just about all electronics like smart TVs, DVD players and cell phones. This is another factor we are aware of. Specifically what code is residing in the CPU. A brand new CPU would come with nothing in RAM. No one would be surprised to find that the CPUs in service are initialized with a basic boot program of some type. Again this is common practice across the electronics industry.
The first step remains identify the processor. That will pull into focus all these issues. If as suspected there are OTW (one time written) sectors before the CPU even is able to wake up then the project is pooched. Pooched because it would be practically impossible to load any firmware other than correctly formatted manufacture generated files.
The first step remains identify the processor. That will pull into focus all these issues. If as suspected there are OTW (one time written) sectors before the CPU even is able to wake up then the project is pooched. Pooched because it would be practically impossible to load any firmware other than correctly formatted manufacture generated files.
So tell me how needing 'right to repair' status helps your project and keeps you legal? You are working on software/firmware which is intellectual property and does not belong to you. You only own the hardware when you bought the scanner. And then you received from Uniden a license to personally use the embedded software/firmware to make the scanner operational. Maybe Mr. G or Mr. T can clarify that for us?
Case Fact just look back at the GRE/WHISTLER event with firmware.
eorange
♦RF Enabled Member♦
There is no more Paul or Wendy nowadays. And barely Joe. Who from Uniden is going to speak up? This might be the event that proves someone is at the wheel...or not.
We may never know.
Legal contact would likely be made to this threads OP directly by someone with Uniden's legal department if Uniden pursues the issue.
eorange
♦RF Enabled Member♦
Probably. To our anonymous usernames 😃
Ironically they'll have no one technical at the helm but plenty of lawyers ready to pounce.
radio3353.
This is a legal set of definitions. We are NOT lawyers so have to speak in generalities based on our understanding. The right to repair allows the owners of the hardware to do repairs on their hardware without being in violation of user agreements. Without that right technically you cant even take the screws out. The right to repair MAY be extended to "I can put whatever software I want into the unit" for MY own personal use. Since we would not be using Uniden's embedded software or firmware??????. Again this depends on post 132 and bootup code and processes.
Everyone here would love to have these issues clarified but so far its such a grey area all we can do is be open so there is no confusion.
kruser.
No threats would be needed. A simple post from Joe saying dont do it would be enough for us to abandon the project. We are not looking for conflict all we want is to improve/fix the firmware for better performance.
Back to new stuff. We are still looking for people to post firmware based requests (option2 in post 89). So far we have
- An advanced mode menu with the abitly to enable disable features on a readio wide basis
- the ability to turn off encrypted mute
- the ability to one step enable/diable all service types (yes disable all could geberate a nothing to scan condition)
- the ability to enable/disable error correction of DMR (yes this will affect RAS)
- the ability to increase audio logging in discovery mode past 600 seconds.
- a quick key finction to enable audio logging on a specifc TG/Channel and allow normal scanning
- the addition of the band scope feature
- a CC mode that improves any TDMA signal capture (slow the sweep speed down?)(only sweep a small defined chunk 1meg?)
This is a legal set of definitions. We are NOT lawyers so have to speak in generalities based on our understanding. The right to repair allows the owners of the hardware to do repairs on their hardware without being in violation of user agreements. Without that right technically you cant even take the screws out. The right to repair MAY be extended to "I can put whatever software I want into the unit" for MY own personal use. Since we would not be using Uniden's embedded software or firmware??????. Again this depends on post 132 and bootup code and processes.
Everyone here would love to have these issues clarified but so far its such a grey area all we can do is be open so there is no confusion.
kruser.
No threats would be needed. A simple post from Joe saying dont do it would be enough for us to abandon the project. We are not looking for conflict all we want is to improve/fix the firmware for better performance.
Back to new stuff. We are still looking for people to post firmware based requests (option2 in post 89). So far we have
- An advanced mode menu with the abitly to enable disable features on a readio wide basis
- the ability to turn off encrypted mute
- the ability to one step enable/diable all service types (yes disable all could geberate a nothing to scan condition)
- the ability to enable/disable error correction of DMR (yes this will affect RAS)
- the ability to increase audio logging in discovery mode past 600 seconds.
- a quick key finction to enable audio logging on a specifc TG/Channel and allow normal scanning
- the addition of the band scope feature
- a CC mode that improves any TDMA signal capture (slow the sweep speed down?)(only sweep a small defined chunk 1meg?)
There are more hurdles here than this group realizes. My approach would be to even write a new boot loader from scratch. Yeah it means the firmware can't be serially transmitted until you've changed the boot loader. But that can eventually be tackled. I had a product where I had to field upgrade the boot loader and was able to do it. This kind of thing is where you can totally brick a product however (unless you connect a hardwired programmer and reload that way).
- Status
Similar threads
BCD325P2/BCD996P2:
BC_VUP3 unresponsive when trying to update more than one 325P2/996P2
