Shop OBEX P1 Docs P2 Docs Learn Events
Keeping my propeller code mine? — Parallax Forums

Keeping my propeller code mine?

Zap-oZap-o Posts: 452
edited 2010-06-20 04:40 in Propeller 1
Is there a way to secure the propeller firmware that I write? In my opinion the current -propeller to 24lc256- is as easy as it gets, stealing the code that is.

I work many hours / months and my code is not secure, you dont find that disturbing?

Just wondering if its possible to some degree?
«13

Comments

  • MicrocontrolledMicrocontrolled Posts: 2,461
    edited 2010-06-18 03:10
    Well, for a distributive package, you could save it as a binary in the Propeller Tool software. That would avoid people reading your code. You could also check out the "ID" object in the OBEX that stores a random value on the EEPROM. You could program your prop to only boot if that value was found. This would avoid people stealing it by coping the EEPROM, assuming they only got the lower 32k. You could also attach a small EEPROM to the bottom of a DIP prop, cover it in epoxy, and hope no one wants it that bad.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Check out my new website!!

    Use the Propeller icon!! Propeller.gif

    Follow me on Twitter! Search "Microcontrolled"
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2010-06-18 03:21
    Zap-o,

    I've never found software alone to be a very promising way to make money. And, believe me, I've tried. You'll gain way more from sharing your code and reaping the rewards from your hardware designs than you ever would from trying to capitalize on just software. To garner a serous income from your programming, you'd have to hire a cadre of attorneys just to intimidate those who might try to copy you. Who would ever want to be that kind of person?

    -Phil
  • HollyMinkowskiHollyMinkowski Posts: 1,398
    edited 2010-06-18 03:55
    I had an idea about burning out a section near the end
    of the eeprom by re-writing it so many times it just fails.
    Then have your code check to make certain that area is
    indeed dead, and if it is not, then fail to run. So simply copying
    the eeprom code to another chip won't result in a program
    that will function.

    It's a bit lame, I know. But there really is no certain way
    to protect your code.
  • Cluso99Cluso99 Posts: 18,069
    edited 2010-06-18 05:43
    Zap-o: It's been discussed many times before so do a Google advanced search on the forum.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
    · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
    · Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
  • Kevin WoodKevin Wood Posts: 1,266
    edited 2010-06-18 08:53
    Phil, I think Zap-o's question is legitimate, and that the answer isn't as simple as "sharing your code". Parallax obviously offers products containing their own intellectual property (ie, BS2 interpreter, Propeller HW/FW) that they wish to keep to themselves. is it so bad that somebody using their products might want to do the same?

    There are a few Propeller design decisions that, IMO, I wonder what Chip Gracey was thinking when he went that direction. Not offering code protect is one of them.
  • BeanBean Posts: 8,129
    edited 2010-06-18 10:39
    All 1-wire devices have a unique serial number.

    So if you are using any 1-wire devices just get the serial number, and check for it at several places in your code.

    Another method is to fry an unused propeller pin and test for that somehow.

    @Holly, interesting idea. I'm not sure if EEPROM ever fails completely. I think it just get unreliable. Let us know if you ever have a chance to try it.

    Bean

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Use BASIC on the Propeller with the speed of assembly language.
    PropBASIC thread http://forums.parallax.com/showthread.php?p=867134

    March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    There are two rules in life:
    · 1) Never divulge all information
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    If you choose not to decide, you still have made a choice. [noparse][[/noparse]RUSH - Freewill]
  • BradCBradC Posts: 2,601
    edited 2010-06-18 11:09
    Bean said...
    Another method is to fry an unused propeller pin and test for that somehow.

    Thus far every time I've fried a prop pin I've also taken out the PLL.
    Bean said...

    @Holly, interesting idea. I'm not sure if EEPROM ever fails completely. I think it just get unreliable. Let us know if you ever have a chance to try it.

    Reads always succeed, but writes get unreliable. Heat helps write to the device though (and elevating the device temperature can extend the write life a *lot*), so you'd want to burn out the EEPROM locations at elevated temperatures to ensure they were permanently unreliable at low temps.

    I found that one the hard way (when my German car radio failed because the idiots made it write the current volume level to the EEPROM *every* time it changed and then read the level back to set the volume. On hot days it would work great, but the cooler it got the less reliable it got. Some dodgy "fixit" stores on the net used to "fix it" by gluing a resistor to the eeprom connected across the supply lines to keep it warm).

    Blaupunkt (cough, spit).

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
  • heaterheater Posts: 3,370
    edited 2010-06-18 11:30
    BradC: "Blaupunkt"

    Heater: "Gesundheit."

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • RaymanRayman Posts: 14,889
    edited 2010-06-18 12:46
    There does seem to be an opening for a 3rd party hardware developer here...

    I think just a $1 PIC could be used to decrypt EEPROM code and load the Prop...
    PICs appear to have pretty good code protection...


    I think I'd program the PIC to mimic an EEPROM chip to make transition simple...

    Just realized that scheme could be easily broken...

    Maybe there is no way to protect code (not that I care myself about this).

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Apps:· http://www.rayslogic.com/propeller/Programming/Programming.htm

    My Prop Info: ·http://www.rayslogic.com/propeller/propeller.htm
    My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm

    Post Edited (Rayman) : 6/18/2010 12:57:26 PM GMT
  • eod_punkeod_punk Posts: 146
    edited 2010-06-18 13:25
    Microcontrolled said...
    You could also attach a small EEPROM to the bottom of a DIP prop, cover it in epoxy, and hope no one wants it that bad.

    If you wanted to go this route what epoxy should be used? Isn't this also what they do in the game consoles?

    Also is there a way to take the screen print markings off an chip? I'm just looking at other ways to make it more difficult for someone to figure out whats all in there.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    There is no problem that can't be solved with a suitable amount of explosives!

    EOD Memorial
  • BeanBean Posts: 8,129
    edited 2010-06-18 13:28
    BradC said...
    Bean said...
    Another method is to fry an unused propeller pin and test for that somehow.

    Thus far every time I've fried a prop pin I've also taken out the PLL.
    Well that's a bummer. But if the application didn't need the PLL, it would be a pretty good method.

    Bean


    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Use BASIC on the Propeller with the speed of assembly language.
    PropBASIC thread http://forums.parallax.com/showthread.php?p=867134

    March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    There are two rules in life:
    · 1) Never divulge all information
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    If you choose not to decide, you still have made a choice. [noparse][[/noparse]RUSH - Freewill]

    Post Edited (Bean) : 6/18/2010 4:39:44 PM GMT
  • potatoheadpotatohead Posts: 10,261
    edited 2010-06-18 14:16
    You know, I think Holly's idea is interesting. A small burnout, and a check gets the program running. If that were combined with a seriously obfuscated binary, and some unpleasant materials, that's a high barrier. Simple cloning would be a pita, essentially requiring the work be done to both recover the bits, and reverse engineer them.

    Not bad, IMHO.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Wondering how to set tile colors in the graphics_demo.spin?
    Safety Tip: Life is as good as YOU think it is!
  • BradCBradC Posts: 2,601
    edited 2010-06-18 14:57
    potatohead said...
    You know, I think Holly's idea is interesting. A small burnout, and a check gets the program running. If that were combined with a seriously obfuscated binary, and some unpleasant materials, that's a high barrier. Simple cloning would be a pita, essentially requiring the work be done to both recover the bits, and reverse engineer them.

    An X-ray (found at your friendly VET / Dentist / Airport), drill bit and a couple of pogo pins bypasses the unpleasant materials. I often wonder if people who think reverse engineering code is hard have ever done it. Even obfuscated code can be pretty trivially traced to find the trigger points and bypassed if you are simply looking to copy and remove protection. Proper reverse engineering is quite a bit harder, but by no means impossible. Witness how long it took a few people on the forum to get the SPIN interpreter to a state where Chip was willing to release the code....

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
  • hover1hover1 Posts: 1,929
    edited 2010-06-18 14:58
    Sandpaper is used a lot. I was once asked to fix a piece of audio gear, and every chip was sandpapered, (about 70 IC's) and no schematics·where available.·Needless to say, it didn't get fixed.

    Jim
    eod_punk said...
    Microcontrolled said...
    You could also attach a small EEPROM to the bottom of a DIP prop, cover it in epoxy, and hope no one wants it that bad.

    If you wanted to go this route what epoxy should be used? Isn't this also what they do in the game consoles?

    Also is there a way to take the screen print markings off an chip? I'm just looking at other ways to make it more difficult for someone to figure out whats all in there.

  • Zap-oZap-o Posts: 452
    edited 2010-06-18 15:37
    Some of You fail to realize that all it would take is for someone to remove the 24LC256 off my board and run it off another propeller or similar IC reading each bank of code. Remember its an i2c device and adding a resistor will change its address. This would create a mirror image of your code. You could burn banks of code, bend prop pins etc it wont matter in my opinion. The code is in the 24LC256 and not protected as far as I can tell.

    Phil - its not that I want to make $$ off my code its that we sell units all over the world and my code is the jewel of the units. The hardware is not secret and the circuit board is nothing either. Its the code that our customers want.

    Is there an encryption technique that one could use some how?

    I have been looking at PIC chips and the EEprom is in the IC. I know the propeller is a FPGA based IC so the memory will almost always be out side the IC. Perhaps I need to design a PIC chip to keep the memory for the propeller?
  • LeonLeon Posts: 7,620
    edited 2010-06-18 15:47
    It's not FPGA-based, an FPGA was used during development.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Leon Heller
    Amateur radio callsign: G1HSM
  • potatoheadpotatohead Posts: 10,261
    edited 2010-06-18 15:53
    Brad, of course! And I agree with you on the code.

    My point was simply to put a nice work barrier there. That's all it really ever is.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Wondering how to set tile colors in the graphics_demo.spin?
    Safety Tip: Life is as good as YOU think it is!
  • John R.John R. Posts: 1,376
    edited 2010-06-18 15:59
    If there is value in your product, people will buy it. What makes the code so "special"? (I'm not saying it isn't, just talking hypothetically.)

    If an outside user with some smarts could duplicate the functions of the code by watching how your device works, what real good is code protection? Sure, copying the code might save some time, but what stops a person from "reverse engineering" the code based on functionality?

    I personally have a tough time with the whole concept of "it's secret". Most people don't want to take the time to mess with stuff, and if there is enough market to make it commercially viable to hijack something, there is enough to make it worth the "reverse engineering" effort anyway.

    E.G. - AMD made a chip "from scratch" based not on copying Intel's actual chip layout, but based on reverse engineering from the data sheet and practical tests in the lab.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    John R.
    Click here to see my Nomad Build Log
  • Zap-oZap-o Posts: 452
    edited 2010-06-18 16:06
    Okay so I have an Idea to encrypt EEprom data. Stay tuned.

    @ leon - thanks for the clarification

    @ John - my code is almost a year of mathematical equations derived from myself and a scientist, people are lazy and could so easily copy. My code is special just because of the time I put in to it and I think protecting it to some minimal degree should be a natural reaction.


    I have a way to encrypt the EEprom I think 128 bit should be enough, what do you all think?
  • John R.John R. Posts: 1,376
    edited 2010-06-18 16:25
    The natural reaction to protect your work is indeed natural, and very understandable. I just question (not just in this case, but many) the validity of the concern.

    In your case, is/will the calculations be published? If so, why worry so much about protecting the code?

    If the formulas/calculations will not be published, that certainly makes things a different story, if ineed the calculations are truely that unique and valuable.

    I guess what I'm really trying to say is this:

    Is the process of protecting the code REALLY needed, or is it just a psycological "need". In most cases, if "someone" wants it bad enough, they will find a way to get it. Also, in most cases, people won't find it worth the effort, unless there is significant financial gain, and then they will want it "bad enough" to whatever it takes anyway.

    There certainly are cases where protection is warranted, just fewer than most people think.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    John R.
    Click here to see my Nomad Build Log
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2010-06-18 16:27
    You could encrypt it, but part of the code has to be in the clear just to get started after reset. And the part that's in the clear has to include the decryption code. So you won't really accomplish anything with the encryption. IMO, any attempt to encrypt or obfuscate code in EEPROM is a waste of time.

    Propeller code simply cannot be adequately protected against a dedicated snoop. Get over it, and move on.

    -Phil
  • smbakersmbaker Posts: 164
    edited 2010-06-18 16:33
    Zap-o said...
    I have a way to encrypt the EEprom I think 128 bit should be enough, what do you all think?

    How are you going to decrypt it? Encryption is generally based on having a "secret", and the lack of having a secret is the root of the problem. To do any kind of decryption, I'd think the secret would have to be physically embedded into the Prop. Otherwise someone can snoop the ciphertext, the secret, and your decryption algorithm and decrypt your code.

    Unless you physically lock down the chip so you can create a secret, the best you can probably do is code obfuscation, which is what the virus makers do. Code obfuscation is another technique to make it slightly more difficult for the casual hacker to gain access to the code, but like the other techniques presented here does not prevent against the determined individual.
  • Zap-oZap-o Posts: 452
    edited 2010-06-18 16:56
    My ideas is simple.

    I will have some of the firmware loaded on the 24LC256 running a decrypting program. This is what loads when the propeller starts. A type of boot loader. Once this program is loaded into the propeller it looks for the key. The key will be located in the FTDI memory or other ICs that I am using on the board that contains EEprom data I can program from my PC. Onces the Decrypting program (running on the propeller ) finds the correct key it can begin un-locking the remaining data stored in the 24LC256 that is scrambled.

    Note: On the computer side I have to compile the binary file (my firmware) and encrypt it. Then load it to the EEprom starting at an address after the decrypting boot loader.

    Wow, hope this makes since. I have started on this project and it seems doable.
  • smbakersmbaker Posts: 164
    edited 2010-06-18 17:15
    Zap-o said...
    I will have some of the firmware loaded on the 24LC256 running a decrypting program. This is what loads when the propeller starts. A type of boot loader. Once this program is loaded into the propeller it looks for the key. The key will be located in the FTDI memory or other ICs that I am using on the board that contains EEprom data I can program from my PC. Onces the Decrypting program (running on the propeller ) finds the correct key it can begin un-locking the remaining data stored in the 24LC256 that is scrambled.

    All I have to do is create an in-circuit propeller emulator, substitute it for the real prop in your device, let it run your decryptor, and then read the plaintext back out of the emulator.

    In fact, I'm surprised nobody on this board has emulated a prop-in-a-prop yet (they've emulated everything else!)

    SCott
  • Zap-oZap-o Posts: 452
    edited 2010-06-18 17:18
    Sure but you wont have the key to decrypt. So you'll have code but it will be useless. Right?
  • smbakersmbaker Posts: 164
    edited 2010-06-18 17:21
    Zap-o said...
    Sure but you wont have the key to decrypt. So you'll have code but it will be useless. Right?

    Your solution ended up with the decrypted data (code) sitting in the prop's RAM, didn't it? If so, then it would be sitting in my prop-emulator's (emulated) RAM, and I could read it out. Perhaps I've misunderstood...

    Scott
  • Dave HeinDave Hein Posts: 6,347
    edited 2010-06-18 17:22
    Zap-o's scheme would work if the key could be burned into the Prop.
  • smbakersmbaker Posts: 164
    edited 2010-06-18 17:28
    Dave Hein said...
    Zap-o's scheme would work if the key could be burned into the Prop.

    Technically, if the key could be burned into the prop, and could not read by any program loaded on the prop (otherwise I'd just boot the prop with code that read the key and sent it out the serial connection). Thus the prop would need a protected decryption subroutine in firmware that was the only way to access the protected key.
  • Zap-oZap-o Posts: 452
    edited 2010-06-18 17:28
    The key would be on the computer program fellas look at my crude picture. Since a computer is needed in my application, we make the program to go along with the units.

    attachment.php?attachmentid=71282
    504 x 680 - 25K
  • smbakersmbaker Posts: 164
    edited 2010-06-18 17:33
    Zap-o said...
    The key would be on the computer program fellas look at my crude picture. Since a computer is needed in my application, we make the program to go along with the units.

    I still don't see why I can't replace the propeller in your picture with my own black box that looks and acts exactly like propeller but also allows me to read the contents its RAM. The decrypted code has to be sitting where the prop can execute it, which is in the prop's local RAM.
Sign In or Register to comment.