
NRF52 Firmware Readout and Reverse-Engineering Now Possible - cvs268
https://limitedresults.com/2020/06/nrf52-debug-resurrection-approtect-bypass/
======
ohazi
This isn't actually as bad as it sounds.

Almost all general purpose microcontrollers with "readout protection" are
vulnerable to glitching attacks like this one. It may be a stretch to claim
that _most_ embedded engineers understand this, but successful attacks like
this one are published at least a few times a year, and eventually one of them
targets a part that you've used before.

All it does is force you to think about your threat model. You shouldn't keep
sensitive or long-term secrets on a microcontroller and expect them to remain
safe. Transient things like BLE session keys? Sure, whatever.

It's why you don't see (responsible) people designing HSMs using parts like
these, and why extreme skepticism is warranted when people try to build things
like cryptocurrency hardware wallets out of Arduino-caliber parts.

There are special classes of parts with more robust security features that you
should consider using if you need anything resembling an HSM. Even those parts
get broken from time to time, and those breaks are rarely fixable without new
hardware.

~~~
londons_explore
It is not awfully hard to protect a chip against readout through glitching.

All it takes is having brown-out detection which is always on and forces the
chip into reset immediately (ie. No 4 cycle interrupt delay). Rate of change
of voltage detection might be easier to implement without a precision voltage
reference.

Another approach is to put current measurement on the pins. Glitching requires
changing the voltage on a pin very quickly, and since the die has quite a lot
of capacitance, the current flow is large and easy to measure.

Pretty much, there are lots of solutions to this problem, and any chip
designed after 2010 that doesn't implement these shouldn't be considered well
designed.

~~~
ohazi
I mean, you're not wrong... but the chip industry moves slowly, and by your
own definition, most chips produced today would not be considered well
designed.

Also, once you protect against power glitching, they'll move on to clock
glitching. It's endless.

Historically, this is not something that chip companies or their customers
have cared about. Again, unless you're designing an HSM, hardware security is
a checkbox sales item that is adequately satisfied by a probably-not-actually-
secure firmware readout bit. The sales team is happy with this. The buyers on
the other end designing shitty IoT products with a 2 year lifespan can now put
a "secure" sticker on the box.

~~~
avian
The shitty IoT products can then also use a shitty battery/power supply
because the advanced brownout protection the grandparent is talking about
won't be spazzing out every 5 minutes that a LED causes voltage to droop. It's
a win-win.

~~~
xnyan
I worked in consumer, industrial and medical device testing industry for
several years. When working with device manufacturers in the consumer space,
for most of them most of the time cost of the device is the primary and
overriding concern for the product.

Cost mattered for industrial too, but it was balanced by performance and other
considerations. For consumer, it's just cost. Anything that pushed the bill of
materials up = bad, not at all win-win in their mind. "Grandpa buys bad
electronic devices all the time and will keep doing so, why throw our money
away for no reason?" would be a summery of their argument/thought process.

Medical devices are a whole different beast and money was far less of a
consideration, or rather, they are far less worried about the cost because
it's far easier to recoup the cost of the device.

------
hamandcheese
I can’t help but read this and think that this is a good thing... especially
knowing Logitech uses these chips and the scummy things they have been known
to do to sabotage the resale value of the hardware they make. [0]

Is there any meaningful downside to anyone but Nordic and Nordic’s customers?

[0][https://www.reddit.com/r/homeautomation/comments/esiv9b/psa_...](https://www.reddit.com/r/homeautomation/comments/esiv9b/psa_to_harmony_hub_users_avoid_unnecessary/)

~~~
saagarjha
If you’ve put keys or IP in that chip and thought that readout protection
would help you, then you’d be hurting right now. There’s a high chance that
you’re only doing so if you’re a customer, though, and if you thought that
this would actually protect your stuff you’re fairly misguided.

------
usrusr
I've been trying to come up with scenarios where someone relying on that
security would suffer worse from this revelation than merely enabling hardware
clone manufacturing.

(Note that most of those cases are very far from where you would typically
find an NRF52)

Decryption keys for "broadcast" style DRM schemes? Kind of bad, but usually
those also have implementations on far more open hardware, it wouldn't be the
weakest link.

A Yubikey-like second factor configured only for presence? When you can take a
soldering iron to the device you might just as well keep the one you already
have. It would only make a difference for elaborate attacks involving more
than one copy of the destroyed original (e.g. sneaking a clone back to the
original owner). I'd argue that it retains 98% of the security upside compared
to not using a second factor and would still come ahead of many weaker second
factors.

A Yubikey-like second factor configured to require on-device decryption of its
keys? (e.g. built in PIN pad) Bad because the readout would enable unthrottled
attemps, but still only terrible if the resulting key isn't throttled
otherwise (e.g. bad for decrypting some offline storage).

An anti-tampering signature for content production, e.g. camera hardware
confirming that a pictue is based on actual photons hitting a CCD? Bad,
definitely.

An encapsulated root CA in its CEO's pocket? Someone will get fired, but it
won't be the right person.

I'm sure that this list could be longer, but so far I don't see any overlap
with the usual application domain of NRF52.

~~~
michaelt
Stolen devices, and devices that are legitimately in the possession of someone
who is not the owner.

A wifi-enabled doorbell, where you don't want people to be able to snatch it
and extract your wifi credentials.

A product with an iphone-style activation lock (which deters theft by
preventing resale of stolen goods) where you don't want the activation lock
bypassed.

A smart energy meter, which needs to accurately track energy usage...

------
paddlesteamer
With this, devices that use NRF52 chips are now open to investigators. I think
we'll learn of more vulnerabilities of BLE devices whose shitty
implementations are hidden in those SoCs. I'm more than excited about the next
post about Logitech Pro G mouse.

Making things open is a good thing on society's security.

~~~
pantalaimon
That is if they have been locked in the first place.

Also with a lot of devices being firmware upgradable, there is little point in
enabling read-out protection if you can just download the firmware off the
internet. (Unless you want to go through all the hassle of encrypting the
firmware image, but most devices won't be doing anything so special to make
this worthwhile)

~~~
SwaraLink
Nordic provides some easy-to-use tools and examples for encrypting and signing
firmware images when using a bootloader for in-field updates. I would expect
that most products based on the nRF52 that support firmware updates encrypt
the image.

~~~
agustamir
Nordic's off-the-shelf firmware upgrade process has signed image verification
only. The image itself sent over BLE is not encrypted. So anyone using that
right off the bat is in for a nice surprise.

~~~
pantalaimon
Why would anyone be surprised? I'd be _very_ surprised if my firmware was
encrypted without setting any encryption key.

~~~
agustamir
Partially because they call their firmware upgrade process "secure Device
Firmware Update (DFU) functionality" (lifted from their documentation).
Obviously, an engineer needs to go see the source to see what is actually
happening under the hood.

~~~
pantalaimon
Why do you need Encryption for security? A signature should be enough.

(Don’t conflate security with confidentiality)

~~~
agustamir
Not in the context of enabling trusted binaries being used for updates, but to
your original point about reverse engineering unencrypted firmware

~~~
pantalaimon
It's not common for firmware to be encrypted, just as it's not common for
executables on your PC to be encrypted.

------
btashton
I have come to just accept the firmware will be read out in most
microcontrollers unless they are specifically built to hold secrets. Maybe you
can keep someone from copying your code for a little while, but eventually it
will happen and you should have some other value that protects your business.

NRF, STM32, PSoC, ESP32, Xilinx. All of them have silicon or ROM errata that
leak the firmware or the encryption around it.

~~~
baybal2
> unless they are specifically built to hold secrets.

Even that is not warranted, there are companies who lift contents of hardened
microcontrollers for things like smartcards, credit cards, id cards, pos
terminals etc no questions asked

------
reitanqild
> Nordic Semiconductor and LimitedResults did not agree on a responsible
> disclosure. _That’s life._

Short and sweet, kind of.

~~~
bsder
What's Nordic going to even agree to? This is a firmware power glitch exploit.
It's not like they can patch it in the field.

If all they said was: "Nordic Semiconductor and LimitedResults did not agree
on a responsible disclosure." That's fine. So be it.

However, when I see: "Nordic PSIRT proposes to purchase the full report for a
rock-bottom price." They lost my sympathy right there. I have no idea what
they told Nordic, and Nordic really doesn't have a good way to defend against
that accusation without exposing emails that they likely sent back and forth
with confidentiality in place.

That kind of commentary is bad faith _even if_ Nordic may also be acting in
bad faith (and I have no real way to verify that).

~~~
monocasa
What's bad faith about noting that Nordic's response to responsible disclosure
was trying to get money out of the researcher?

~~~
bsder
Did I miss something: "Nordic PSIRT proposes to purchase the full report for a
rock-bottom price."

I read that as the researcher trying to get money out of Nordic--especially
with a comment like "rock-bottom price". Did I get that wrong?

That "rock-bottom price" is an unprofessional sideswipe that Nordic probably
can't counter without breaking confidentiality agreements.

And, what's a "rock-bottom" price? A hundred dollars? A thousand dollars? Ten
thousand dollars?

What price _should_ Nordic pay for a report on a power glitch exploit--
something that pretty much affects every microcontroller on the planet?

And what did the researchers disclose to Nordic in order to agree on a price?
Nordic certainly isn't going to pay much if you just say "I found an exploit"
and don't tell them much else.

That "rock-bottom price" comment adds a whole bunch of character questions to
my assessment of the author as "security researcher" that simply wouldn't be
in scope if they had left it at "Nordic Semiconductor and LimitedResults did
not agree on a responsible disclosure. That’s life."

~~~
monocasa
I guess I read that as "Nordic PSIRT [proposes for the researcher] to purchase
the full report for a rock-bottom price."

Given what I've seen with chip companies that aren't used to dealing with
third party security researchers, that seems pretty on point. Trying to sell a
support contract to someone reporting a security vulnerability.

------
TaylorAlexander
“This security investigation presents a way to bypass the APPROTECT on a
protected nRF52840, in order to reactivate the Serial Wire Debug Interface
(SWD), offering full debug capabilities on the target (R/W access to
Flash/RAM/Registers, Code Exec and reprogramming). All the nRF52 versions are
impacted.

Due to its intrinsic characteristics, the vulnerability cannot be patched
without Silicon redesign, leading to a countless number of vulnerable devices
on the field forever.”

Ooof.

~~~
RealityVoid
Not great, not terrible. You do need physical access to the device and to know
what you're doing, if I had a device based on nRF52840 as a user, I wouldn't
worry so much. More worrying is maybe for producers of devices, afraid their
IP might get stolen. But, honestly, if I put an embedded device out there, I
expect a sufficiently determined attacker would be able to read it anyways.

------
tsomctl
> My low-cost voltage gliching is an homemade HW electronic system, dedicated
> to perform fault injections in a suitable manner. The total cost of this
> electronic board is less than 5$, which proves fault injection is a very low
> cost technique and can be achieved by limited hackers.

Has he released the schematic for this? I'm thinking it's just a small npn
pulling the power pin to ground, and controlled by a microcontroller.

Edit: He talks about his glitcher here:
[https://limitedresults.com/2019/05/pwn-mbedtls-on-
esp32-dfa-...](https://limitedresults.com/2019/05/pwn-mbedtls-on-esp32-dfa-
warm-up/)

------
floatboth
Custom open firmware for Logitech mice incoming? :D

------
rkagerer
TLDR: Soldered onto some pins, identified power usage pattern during boot
sequence characteristic of Flash read, wrote a search program to glitch the
chip at just the right moment when it loads the protection flag.

Apparently able to make exploit persistent, and demo coming up in future post
on a real consumer product (Logitech Mouse). Couldn't reach agreement with
Nordic on a responsible disclosure mechanism.

~~~
floatboth
> Apparently able to make exploit persistent

Well, that's just how the nRF's protection works: you can always disable it,
erasing the flash.

They glitched the chip to access debug without disabling protection → can dump
the firmware now → obviously possible to disable it and then reflash the
recovered firmware.

------
chrissnell
Are these SoC devices often used to act as serial-over-BLE bridges? I have a
barbecue controller from ThermoWorks that I have been trying to reverse
engineer. Sniffing BLE has been pretty useless for this thing because it
appears to be using BLE as a mechanism to do basic serial comms. I would like
to understand more how these serial implementations work and to find some
resources that I could use to capture the protocol.

~~~
dromtrund
Yes. This example is supposedly a common starting point for this type of
application:
[https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/ble...](https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/ble_sdk_app_nus_eval.html?cp=7_1_4_2_2_25)

------
als0
The following Nordic chips seem to have gone through some security evaluation
[https://www.psacertified.org/certified-
products/?_company=no...](https://www.psacertified.org/certified-
products/?_company=nordic-semiconductor)

------
75efhjitsc
> Nordic Semiconductor and LimitedResults did not agree on a responsible
> disclosure. That’s life.

Can you elaborate more on how this would work?

~~~
vaxman
I read it as the guy at LimitedResults sent an extortion demand and was
rebuffed, then released the information under his company alias to and avoid
the appearance of extortion by investigating authorities that Nordic would
have had a duty to its stakeholders to file a complaint with.

------
embiowway1228
[https://autochess.onl/](https://autochess.onl/)

