[chirp_devel] [PATCH] [UV-5R] Prevent image upload when "special block" doesn't match
# HG changeset patch # User Jim Unroe rock.unroe@gmail.com # Date 1405559320 14400 # Node ID b56d639ab6ab343d5e00b2480c60d4516929987a # Parent 3bab2acc2cf68e735e48138bf4871c2cd3fed85a [UV-5R] Prevent image upload when "special block" doesn't match
add code to compare the data image "special block" to the radio image "special block" and abort the upload if they don't match
#1773
diff -r 3bab2acc2cf6 -r b56d639ab6ab chirp/uv5r.py --- a/chirp/uv5r.py Mon Jul 14 20:10:30 2014 -0400 +++ b/chirp/uv5r.py Wed Jul 16 21:08:40 2014 -0400 @@ -369,6 +369,16 @@ print "_firmware_version_from_image: " + util.hexprint(version) return version
+def _special_block_from_data(data, special_block_start, special_block_stop): + special_block_tag = data[special_block_start:special_block_stop] + return special_block_tag + +def _special_block_from_image(radio): + special_block = _special_block_from_data(radio.get_mmap(), 0x0CFA, 0x0D01) + if CHIRP_DEBUG: + print "_special_block_from_image: " + util.hexprint(special_block) + return special_block + def _do_ident(radio, magic): serial = radio.pipe serial.setTimeout(1) @@ -436,6 +446,11 @@ version = block[48:64] return version
+def _get_radio_special_block(radio): + block = _read_block(radio, 0xCF0, 0x40) + special_block = block[2:9] + return special_block + def _ident_radio(radio): for magic in radio._idents: error = None @@ -488,13 +503,22 @@
image_version = _firmware_version_from_image(radio) radio_version = _get_radio_firmware_version(radio) - print "Image is %s" % repr(image_version) - print "Radio is %s" % repr(radio_version) + print "Image Version is %s" % repr(image_version) + print "Radio Version is %s" % repr(radio_version)
if not any(type in radio_version for type in BASETYPE_LIST): raise errors.RadioError("Unsupported firmware version: `%s'" % radio_version)
+ image_special_block = _special_block_from_image(radio) + radio_special_block = _get_radio_special_block(radio) + print "Image Special Block is " + util.hexprint(image_special_block) + print "Radio Special Block is " + util.hexprint(radio_special_block) + + if image_special_block != radio_special_block: + raise errors.RadioError("Image not supported by radio: `%s'" % + radio_special_block) + # Main block for i in range(0x08, 0x1808, 0x10): _send_block(radio, i - 0x08, radio.get_mmap()[i:i + 0x10])
[UV-5R] Prevent image upload when "special block" doesn't match
add code to compare the data image "special block" to the radio image "special block" and abort the upload if they don't match
How would we ever change the special block if we can't upload it if it's different?
--Dan
On Fri, Jul 18, 2014 at 5:18 PM, Dan Smith dsmith@danplanet.com wrote:
[UV-5R] Prevent image upload when "special block" doesn't match
add code to compare the data image "special block" to the radio image "special block" and abort the upload if they don't match
How would we ever change the special block if we can't upload it if it's different?
--Dan
Nothing in is area of memory has ever been mapped to any settings. I have no idea what this area is used for. We've never had to change any of it for anything before.
All I know for sure is if you copy these 7 bytes from a KT-980HP or BF-F8HP CHIRP image to any other UV-5R variant radio, the receiver is disabled. It is actually 4 bytes (2 sets of 2 separated by 3 bytes) that cause the issue. I could check each pair independently and abort if either pair doesn't match. That would minimize the number of bytes affected.
Uploads of images could be prevented when the firmware versions don't match. But that would prevent some 16 (and growing) firmware versions that can currently share a common .img file to no longer be able to do it.
I'm definitely open to doing this some other way. Have you got any ideas or suggestions?
Thanks, Jim
Nothing in is area of memory has ever been mapped to any settings. I have no idea what this area is used for. We've never had to change any of it for anything before.
Hmm, I thought there were some band limits in there or something, no? There's some reason we're uploading it, because it wasn't in my initial implementation.
Regardless, it doesn't seem useful to upload it only if it's the same as what is there. If we're uploading the exact thing, why not just not upload it?
--Dan
On Fri, Jul 18, 2014 at 6:24 PM, Dan Smith dsmith@danplanet.com wrote:
Nothing in is area of memory has ever been mapped to any settings. I have no idea what this area is used for. We've never had to change any of it for anything before.
Hmm, I thought there were some band limits in there or something, no? There's some reason we're uploading it, because it wasn't in my initial implementation.
The Aux block has the band limits. The location in memory of the band limits changed when BFB291 was introduced. This caused some undesired issues so since then the upload of the Aux block is aborted when the firmware versions are different.
This new issue is in the Main block. The main block has always been considered to be safe to upload across all models of UV-5R variants. Now it isn't.
Regardless, it doesn't seem useful to upload it only if it's the same as what is there. If we're uploading the exact thing, why not just not upload it?
If the bytes match, the image is being uploaded to the correct radio. If the bytes do not match, the image is being uploaded to the wrong radio and it must be aborted. Isn't that what is always done at the start of the upload clone process? Check to make sure the right radio is on the other end of the programming cable.
The only difference here is the bytes that are being used to detect the radio model are also the bytes that better not be copied to the wrong radio.
Look at the attached file. What I am trying to avoid uploading images from the bottom two rows/models to the top 18 rows/models. It is no different than not being able to upload an image from a UV-5R to a UV-82 or a UV-82 image to a UV-5R. Fortunately with those models, Baofeng change the "ident" between the two. In this case the "ident" is the same.
UV5R_MODEL_291 = "\x50\xBB\xFF\x20\x12\x07\x25"
--Dan
Jim
The Aux block has the band limits. The location in memory of the band limits changed when BFB291 was introduced. This caused some undesired issues so since then the upload of the Aux block is aborted when the firmware versions are different.
This new issue is in the Main block. The main block has always been considered to be safe to upload across all models of UV-5R variants. Now it isn't.
Sorry, when you called it the special block, I thought you mean the aux block, and I thought you were referring to our selective uploading of that if the model/firmware matched. I get the picture now ;)
--Dan
On Fri, Jul 18, 2014 at 7:10 PM, Dan Smith dsmith@danplanet.com wrote:
The Aux block has the band limits. The location in memory of the band limits changed when BFB291 was introduced. This caused some undesired issues so since then the upload of the Aux block is aborted when the firmware versions are different.
This new issue is in the Main block. The main block has always been considered to be safe to upload across all models of UV-5R variants. Now it isn't.
Sorry, when you called it the special block, I thought you mean the aux block, and I thought you were referring to our selective uploading of that if the model/firmware matched. I get the picture now ;)
--Dan
I appreciate you watching my back. ;)
I struggled with what to call this 16 byte area. I didn't know if "chunk" would be better than "block". Not knowing exactly what it was used for I didn't know what to name it so I just used "special".
Jim
participants (2)
-
Dan Smith -
Jim Unroe