What does the HalfKay bootloader do?

Status
Not open for further replies.
P

Pazi

Well-known member
In 2.0(++) it's just an AVR bootloader. But starting from (ARM-based) 3.0, there have been a separate bootloader chip. I've figured out that this is a tiny (ARM M0 type?) MCU.

I've read that it loads the bootloader code into the main MCU RAM, and the main MCU then runs it from here. Is this correct?
 
As far as i know, this is correct.
China "Teensy 2.0" clones are available at Ebay, Amazon and Alieexpress.

I think, it's to prevent these counterfeits..

But it is better, too - no risk to damage the bootloader with a wrong click... :)
 
Last edited:
I've read that, but if the bootloader chip pushes the bootloader to the ram or the flash, is still not clear. If it's ram, could that program read the existing code from the flash, or is it locked until erased and rewritten?

Could one write a "sketch" that partially rewrites the program flash? In AVR / Arduino world bootloader does just that, but this is different?
 
Pazi said:
I've read that, but if the bootloader chip pushes the bootloader to the ram or the flash, is still not clear. If it's ram, could that program read the existing code from the flash, or is it locked until erased and rewritten?

Could one write a "sketch" that partially rewrites the program flash? In AVR / Arduino world bootloader does just that, but this is different?
Click to expand...

MKL02 does not allow you to program only the RAM without erasing the flash. First bootloader operation, after receiving first chunk of program, is to erase the flash. This may or may not include EEPROM (see 15 sec hold of prog button in T3.6 beta thread).
Only way to load program into RAM without erasing flash is to use SWD programmer (T3.5/6 only), but nobody has reported on MKL02 free programming of T3.5/6.
 
WMXZ said:
MKL02 does not allow you to program only the RAM without erasing the flash. First bootloader operation, after receiving first chunk of program, is to erase the flash.
Click to expand...
Yes, I know the bootloader only provides write-only access. I'm just curious if the chip pushes the bootloader into the main MCU ram to be ran from there? And if that's the case, and if someone could replace that bootloader, could it be used to read back the software in the flash?

So, if someone wants to protect his/her software, and normally the bootloader offers that protection, is it possible to bypass that protection by replacing the loader chip?

Currently I have no need protecting my software, or breaking any protection, just curious.

WMXZ said:
Only way to load program into RAM without erasing flash is to use SWD programmer (T3.5/6 only), but nobody has reported on MKL02 free programming of T3.5/6.
Click to expand...
Why is that T3.5/6 only? The required pins to do that are not exposed in 3.2 / LC?

About the SWD programmers, they are not interchangeable between different brands, are they? Seems that at least this one is, if it really works http://www.waveshare.com/arm-debugger.htm
 
Pazi said:
So, if someone wants to protect his/her software, and normally the bootloader offers that protection, is it possible to bypass that protection by replacing the loader chip?
Click to expand...

By default, the main chip is unlocked.

But as you can see in the code Frank mentioned, if you edit FSEC to 0xDC, the chip will become locked. A Teensy programmed with such code will not be copyable, even by removing the bootloader chip and connecting a JTAG/SWD debugger.

If you want to prevent your code from being copied, definitely edit FSEC before your final programming and shipping of your Teensy-based product.

If you're trying to extract the code from a Teensy someone else programmed, and if they edited FSEC, you're pretty much out of luck. Well, unless you can crack Freescale's hardware lock.
 
Well off topic but that wasn't a freescale Scanlime was pulling code from but a more generic chip, but certainly the basis behind the attack could work against pretty much any CPU that has USB information stored in the same address space as more critical code. Doing it to a Teensy would also be helped by the fact that you could practise on your on board first using known hex files to confirm you hadn't just triggered 64kb of output from the RNG.

Scratching my head about what you could do at the code level to hinder that style of side channel attack without making life for yourself and all your normal users harder. Wondering if you could tweak delay() to toggle unused peripherals in and out to add noise to the power monitoring process, though not good in a battery powered device and horrible if you forget and use the hacked delay() for a different project while it randomly toggles modes on the hardware you ARE using.
 
Status
Not open for further replies.
Back
Top