Dale Cunningham 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.
yes. the password is weaker. but i can use numbers from the entire 2kB
flash i reserve for the boot loader. interrupt 16 isn't used, i can
write there any number i want. and my redirection table does not need to
be sorted, it can have any order.
as i'm using my own loader, i'm using also different IOs. there is no
way to activate the ROM BSL without opening the device and connecting
wires to the other pins.
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
password, they take over, send the password and read out all your code.
i don't need to transmit the password. a mass erase command only erases
the application and not the bootloader itself. but i don't plan to
encrypt the data anyway.
(if i used a password, it would be the one of the application, not the
one of the boot loader)
if you realy want to encrypt the data, then some asymmetric algorithm
with private and public key would be good. each device could have it's
own private key, so that you can sell the updates per device.
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 don't plan to erase segment 0, so that no concern for me.
> 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.
the NMI function is only active once. a second pulse is a reset, unless
you reconfigure the pin to NMI in the NMI interrupt service routine. i
guess there is no way to ensure that this is done fast enough if someone
unsolders your chip and connects it to his own circuit.
Oh, BTW it's seems like I'm wrong about the TI BSL loading itself into
RAM - couldn't find it again in the docs.
it isn't copied to RAM . it runs directly from the built in ROM.
but there are "replacement BSLs" that allow higher baudrates and fix
some bugs of BSL version 1.1. these are often used with F14x devices.
they are loaded into RAM and executed from there.
chris
