<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Option to roll back from confirmed image slot in rare OTA situations</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/80502/option-to-roll-back-from-confirmed-image-slot-in-rare-ota-situations</link><description>Hi. I am working on firmware for nRF9160 based IoT device Already found a way how I can switch between two different images in flash from the current firmware and it&amp;#39;s super useful 
 Firmware image that laying on backend cloud server includes logic to</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 11 Oct 2021 08:56:29 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/80502/option-to-roll-back-from-confirmed-image-slot-in-rare-ota-situations" /><item><title>RE: Option to roll back from confirmed image slot in rare OTA situations</title><link>https://devzone.nordicsemi.com/thread/333414?ContentTypeID=1</link><pubDate>Mon, 11 Oct 2021 08:56:29 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:1735eaeb-88fd-4ac7-87ec-cc6a1d78a270</guid><dc:creator>H&amp;#229;kon Alseth</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
[quote user=""]Already found a way how I can switch between two different images in flash from the current firmware and it&amp;#39;s super useful[/quote]
&lt;p&gt;Its great to hear this!&lt;/p&gt;
[quote user=""]Firmware image that laying on backend cloud server includes logic to check that main features like server connection and peripherals working well to make a decision to keep that version or roll back to the previous one. One more secure mechanism implemented using MCU boot it&amp;#39;s if firmware not confirming itself device switching back to known firmware stored in a flash that should work well. All those methods providing a good way of reliability, so it really hard to brick the device in process of OTA.[/quote]
&lt;p&gt;You can read about the concepts of mcuboot, specifically how it behaves when reverting (and how to trigger it), here:&lt;/p&gt;
&lt;p&gt;&lt;a href="https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.7.0/mcuboot/design.html"&gt;https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.7.0/mcuboot/design.html&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
[quote user=""]I understand that this is a very unlikely case, but if it&amp;#39;s happening in production all user devices would be bricked as the result of for example a hacker attack on the server and replacing image to as in my example &amp;quot;self-confirming blink&amp;quot; so the device should be shipped back for restoration e.t.c[/quote]
&lt;p&gt;In order for mcuboot to accept an image, it must match the static partition layout in addition to be signed with your own key. If the key is compromised, you can get into this scenario.&lt;/p&gt;
&lt;p&gt;Just&amp;nbsp;applying arbitrary binary data&amp;nbsp;to mcuboot&amp;nbsp;&amp;nbsp;(ie. from a &amp;quot;fake&amp;quot; webserver) will not trigger such a scenario, as mcuboot will recognize that the incoming data is not signed accordingly.&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Kind regards,&lt;/p&gt;
&lt;p&gt;Håkon&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>