FREELOADER FILE ACCESS

[JonW]

Hi Pepe

I don't have a 2550 yet and posted it there for others to test.  I will try to get hold of one, and in the meantime will take that device off the site and have a look through your code.

They are also designed to work in real devices, synchronised in real time with the bootloader pc application.

[RGV250]

Hi Jon,
I am sure i have some 2550's so if you PM me your address i will post them to you.

Regards,
Bob

[JonW]

Pepe,

I've been through the .bas and .hex you sent. It is my MWBOOT_2550 with your edits: the UART set-up, sync, parser, CRC, flash and EEPROM write code are the release code, unchanged. So if yours "works" and the release "doesn't", the difference is your simulator, not the bootloader.

Header

You have removed my copyright notice again. That is the second time. mwboot is free to use, but the notice stays and modified versions are not to be distributed. Modified copies in circulation confuse other users about which file is the real one. If you have a fix, send it to me and I will fold it into the release with credit.

Bugs in your version

1. cWindowMs 1000. bRxTimeout is a byte, so 1000 becomes 232 (your hex loads 0xE8). Your window is 232 ms, not 1 s.
2. CP0 to CP3 = On. Your hex has CONFIG5L = 0x00, which is code protect on all four blocks. On a real chip a programmer can no longer read it back or verify it, until a bulk erase. I doubt that was intended.
3. cNVM_Idle 0x40. Your comment says CFGS = 0, but 0x40 is CFGS = 1. It only gets away with it because the next operation rewrites EECON1.
4. Your header says slot 0x7CF8, code 0x7D00, 776 bytes reserved. With cBootPages 4 it is slot 0x7BF8, code 0x7C00, 1032 bytes. That is 256 bytes of application space lost for nothing.

The stack

This is the one real point. On a blank part, each window timeout leaves one return address on the stack, so after 31 windows STVREN resets the chip, about every 3 seconds. On silicon, that is a clean reset straight back into the same sync window. It cannot happen once an application is loaded, and it has no effect on an upload because the command loop clears STKPTR on every pass. It is verified harmless on silicon, but for correctness I am clearing STKPTR at the exit in the next release, on every family.

Simulators

What I will not do is change the bootloader's format or structure to satisfy a simulator that does not behave like the chip. Your changes to R (config and ID padded with zeros), the longer window and the 4-page layout are there for ISIS, not for a 2550. The protocol, layout and timing are the same across all families, and that structure is bench-proven on real Q43, K42, K40, K20 and K22 parts. Test on a real 2550 before reporting issues.

Test status

Starting with the next release, every bootloader will be marked either BENCH-PROVEN (run on a real chip) or SIMULATOR ONLY in the file header and in the download. Simulator-only parts stay available for anyone who wants to try them and report back. The 2550 is simulator-only today: I have re-run the release in my simulator (Real time simulator, not ISIS), and it passes, and I will confirm it on a real chip as soon as I have one.



Jon

[Pepe]

Thank you very much for your reply.

[JonW]

Added some more tested devices and a free Serial terminal. MWTERM HERE

[JonW]

Pepe

P2550 devices, kindly sent to me by RGV250 (Bob).
Fully tested and verified in Amicus 8 (changed to 16M Xtal and DTR Reset).  No other changes to the BL code other than xtal

All working correctly in Silicon

Moved P2550 into built and tested on the Freeloader site

[Pepe]

Thank you very much. Is there any way to protect the chip so that the programmed code cannot be read or copied?

[JonW]

Hi Pepe

Yeah, you can.  I do the following on some products.

Key: 16 bytes in the boot region, programmed with the bootloader via PICkit, protected by the CP fuses and by removing the R feature from the bootloader. The key never leaves the chip.

PC side: a tool (or a FREELOADER option) takes the hex plus the key and produces an encrypted image file. That file is what customers get; the hex stays with you.
Chip side: W receives a 256-byte frame, checks the CRC as now, decrypts it in bBuf, then erases, writes and verifies exactly as it does today. The page-0 vector patch and the slot are unaffected, since the slot is built before encryption.

[Pepe]

But if I understood correctly, once the chip is programmed after decryption, it can be read to extract the binary program. And what I want to prevent is it being duplicated onto another chip.

[JonW]

Pepe,

1. The key goes in with the bootloader, by PICkit, once. Every update for that product is encrypted on the PC with the same key. (You do this and only you and you never share the Key)

2. I would have to change Freeloader to add this feature.

   FREELOADER reads the hex and moves the first 8 bytes into the slot. It can't do that with ciphertext, so the encrypt tool builds the slot first, and then FREELOADER gets a "send as is" mode. Small change.

   --verify and --read go: R is not in the protected bootloader at all. If it exists, it is a way to copy. Every page is still checked; the chip compares what it wrote with the answer and returns K or F.

Do that and the three ways in are shut:
PICkit read disabled, CP fuses are set
The Bootloader read  - R removed
The customer file is encrypted


What is left is a lab attack on the fuses. That gets the key too, it lives in the same flash. Stops a competitor with a PICkit, won't stop someone who pays for it. No micro will.

CP fuses do not stop the bootloader writing flash. They only block the programmer pins. Leave WRT and EBTR off, or the bootloader can't write
or verify.


Jon

Edit: You sacrifice some Flash space to accommodate the decryption algorithm

[JonW]

Pepe

Looked at this alot more and went through some older C files on arm cores we use, I think an XTEA 128 bit decoder is definitely doable in 2 to 3k with the bootloader in 18F Pics using Positron. Use a key per customer or even product key.  The same key to the mcu in protected area, then distibute your product. You can roll out an uploader and an encrypted hex.  Input key to a simple parser that encodes your updated encrypted hex.

Im slowly retiring, hence more time to help