Shop OBEX P1 Docs P2 Docs Learn Events
Possible that Prop can be more code secure than other MCUs? — Parallax Forums

Possible that Prop can be more code secure than other MCUs?

RaymanRayman Posts: 13,797
edited 2011-08-26 07:18 in Propeller 1
I know the issue of code security has often come up...

Was just wondering if one can keep the Prop powered with a supercap or battery, if it could offer more code security that something like a PIC.

Was reading the other day about how to crack the PIC code security and rip the flash...

Does the Prop have an advantage in being able to run code from RAM?

Is there a way to steal Prop code that's only in RAM?
«13

Comments

  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-18 07:51
    If there is no code running on the Prop to allow access to the HUB/COG RAM I can not see any way that your suggestion could be cracked, by a mere mortal anyway.
  • MacTuxLinMacTuxLin Posts: 821
    edited 2011-05-18 07:59
    Rayman,

    I was evaluating this chip but ... the support is just extremely horrible :frown:

    http://www.atmel.com/dyn/products/tools_devices.asp?category_id=172&family_id=646&subfamily_id=736&tool_id=4535
  • ericballericball Posts: 774
    edited 2011-05-18 08:58
    The difficulty is the Prop1 powers up in an insecure mode. It first checks for a PC serial connection and will load a program into RAM, then it checks for an EEPROM and loads the unencrypted code from there. So although you could load a program into RAM and then use a battery backup to provide power, that program would be lost if the Prop ever lost power or reset. Then the program would have to be reloaded from the unencrypted EEPROM. (OTOH, I once worked with an X.25 encryption device which would clear it's private keys if the case was opened or the power & battery were disconnected. The only way to reload the keys was via an EEPROM embedded in a physical key programmed by the key management server along with a key exchange with the KMS via the X.25 network. Something similar could be done with the Prop, but it would be overkill.)
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-18 09:05
    I think that the intent of the question is in the case that once powered on the Propeller never loses power so that there is never a reset condition, and therefore never any reason for an external EEPROM. In that case it would be quite difficult to crack. You would literally have to use passive magnetic tomography, in order to read the state of the ram, and I do not think that any micro is immune to that.
  • RaymanRayman Posts: 13,797
    edited 2011-05-18 09:09
    Now that I think more about it...

    Could one force a reset and load a very tiny program that outputted the remaining RAM contents?

    Does a reset clear RAM?
  • potatoheadpotatohead Posts: 10,253
    edited 2011-05-18 09:13
    Seems to me, one could couple this with a destroy mode, where not only is the program lost, but the CPU is broken.

    Replacements are shipped to be inserted into the device, already powered, running code.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-05-18 09:15
    A reset doesn't necessarily clear RAM, but the bootloader must, in order to initialize VAR variables.

    -Phil
  • BatangBatang Posts: 234
    edited 2011-05-18 09:45
    Possible that Prop can be more code secure than other MCUs?

    No, Unless you pot the whole thing in epoxy block.
  • LeonLeon Posts: 7,620
    edited 2011-05-18 09:50
    Dunking it in red fuming nitric acid will dissolve the epoxy.

    There are chips with strong code encryption, of course, that are virtually immune to attack.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-05-18 10:09
    Getting back to Rayman's original proposition, I believe it has merit. You would need to program a powered-down mode, along with a soft reset to resume execution from a "virtual power-up", but that's easily achievable. Unless it's coded into the running RAM program, I can't see a way for an intruder to steal code without clobbering RAM completely.

    In order to prevent inadvertent resets, you'd have to tie both /BOE and /RST to Vdd.

    -Phil
  • ericballericball Posts: 774
    edited 2011-05-18 12:15
    In order to prevent inadvertent resets, you'd have to tie both /BOE and /RST to Vdd.

    Then provide a battery sufficient to handle 2+ days without wall power and a way to replace the battery without powering down the system. Then provide a way to replace the system when they reset in spite of everything.
  • TubularTubular Posts: 4,620
    edited 2011-05-18 13:15
    Rayman

    I've been looking into exactly this concept - in fact have just been discussing with Cluso.

    My system has a GPRS modem which has "over the air" updates and should have enough smarts to be able to load the prop. So the "fix" in event of long term disconnection (1 month+, large supercap) is to "reflash" the modem with the prop loader code, reload the RAM based prop, and reflash the loader code and its payload out of there.

    Here's what I think is the critical thing to check:- when loading the prop I think its possible to load a 'short' program. What happens to the remaining RAM in such an event? If it does remain it still may be possible to work around by keeping the private key near the start of RAM, so even a 'short' program would overwrite or at least corrupt it.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-05-18 13:23
    ericball wrote:
    Then provide a battery sufficient to handle 2+ days without wall power and a way to replace the battery without powering down the system.
    That should be pretty easy.
    ericball wrote:
    Then provide a way to replace the system when they reset in spite of everything.
    That raises an interesting question: what happens when the prop resets and there's no EEPROM and no PC connected? When it addresses EEPROM, is it smart enough to recognize that it's not getting an ACK and quit, or does it blithely fill RAM with $FFs? And if it quits, what next? Restart with the program currently in RAM? (That would be nice.)

    -Phil
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-18 13:23
    If we are worried about the possibility of a short program not fully overwriting the RAM, then we should maintain enough power to keep all used COGS active (in wait state) so that the code can be fully contained in cog RAM and the hub RAM can be over written after boot has been completed.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-05-18 13:25
    That would work. Of course, it rules out any meaningful Spin code.

    -Phil
  • schillschill Posts: 741
    edited 2011-05-18 13:33
    That raises an interesting question: what happens when the prop resets and there's no EEPROM and no PC connected? When it addresses EEPROM, is it smart enough to recognize that it's not getting an ACK and quit, or does it blithely fill RAM with $FFs? And if it quits, what next? Restart with the program currently in RAM? (That would be nice.)

    According to the manual (page 18):
    2. The Boot Loader performs one or more of the following tasks, in order:
    a. Detects communication from a host, such as a PC, on pins P30 and P31. If communication from a host is detected, the Boot Loader converses with the host to identify the Propeller chip and possibly download a program into Main RAM and optionally into an external 32 KB EEPROM.
    b. If no host communication was detected, the Boot Loader looks for an external 32 KB EEPROM (24LC256) on pins P28 and P29. If an EEPROM is detected, the entire 32 KB data image is loaded into the Propeller chip’s Main RAM.
    c. If no EEPROM was detected, the boot loader stops, Cog 0 is terminated, the Propeller chip goes into shutdown mode, and all I/O pins are set to inputs.

    I guess this means that it doesn't touch the RAM. So, if the reset did not involve loss of power, would the RAM still be populated?

    Would one possibility be to include an EEPROM with your device, but load it with a "fake" program? If you have a display on the device, this program could just show the message "Return to xxxx for servicing" or something similar. The manual says it reads an entire 32K image from the EEPROM - that would fill RAM.

    Before shipping, you power up the device and load the real program into RAM. You then ship it out powered (as discussed above).

    If it loses power or resets, it will load the program in EEPROM - wiping out the RAM (if necessary) and indicating that it will no longer function as expected.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-18 13:48
    schill:
    Good thought, though this would not prevent someone from pulling the reset line low and loading a small program through P30/P31 as this is checked by the Propeller boot loader before it checks for an EEPROM.
  • schillschill Posts: 741
    edited 2011-05-18 14:00
    schill:
    Good thought, though this would not prevent someone from pulling the reset line low and loading a small program through P30/P31 as this is checked by the Propeller boot loader before it checks for an EEPROM.

    Yeah. Unless the bootloader happens to clear RAM.

    Maybe, after loading the RAM you just need to "cut off" pins 30 and 31. Of course, after that you couldn't reprogram the chip but at least people wouldn't be able to load another program. You'd have to replace the device instead of doing a factory "refurb."

    The cutting off wouldn't necessarily have to be physical. Could you electrically jolt the receive pin sufficiently to destroy it without messing up the rest of the chip?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-05-18 14:22
    I suspect that the bootloader clears all of RAM after the loaded part, which is how VAR variables get initialized to zero.

    -Phil
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-18 14:28
    Maybe some one should make a definitive test. Would loading the entire memory with known data, and then loading a minimal program to send the contents of HUB mem to another prop (should take less code than sending it to a PC), having the second Prop forward this data to a PC and check it for validity be a good way of testing this?
  • Dave HeinDave Hein Posts: 6,347
    edited 2011-05-18 15:45
    The source for the boot loader was posted at http://forums.parallaxinc.com/forums/default.aspx?f=25&p=1&m=252691 . It appears that it clears the remaining RAM after loading a program through the serial port.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2011-05-18 16:18
    So it does. Then I guess that the worries about someone loading a small program to read hub mem are voided.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-05-18 17:38
    There's one other possible issue: What happens when the EEPROM loader gets a partial load, and the EEPROM quits responding?

    Then there's that nasty inadvrtent reset issue. In nice environments, it wouldn't be a problem. But in industrial settings with lots of EMI, anything is possible.

    -Phil
  • UnsoundcodeUnsoundcode Posts: 1,530
    edited 2011-05-18 19:09
    Loading serially with the option to write to EEPROM the download is first written to RAM with locations above and beyond the program size set to zero and then the program is read into the EEPROM.

    If the bootloader could be fooled into thinking it had received (serially without a reset) a valid program with the command to load to EEPROM then the current contents of RAM would be written to an EEPROM if fitted. I'm not saying its possible but it is an intriguing thought

    As an unrelated side note, with a modified bootloader written to an EEPROM the Prop can be programmed from any pin pair 0 - 27 without a reset so if those pins are damaged all is not lost.

    Jeff T.
  • Cluso99Cluso99 Posts: 18,066
    edited 2011-05-18 19:14
    I believe there are ways to protect code in the prop that would suffice. I am not about to publicly state them, for that only fuels the ways to break the protection. I have had discussions with both Tubular and Ken on my thoughts, and I have some new ones too that I discussed with Tubular yesterday.

    If someone has a real need with volumes to match, I am prepared to discuss offline and can indeed provide some solutions. I think Ken and Chip also have ideas, so discuss with them directly too. I might add, nothing is quite perfect. Russia proved that with their Z80 clones.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-05-18 19:19
    Cluso99,

    Please divulge your idea. Security-by-obscurity is not security at all.

    -Phil
  • RaymanRayman Posts: 13,797
    edited 2011-05-18 21:42
    I don't think this idea has been shot down yet... Sounds like tricks with the bootloader may be the only way (for less than a million dollars) to obtain the code in RAM only.

    I'll have to remember to ask Chip about this at UPEW (assuming he'll be there). I'm sure Chip and Parallax are well versed in code security from the Basic Stamp series.
    I'd be surprised if they haven't thought about this already. Maybe they already know a weakness...
  • BatangBatang Posts: 234
    edited 2011-05-18 22:21
    Leon
    Dunking it in red fuming nitric acid will dissolve the epoxy

    Good point, then the only solution would be to case it in unobtainium if security for the prop is your concern. :)
  • BatangBatang Posts: 234
    edited 2011-05-18 22:25
    Come to think of it the the question in the title of this thread:

    "Possible that Prop can be more code secure than other MCUs?"

    is an oxymoron when you consider that the prop has no code security to start with and most other micros do.

    :)
  • TubularTubular Posts: 4,620
    edited 2011-05-18 22:37
    Batang, "security" is a relative not absolute concept.

    The probing techniques required to break and read the volatile ram contents of the prop are different to breaking the "secure" memory of another flash based microcontroller.
Sign In or Register to comment.