At 00:50 18-06-05 -0400, you wrote: >Chris Liechti wrote: >> as i mentioned in the other mail, i'm working on a simiar loader. >> i've made two special linker scripts: >> - one for the updater that only uses the top 2kB of the flash >> - the other for the application, which cuts away the top 2kB flash and >> moves the interrupt vectors 2kB lower > >This redirection of the interrupt vectors seems like a bad idea from a >security standpoint. It would be really easy to guess what the TI BSL >password is - at least for anyone who's seen your post. > >Circumventing all the TI security problems is the major reason I'm >writing this BSL. Even if the supplied BSL had the ability to handle >decryption, once you've sent that password over the serial line you got >trouble. One could easily intercept that by putting a device inline >that buffers and analyzes the communications. Once they see the
If the encryption method is a proper one, you would not be able to decode the password. It would be nice if the BSL would be able to store an encryption key in the device. >password, they take over, send the password and read out all your code. > Another hole: if you erase segment 0 and you're configured in such a >way that the TI BSL can be invoked... It would be tricky to know >exactly when you've done that, but I think it is possible to make a good >guess by counting command packets - it's bound to be close to the first >or last packet. I'm thinking I can avoid this by configuring the NMI >pin so the BSL cannot be invoked, at least during the rewrite of segment 0. AFAIK it is always possible to invoke the BSL at device startup. But you do have a good point... If you want so secure your firmware, you should not reprogram the interrupt vectors. Nico Coesel
