4 ms·
Posting anonymously because I have some industry experience with this. I have designed circuit boards to protect lithium-ion batteries in notebooks. (By the way
by battDesigner 15y ago
Posting anonymously because I have some industry experience with this. I have designed circuit boards to protect lithium-ion batteries in notebooks. (By the way, all this information could be learned from publically-available data sheets on Texas Instrument's website)
The is a complete non-story, and I will tell you why:
1) Regarding installing "malware" on a battery. I have never worked with a battery monitoring ASIC that contains a general purpose micro controller. I have worked with Texas Instruments notebook battery monitors, and none of the ones I have worked on can run general purpose code. They have registers that the host can poll to get information about the battery, but there is no way to load code onto them. The researcher keeps talking about "reverse engineering the firmware" of the battery. Maybe things have changed recently, but I have never seen actual general-purpose firmware in a battery. Limits and calibrations settings yes, but firmware no.
2) Regarding any potential safety issues: Every battery controller board has a secondary battery protection IC. This IC has no firmware at all, and is a purely hardware based way to detect over-voltage, under-voltage, or over-temperature conditions. This can not be overridden in any way (it does not sit on a communication bus). Usually when this secondary protection kicks in, it will permanently disable the battery. In addition, each individual cell has a "PTC" (positive-temperature-coefficient) resistor in series that will isolate the cell if too much current is drawn. (Some battery designs might use a fuse instead.) This is in addition to the main battery fuse, and the controllable FETs.
These batteries are designed with multiple levels of protection. Any one of them failing (including the main monitor ASIC) will not make a battery catch on fire.
3) As far as I remember, you can't really use the SMBus of a notebook without having root access. I could be wrong here though.
4) Finally, this is by no means limited to only Macs. Every PC notebook has extremely similar battery architecture, with the exact same "security risks".
The worst that this guy could do, given he has physical access to your computer, would be to disable your battery. If you just want to do that, a hammer will do a much better job.
- swolchok 15y agoI was actually working on this exact problem in grad school, but gave up when we couldn't start fires (and so did Barnaby Jack, according to Forbes -- http://blogs.forbes.com/andygreenberg/2011/07/22/apple-laptops-vulnerable-to-hack-that-kills-or-corrupts-batteries/ http://blogs.forbes.com/andygreenberg/2011/07/22/apple-lapto...). What put the nail in the coffin for us was finally discovering the PTC devices on the individual cells -- they make a rather loud click and shut off if you short the cell. We also found evidence of them on cylindrical cells pulled from a PC battery. It's not limited to Macs, but Apple's the only company I could find that released battery firmware updates. Other machines do seem to use the bq20z80, but it was easiest by far to play with battery firmware on Macs (i.e. I never got anything working on any other kind of machine). A semi-plausible fraud threat is that you can buy old batteries off ebay that have disabled themselves in hardware due to undervoltage, re-enable them, recharge them, and resell them as "like new." They'll work for a few days and then bulge.
- battDesigner 15y agoWhen you mention "battery firmware", are you referring to the settings in flash that you can change regarding safety cut-off points, etc? Or were you actually able to make the battery's IC execute arbitrary code? In my mind, firmware only refers to executable code. Curious though if there is a way to actually run code on those guys.
- swolchok 15y agoThey called it a battery firmware update, but they meant the pages of settings you can change in flash. I was able to dump raw memory from the chip, but I could never figure out which generic microcontroller the battery controller had been built on top of (at least I assumed it had been built that way), so running code was a nonstarter.