[chirp_devel] How to brick an FT-60

[chirp.cordless at xoxy.net]

On Mar 22, 2014, at 5:51 PM, Dan Smith - dsmith at danplanet.com wrote:
>> If I can download from the radio and upload the same file and do this,
>> that's a little scary.
> 
> Well, it sounds like it's not 100% clear that that's what happened, and
> like you, I can't imagine that actually causing a problem.

Well, for anyone still interested, there is a new piece of data.

I realized there _is_ a telltale in the image file as to whether it was
modified - the checksum. Chirp does not modify the checksum in
the .img file after editing and saving. The checksum is recomputed
on the fly on upload, so it's not like the radio will see a bad checksum
as a result, but there's info in the file as to whether it was likely edited.

So I slapped together a tool to compute checksums on FT60 .img
files and compare to what's in the file. Tested it by tweaking a bit in
a file, and it behaves as expected.

BrickMaker.img checksums don't match.
So there you go, and I think that increases the probability that it _is_
the bits. Still just guesses and probabilities...

The computed checksum is 0xC5 vs saved 0x95, which would be consistent
with changing some data field from -001----b to -100----b somewhere in the file.
Or something equivalent, of course. But sorry, that was Feb 7, and I can't
remember what that might have been. Maybe I'll stare at the file and see if
there's any inspiration there. But it's a plausible thing for me to have done
early in this process.

Some statistics: Of 248 .img files in the  directories where I'm
saving these, my tool says 21 checksums don't match. I did do some
poking around in the Browser tool exploring the ability to modify bits.
And some uploading to the radio to make sure the whole proposition
of editing settings is feasible. And some of them might just be normal
Memory channel edits. I didn't think I'd saved 21 edited files, but it's been
almost two months, and that's what it looks like, unless I'm missing something.


> However, the
> way most Yaesus do (or don't do) their checksums, it's easy for a bad
> cable or connector to corrupt data on the way in without the radio
> knowing. By the time the radio gets to the end and determines that the
> checksum is wrong, the bad data is already in place. If it's not going
> to do a full reset (automatically or when asked), then a bad cable could
> absolutely end up with you getting broken data into the radio.
> 
> I'm sure you're not looking for any sarcastic remarks here, but if
> anything, the above makes me even less likely to spend money on Yaesus
> in the future. I know brand loyalty is based on lots of things, and
> people choose radios based on a lot more than what is under the hood,
> but honestly, bricking a radio through the user-accessible serial port
> should *not* be possible, IMHO.

As a retired design engineer, I agree most emphatically. If that's
actually what happened, it's really not excusable. Refuse to boot and
require a RESET-ALL is reasonable if the checksum is wrong or the
data is internally inconsistent, but unrecoverable bricking for corrupted
flash data that can be reloaded with factory defaults is not.

As I said in another reply:
- The new radio has gone back to Yaesu. Chirp wasn't mentioned.
No further decisions until I see where that goes.

- I've ordered another cable from Valley Enterprises. Cheap insurance
in case it's a bad cable, or at least it might provide more data.

Thanks and regards,

-dan