3 ms·
No. I suggest you do skim the article. The author taped the switch readout pin (mPCIe pin 20) at the card side, and the card was so designed that it assumes th
by numpad0 3y ago
No. I suggest you do skim the article.
The author taped the switch readout pin (mPCIe pin 20) at the card side, and the card was so designed that it assumes the switch is set to not-kill when the switch is not present at all.
We do not know how deep the mechanism goes within the card. It is only shown that the card do work if the pin is open.
- stavros 3y agoWhich means that then the switch is _exactly_ "just a suggestion that is then handled in the card”s firmware". It doesn't cut the power to the card.
- lagadu 3y agoWe don't actually know that. It's possible that connecting that pin shorts some circuit on the card that prevents it from operating. I suspect you're right though.
- sue_real 3y agoIt's pretty much just a button, if it doesn't physically cuts power, I'd suggest. I think with billion dollar budget year after year, you pretty much go for firmware level attacks thees days. 0click 0day as-a-service is private economy and.. cheap and very different from what they want: long term backdoor access to everything, without the possiblility to spot it in user space or OS.
- BertoldVdb 3y agoIt usually is not, most cards will allow software unlocking even if the hardware switch is off. You can run 'rfkill unblock all' on a Linux system to test it.
- numpad0 3y agorfkill shouldn’t be able to unblock hardblocks, “all” means “all cards here”, not “all of those nonsense”. Is that your experience or are you just theorizing?
- numpad0 3y ago"in the firmware" part is pure speculation. It's fair to assume worst as a security best practice, but pedantically we just don't know if a mal-firmware can in fact ignore it. There could be like, the kill switch input distributed to radio amplifier and such. A lot of analog components has on-off(usually not-enable) inputs.