• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 274 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1352R: Factory Image: Justification/risk?

Daniel Hoenig
Prodigy 30 points
Part Number: CC1352R

FactoryImage support is standard functionality of the OAD code in the TI SDK.

While I understand the superficial reason for this functionality (robustness in case of a malfunction), I would like to better understand the details of this scenario, i.e. what are the conditions that would make the FactoryImage useful, and what is the risk to get there?

The FactoryImage mechanism kicks in if there is neither a valid application nor a valid (OAD) image to copy over. However, the way the OAD process is working, it is assured that there is always at least one valid image:

  • The application image is erased only if the OAD image check was successful
  • the OAD image, after copying over, is invalidated only once the app image check was successful

So the only scenario I can imagine is if somehow the copy process doesn't work or the images get corrupted during the OAD process within a very very small window. If the copy process doesn't work for the real image, it probably doesn't work for the FactoryImage either, and the probability that the image get corrupted in the window between validity check and copying is tiny.

Another scenario could be that flash aging leads to corruption. This would mean we have a defective device, so a factory image won't help.

So long story short, is there more to it, are there more random attack vectors of higher probability that I don't see to get into a fatal situation where the FactoryImage would help?

Best

Daniel

  • +1
    TI__Guru* 82271 points

    Hi Daniel,

    Yes you are right. The other option is

    - You have downloaded a valid image which is not OAD capable. 

    - Your have downloaded an image with a bug which makes the device hang.

    We have added secure OAD to avoid a random image being loaded to the device. (OAD requires signed image.)

    Cheers,

    Marie H.

  • 0 in reply to Marie H
    Prodigy 30 points

    Hi Marie,

    thank you for your answer, it leads me to a follow-up question:

    In both of your scenarios, the BIM would have to be triggered to copy the factory image over, but I'm not aware of a mechanism that would do that: to the BIM, an OAD non-capable image looks perfectly normal, and a crash in a defective application isn't detected either, is it?

    Is there a way that I haven't seen yet that activates the copy mechanism in these scenarios?

    Cheers,

    Daniel

  • 0 in reply to Daniel Hoenig
    TI__Guru* 82271 points

    Hi Daniel,

    You are right, the BIM needs to be triggered to use the factory image (typically a button press on device reset).

    Cheers,
    Marie H

  • 0 in reply to Marie H
    Prodigy 30 points

    Understood.

    So as the button press is mainly a Launchpad feature, on a custom hardware other means have to be found (i.e. by customizing the BIM) to detect the targeted conditions.

  • 0
    Prodigy 30 points

    On a side note: I patched out the factory image creation support due to the feedback I gained here, however, the rest of the oad.c code (namely the combination of oadFindExtFlImgAddr() and oadFindleastRecentlyUsedIdx() ) are based on the assumption that at least one valid header exists in external flash (see parallel question about an endless loop that I then experienced). These functions (at least) would have to be modified to support a completely "headerless" flash.