Have been through the complete design of a system, including the menu system, I can say that I feel that close to 75% of the work is in creating the user interface, which is completely public! If I could copy what I have and can see now, I would have spent MUCH less time.
If you put your own splash screen on your product, and include checking the integrity of the loaded data, realistically who is going to spend the time deciphering the byte codes so they can change their pins and misc, and put their own splash screen on?
potatohead said...
Given what's been written on this topic, I'm curious about the devices with protection that is acceptable. What means are used? Seems to me, a few hundred dollars gets the code no matter what! How is that protection seen as acceptable then?
One can look at how copy protection has been implemented in the console arena for examples.
IMHO one way to do it would be to have a set of onchip write-only fuses and a DES/AES engine. The fuses (once they are programmed) are used by the bootstrap code to decrypt the EEPROM data using the DES/AES engine. Once the EEPROM is programmed the fuses are blown. Of course, this doesn't protect against those willing to decap the Prop and read out the fuses. But it would protect against snooping the EEPROM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObExForum
OnePinTVText driver: ObExForum
Pursuant to the RAM-only idea, the Propeller is a fully static device. If one were to drive it with an external, gated clock, and gate the clock "off" when external power is removed, the RAM contents would be preserved with very little power. It would be an interesting experiment to see how long a reasonably-sized cap could retain the RAM contents. (Holly, your caps are not reasonably-sized! )
Great point Phil, I'd be interested in what the current draw is in that situation. If nothing else, a rechargeable 3.6V coin cell battery should last a reasonable amount of time. All of this is somewhat assuming that the product won't be shelved for a year... I would really only recommend this for an application that will have charging current on a regular basis.
Another possibility. Why not publish the formulas in the documentation, but "tweak" them a bit so that the results are close, but not quite right. That way people will think they have the formulas, and won't look any further, but they won't have as high a quality product as you do. Plus it will drive them crazy trying to figure out what's wrong.
Comments
But you could no longer tx to the prop plug :-(
If you put your own splash screen on your product, and include checking the integrity of the loaded data, realistically who is going to spend the time deciphering the byte codes so they can change their pins and misc, and put their own splash screen on?
IMHO one way to do it would be to have a set of onchip write-only fuses and a DES/AES engine. The fuses (once they are programmed) are used by the bootstrap code to decrypt the EEPROM data using the DES/AES engine. Once the EEPROM is programmed the fuses are blown. Of course, this doesn't protect against those willing to decap the Prop and read out the fuses. But it would protect against snooping the EEPROM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
-Phil