7 ms·

NRF52 Firmware Readout and Reverse-Engineering Now Possible

143 points by cvs268 6y ago

TaylorAlexander 6y ago
“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 6y ago
  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.
reitanqild 6y ago
> Nordic Semiconductor and LimitedResults did not agree on a responsible disclosure. That’s life. Short and sweet, kind of.
- pantalaimon 6y ago
  I mean it’s not like they could patch it anyway
  - reitanqild 6y ago
    No but Nordic could have gotten some time to warn their customers allowing their customers to create emergency plans.
    - bsder 6y ago
      What emergency plan? This is a device in the hands of a hostile adversary. You pretty much have to assume that given enough determination an adversary WILL crack the device and read your code. All you can really do is make sure anything based around security is one to one and that the attack doesn't scale. You can break you own device, but all that gets you is access to your own device and data. What you don't want is for data to come off the chip that allows somebody to break other copies of your firmware. That would be BAD(tm). However, that's a failure to consider threat model rather than a firmware fault by Nordic.
      - deleted 6y ago
        [deleted]
      - reitanqild 6y ago
        > What emergency plan? Any. Depending on what the stakes are, some examples: - apologize - refund - contact the appropriate secret service and ask them to exfiltrate devices etc etc > This is a device in the hands of a hostile adversary. You pretty much have to assume that given enough determination an adversary WILL crack the device and read your code You and I know this. I feel lucky to have had bosses that have a good idea about this, not everyone seems to be so lucky.
- bsder 6y ago
  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 6y ago
    What's bad faith about noting that Nordic's response to responsible disclosure was trying to get money out of the researcher?
    - bsder 6y ago
      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 6y ago
        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.
rkagerer 6y ago
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 6y ago
  > 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.
- kosma 6y ago
  This works on a surprisingly large number of chips.
btashton 6y ago
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 6y ago
  > 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
ohazi 6y ago
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 6y ago
  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.
  - numpad0 6y ago
    I don’t know a more better designed BLE SoC than nRF51/52 though...
    - djcooley 6y ago
      You might check out the EFR32BG22 from Silicon Labs. It has alot of great security functions, including a dedicated security core with secure boot, secure debug, and unique ID.
hamandcheese 6y ago
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_to_harmony_hub_users_avoid_unnecessary/ https://www.reddit.com/r/homeautomation/comments/esiv9b/psa_...
- saagarjha 6y ago
  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.
- sigwinch28 6y ago
  That is an absolutely horrible business practice from Logitech. I was considering buying a new high-end mouse but now I will be avoiding Logitech products at all costs.
paddlesteamer 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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 6y ago
        Why would anyone be surprised? I'd be very surprised if my firmware was encrypted without setting any encryption key.
        agustamir 6y ago
        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.
floatboth 6y ago
Custom open firmware for Logitech mice incoming? :D
usrusr 6y ago
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 6y ago
  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...
chrissnell 6y ago
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 6y ago
  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_sdk_app_nus_eval.html?cp=7_1_4_2_2_25 https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/ble...
tsomctl 6y ago
> 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-warm-up/ https://limitedresults.com/2019/05/pwn-mbedtls-on-esp32-dfa-...
als0 6y ago
The following Nordic chips seem to have gone through some security evaluation https://www.psacertified.org/certified-products/?_company=nordic-semiconductor https://www.psacertified.org/certified-products/?_company=no...
75efhjitsc 6y ago
> Nordic Semiconductor and LimitedResults did not agree on a responsible disclosure. That’s life. Can you elaborate more on how this would work?
- vaxman 6y ago
  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 6y ago
https://autochess.onl/ https://autochess.onl/

143 points by cvs268 6y ago

“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 6y ago
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.

reitanqild 6y ago

> Nordic Semiconductor and LimitedResults did not agree on a responsible disclosure. That’s life. Short and sweet, kind of.

pantalaimon 6y ago
I mean it’s not like they could patch it anyway
- reitanqild 6y ago
  No but Nordic could have gotten some time to warn their customers allowing their customers to create emergency plans.
  - bsder 6y ago
    What emergency plan? This is a device in the hands of a hostile adversary. You pretty much have to assume that given enough determination an adversary WILL crack the device and read your code. All you can really do is make sure anything based around security is one to one and that the attack doesn't scale. You can break you own device, but all that gets you is access to your own device and data. What you don't want is for data to come off the chip that allows somebody to break other copies of your firmware. That would be BAD(tm). However, that's a failure to consider threat model rather than a firmware fault by Nordic.
    - deleted 6y ago
      [deleted]
    - reitanqild 6y ago
      > What emergency plan? Any. Depending on what the stakes are, some examples: - apologize - refund - contact the appropriate secret service and ask them to exfiltrate devices etc etc > This is a device in the hands of a hostile adversary. You pretty much have to assume that given enough determination an adversary WILL crack the device and read your code You and I know this. I feel lucky to have had bosses that have a good idea about this, not everyone seems to be so lucky.
bsder 6y ago
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 6y ago
  What's bad faith about noting that Nordic's response to responsible disclosure was trying to get money out of the researcher?
  - bsder 6y ago
    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 6y ago
      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.

rkagerer 6y ago

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 6y ago
> 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.
kosma 6y ago
This works on a surprisingly large number of chips.

btashton 6y ago

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 6y ago
> 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

ohazi 6y ago

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 6y ago
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.
- numpad0 6y ago
  I don’t know a more better designed BLE SoC than nRF51/52 though...
  - djcooley 6y ago
    You might check out the EFR32BG22 from Silicon Labs. It has alot of great security functions, including a dedicated security core with secure boot, secure debug, and unique ID.

hamandcheese 6y ago

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_to_harmony_hub_users_avoid_unnecessary/ https://www.reddit.com/r/homeautomation/comments/esiv9b/psa_...

saagarjha 6y ago
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.
sigwinch28 6y ago
That is an absolutely horrible business practice from Logitech. I was considering buying a new high-end mouse but now I will be avoiding Logitech products at all costs.

paddlesteamer 6y ago

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 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      Why would anyone be surprised? I'd be very surprised if my firmware was encrypted without setting any encryption key.
      - agustamir 6y ago
        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.

floatboth 6y ago

Custom open firmware for Logitech mice incoming? :D

usrusr 6y ago

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 6y ago
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...

chrissnell 6y ago

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 6y ago
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_sdk_app_nus_eval.html?cp=7_1_4_2_2_25 https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/ble...

tsomctl 6y ago

> 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-warm-up/ https://limitedresults.com/2019/05/pwn-mbedtls-on-esp32-dfa-...

als0 6y ago

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

75efhjitsc 6y ago

> Nordic Semiconductor and LimitedResults did not agree on a responsible disclosure. That’s life. Can you elaborate more on how this would work?

vaxman 6y ago
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 6y ago

https://autochess.onl/ https://autochess.onl/