4

I need to be able to prevent other from copying my program placed in the flash, but want to still be able to write to the EEPROM.

I tried the lock bits by setting them to Mode 3 (0x3C). But that will prevent me from writing to the EEPROM.

Is there a way of prevent reading the flash while continue to allow writing to the EEPROM?

Nick Alexeev
  • 37,739
  • 17
  • 97
  • 230
T Tuba
  • 41
  • 4
  • 1
    Why would you want to lock the flash but keep manipulating the EEPROM with a programmer afterwards? This is uncommon "production" flow. – Rev Nov 18 '13 at 16:26
  • Make the code boot in a eeprom programmer mode by setting a pin high (or low). – jippie Nov 18 '13 at 20:10
  • 2
    Can you please elaborate about the "eeprom programmer mode" you just mentioned? I tried to google it but couldn't find much. Please explain how can it help in my situation.Thanks – T Tuba Nov 18 '13 at 20:36
  • I believe the idea would be to put functionality into your firmware to enable "self" programming the EEPROM in response to external requests. You could even have this duplicate a common serial programmer interface, much as bootloaders for this chip often do - though for your application detail given below, giving it an interface more tailored to "add card #" or "remove card #" could make more sense. – Chris Stratton Nov 18 '13 at 22:29

3 Answers3

2

REF: https://electronics.stackexchange.com/a/53293

and especially: http://web.engr.oregonstate.edu/~traylor/ece473/lectures/fuses.pdf

It may be possible to set a "Mode not 2" aka "Mode 1 xor 2", with LB1 as 1 and LB2 as 0.

implication: an enterprising individual should be able to use the programming ability implicit by LB1's enabled status to reset LB2 to 1

irregardless, by "clamping" (wire tapping) the flashing data stream, (presumably over a USB cable) the uploaded data can be seen (trivially and literally with an oscilloscope - a person "could read" RS232 data this way for low (<<75) baud rates and is the visual analogue to the aural ability for using Morse code, where senders could even be identified by their "fist")

if this uploaded data is therefore NOT decrypted before flashing then the internal boot loader must be modified to decrypt it, ... and if parts of the boot loader must be decrypted by a key encrypted in the flash upload data ...

a secret external key, password, starts the process above, so a "cold" chip is useless otherwise

this technique does not prevent copying but it does inhibit usability of the copy

if nothing else, the obfuscation presents a challenge for not only the interloper but the authentic author too

Community
  • 1
just wondering
  • 21
  • 3
1

No, there is not. Consider adding an external I2C or SPI EEPROM/flash if you need externally-writable space while having the on-board program flash be unreadable. Not only will this solve your immediate problem, it can also give you much more space in which to store your data, either supplied or generated.

Ignacio Vazquez-Abrams
  • 48,282
  • 4
  • 73
  • 102
  • "if you need writable space while having the on-board program flash be unreadable": This only makes sense if you are referring to writing EEPROM from code. And that is (obviously) independent from the lock bits. However, it is somewhat uncommon to want to lock the flash in the first place and keep manipulating only the EEPROM with a programmer afterwards. – Rev Nov 18 '13 at 16:25
  • 3
    It is very common to run into uncommon scenarios:) – T Tuba Nov 18 '13 at 16:43
  • 1
    I have a program that will specify which cards are authorized to access a facility. The card IDs are stored in the EEPROM, while my program is stored in the flash. I provided my users with a desktop application to connect to the IC and add/remove cards (therefore I'd like to be able to write to the EEPROM), on the other hand I want to protect my program on the flash from copying and replicating it by competitors. Ignacio's idea makes sense although I was hoping for a solutions where I don't have to add new components. Thanks – T Tuba Nov 18 '13 at 16:59
  • It's entirely possible to fulfill this need with internal storage only, by treating it as "data" exclusively stored/written by the firmware rather than an external programmer operation - no need for an external chip unless additional space is needed. – Chris Stratton Nov 18 '13 at 22:32
0

Here is how I solved it. It might not work for everyone in my situation but that was good enough for my need. Since I'm restricted by mode 3. I decided to use mode3 (prevent reading and writing for flash and eeprom). Therefore I will be providing my program + the data to the customers in an encrypted file that can only be opened by my desktop application, which will decrypt it and deploy both the program and the data and lock them again to the chip. The only draw back with this solution is the time it will take to upload to flash and EEPROM (~40-45 seconds) while uploading to the EEPORM alone takes around 10 to 15 seconds. On the other hand, this solution have an extra advantage of allowing the submission of any updates to my program within the same operation.

Thanks for everyone's suggestion. I may try them in the future when I have time to experiment.

T Tuba
  • 41
  • 4
  • Just keep in mind that unless your secret key is stored on the microcontroller in a safe unreadable location, it is trivial to get the decrypted firmware and data. I hope this works well for you! – HL-SDK Nov 19 '13 at 14:40
  • This is just not a good solution - it's overly complicated and trivially defeated. – Chris Stratton Nov 19 '13 at 15:38
  • I agree, but my solution is mainly aiming to discourage others from attempting to copy my code rather than having a very tight security. Also, I'm not storing any key on my MCU, I'm sending the customers an encrypted file and my desktop application (which is also protected by a well-known code protection tool) will decode the encrypted file, upload to the flash and EEPROM, then re-lock the chip. Again, I just want to discourage snoopers and I don't want the micro-controller program available readily by just downloading it from my chip and copy it to other chips to replicate my effort. Thanks – T Tuba Nov 19 '13 at 19:46
  • I'd consider throwing in a bunch of garbage or misleading code before and after the decryption at least, and scrambling the contents of the decoded RAM as quickly as possible (again with garbage code.) As soon as the decrypt happens, a talented hacker can pause the CPU, dump the RAM, and pick out the gold nugget pretty easily these days. I've even developed hardware enc/decryption but that was also easily thwarted for the same reason. Bottom line, hacker is always more determined than the developer. – rdtsc Dec 20 '15 at 23:14