Shop OBEX P1 Docs P2 Docs Learn Events
Propeller 2 Code Protection — Parallax Forums

Propeller 2 Code Protection

michaelshumichaelshu Posts: 3
edited 2019-06-11 18:59 in Propeller 2
I'm new to Propeller and evaluating Propeller 2. Is there any code protection feature built in hardware? Or anyway to implemet some software solution for code protection? I found this old forum article but not sure it's implemented in Propeller 2. https://forums.parallax.com/discussion/138403/parallax-propeller-2-code-authentication-and-protection

Comments

  • cgraceycgracey Posts: 14,133
    There is no code protection.

    It was planned for, using poly fuses to set up a 256-bit key, but not implemented because of likely fuse error rates. There was an alternative possibility of using some ON Semi IP to get the needed bits, but it seemed too complicated to try to implement amid all the other things needing to get done at the time.

    You could fashion your own protection using a small code-protected micro, but its efficacy will be determined by the likely efforts used against it. I think if everyone came up with their own scheme, so that there was no universal attack possible, these would be reasonably secure for most purposes.
  • cgracey wrote: »
    I think if everyone came up with their own scheme, so that there was no universal attack possible, these would be reasonably secure for most purposes.

    That.
    As soon as there is enough interest, any code protection WILL get cracked. IIRC most common microcontroller's code protection schemes are broken.

    However, there are ways to prevent your code from being "stolen", such as:
    - Come up with your own contrived encryption/verification scheme, as chip said.
    - Hide some kind of message inside your code, so when you suspect someone has cloned your product, you can prove it.
    - Store code on a RAM chip that looses power when an intrusion is detected (of course that only works when you can service the device)
    - Release the code as open-source to begin with :wink:
  • That is exactly what MS does for their code protection. I use Find & Replace for all my variables and change them to very random 8-bit Hex numbers. Bury hidden messages in the code, as in: line 7, 15th letter, equals the 1st letter of the message. Then if there is any memory left over at the end, I just fill it up with "dummy" code. It is going to be weeks, or months, before they figure it out. To top it off, I can always take an extra couple of i/o pins and run a *high* voltage thru them to fry the innards of the chip if you power it up in the wrong sequence.
  • Thanks. Guys. It's very helpful.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    You could fashion your own protection using a small code-protected micro, but its efficacy will be determined by the likely efforts used against it. I think if everyone came up with their own scheme, so that there was no universal attack possible, these would be reasonably secure for most purposes.

    Yes, even small sub 50c MCUs commonly have unique serial numbers, so those can be used for first level clone or gateway protection.
    eg the EFM8UB3 USB-MCU on P2D2 says this
    "5.2 Unique Identifier A 128-bit universally unique identifier (UUID) is pre-programmed into all devices."

    Above that, there are more security focused MCUs and even FPGAs now, that managers are more likely to sign off on :

    http://www.nuvoton.com/hq/products/microcontrollers/arm-cortex-m23-mcus/?__locale=en
    http://www.latticesemi.com/Products/FPGAandCPLD/MachXO3D
  • PropGuy2 wrote: »
    That is exactly what MS does for their code protection. I use Find & Replace for all my variables and change them to very random 8-bit Hex numbers. Bury hidden messages in the code, as in: line 7, 15th letter, equals the 1st letter of the message. Then if there is any memory left over at the end, I just fill it up with "dummy" code. It is going to be weeks, or months, before they figure it out. To top it off, I can always take an extra couple of i/o pins and run a *high* voltage thru them to fry the innards of the chip if you power it up in the wrong sequence.

    What is "MS" ? A company?
  • RaymanRayman Posts: 13,805
    I guess it's true that code from a P2 is really only going to work on another P2.
    So, if you can tag your code, the thief's code will be unprotected too and you'd have proof that it was stolen.
    But, what next?

    Is the goal to protect the P2 code or proprietary info about something connected to the P2?
    In the latter case, they don't need your code, they just need to reverse engineer how what is connected to the P2 works...
  • BeanBean Posts: 8,129
    edited 2019-06-11 23:07
    Any 1-wire device will have a unique serial number. Verifying that is about all the "protection" you probably need.
    Any protection scheme can be broken. Usually you just need to "keep the honest people honest" by not making it too easy to clone.

    Bean
  • cgraceycgracey Posts: 14,133
    michaelshu wrote: »
    PropGuy2 wrote: »
    That is exactly what MS does for their code protection. I use Find & Replace for all my variables and change them to very random 8-bit Hex numbers. Bury hidden messages in the code, as in: line 7, 15th letter, equals the 1st letter of the message. Then if there is any memory left over at the end, I just fill it up with "dummy" code. It is going to be weeks, or months, before they figure it out. To top it off, I can always take an extra couple of i/o pins and run a *high* voltage thru them to fry the innards of the chip if you power it up in the wrong sequence.

    What is "MS" ? A company?

    Microsoft.
  • evanhevanh Posts: 15,126
    Multiple Sclerosis
  • Bean wrote: »
    Any 1-wire device will have a unique serial number. Verifying that is about all the "protection" you probably need.
    Any protection scheme can be broken. Usually you just need to "keep the honest people honest" by not making it too easy to clone.

    Bean

    I used a 1-wire serial number in a project. On initial boot-up the serial number would be read and store -- in an obfuscated way -- in the EEPROM. The idea was that someone making a copy of the EE (a concern for the client) would end up with a bricked system if the physical serial number didn't match the stored version. If a mismatch was detected I would erase the EE and display an obtuse error message. The scheme was never deployed, though, because the client needed one more feature and the 1W link was the last IO pin we could use.
  • jmgjmg Posts: 15,140
    JonnyMac wrote: »
    I used a 1-wire serial number in a project. On initial boot-up the serial number would be read and store -- in an obfuscated way -- in the EEPROM. The idea was that someone making a copy of the EE (a concern for the client) would end up with a bricked system if the physical serial number didn't match the stored version. If a mismatch was detected I would erase the EE and display an obtuse error message. The scheme was never deployed, though, because the
    client needed one more feature and the 1W link was the last IO pin we could use.
    Did they still ship with the 1-wire serial number installed, to at least give the illusion it was serialized.. ? ;)


  • With P1 I used a FM31L278 (RTC+32KB FRAM) to replace the eeprom. The RTC was anyway needed.

    The code protection was made by encoding part of the FRAM image. Once the image was transferred into the hub the un-encoded part of the image read the FM31L278's OTP serial number and the two counters value. This two was the decoding key to decrypt the hub content.
    The protection was made in the advancing of the counters value, with external events, for example upon a chassis intrusion switch or a light/ir detector (into a dark closed pcb enclosure), ... The same event also cleared the P1 ram if the MCU was powered when it occurred.
    Obviously there was no decoding key comparison: if the counters value was not the right one the program was simply decoded with the wrong key, leading to unpredictable results.
    A minimum level of security (injury prevention) was made with one IO acting as *disable* to other IO's to avoid wrong outputs driving due to mismatched program.
  • JonnyMac wrote: »
    I used a 1-wire serial number in a project. On initial boot-up the serial number would be read and store -- in an obfuscated way -- in the EEPROM.

    In addition you can send them on a wild goose chase by having a "decoy" that isn't so obfuscated that seemingly leads to something while in fact leads to nothing.

  • JonnyMac wrote: »
    I used a 1-wire serial number in a project. On initial boot-up the serial number would be read and store -- in an obfuscated way -- in the EEPROM.

    In addition you can send them on a wild goose chase by having a "decoy" that isn't so obfuscated that seemingly leads to something while in fact leads to nothing.

    nice
  • In addition you can send them on a wild goose chase by having a "decoy" that isn't so obfuscated that seemingly leads to something while in fact leads to nothing.

    I did leave the vendor name in plain text and used it as part of the security check. If someone edited the EE image to change the name I would also brick the system. This is simple and doesn't require the 1W serial number.
Sign In or Register to comment.