Hacking Apple Laptop Batteries

Interesting:

Security researcher Charlie Miller, widely known for his work on Mac OS X and Apple’s iOS, has discovered an interesting method that enables him to completely disable the batteries on Apple laptops, making them permanently unusable, and perform a number of other unintended actions. The method, which involves accessing and sending instructions to the chip housed on smart batteries could also be used for more malicious purposes down the road.

[…]

What he found is that the batteries are shipped from the factory in a state called “sealed mode” and that there’s a four-byte password that’s required to change that. By analyzing a couple of updates that Apple had sent to fix problems in the batteries in the past, Miller found that password and was able to put the battery into “unsealed mode.”

From there, he could make a few small changes to the firmware, but not what he really wanted. So he poked around a bit more and found that a second password was required to move the battery into full access mode, which gave him the ability to make any changes he wished. That password is a default set at the factory and it’s not changed on laptops before they’re shipped. Once he had that, Miller found he could do a lot of interesting things with the battery.

“That lets you access it at the same level as the factory can,” he said. “You can read all the firmware, make changes to the code, do whatever you want. And those code changes will survive a reinstall of the OS, so you could imagine writing malware that could hide on the chip on the battery. You’d need a vulnerability in the OS or something that the battery could then attack, though.”

As components get smarter, they also get more vulnerable.

Tags: , , ,

Posted on July 29, 2011 at 6:54 AM • 33 Comments

Comments

Tyler • July 29, 2011 7:37 AM

How much storage is there on that battery? I know a good coder can do much with little space, as suggested by computer history, but what kind of things could that space permit?

Paeniteo • July 29, 2011 7:47 AM

@Tyler: “what kind of things could that space permit?”

It would almost certainly be enough to download a larger payload from the net, so…

Danny Moules • July 29, 2011 8:08 AM

@Tyler Paeniteo is quite correct. The art of ‘shellcoding’ is very well established. There are a lot of people that have expertise with making such payloads as small as feasibly possible (a matter of bytes, typically) and/or as generically useful as possible. See http://www.exploit-db.com/shellcode/ for some examples.

wiredog • July 29, 2011 8:17 AM

From the looks of things you have to have physical access to the device, or maybe already have it remotely rooted, to do anything.

Woo • July 29, 2011 8:24 AM

I guess this isn’t actually limited to Apple batteries at all.. I don’t recall any notebook manufacturer that doesn’t embed some chip in their batteries.. be it for environmental monitoring or planned obsolescence.

Roger • July 29, 2011 8:24 AM

And the purpose of a u-processor in a battery is … ?

Oh, wait, it:
“contains instructions for how the battery is meant to behave and interact with the operating system and other components.”

Umm, wouldn’t that be “provide voltage at the terminals”?!

I realise there is good reason for some fancy-pants logic in the battery charger module, but there is no logical reason for that to go on the battery.

Some googling suggests that the function of a on-battery u-processor is simply readout of remaining charge. If that’s the case:
a) why does this require a full-blown u-processor rather than 3 or 4 transistors and resistors?
b) why does the u-processor require a multi-level system with three access levels?
c) was this designed by brilliant idiots too densely clever to see that they were using a sledgehammer to crack a nut? (And breaking some fingers in the process!)

tz • July 29, 2011 8:34 AM

Components aren’t getting smarter. Robots aren’t smart, they are very dumb. Very stupid. They do exactly what you tell them to do.

What they are getting is more complex.

Intelligence makes you less vulnerable.

inflexibility and complexity make you a sitting duck holding a “shoot me” sign.

One of the great arts of computer programming is to make something elegantly simple.

infosec,geek • July 29, 2011 8:53 AM

the smartest component is easiest to hack, hence social engineering will always be an effective tool for the hackers!

Carl 'SAI' Mitchell • July 29, 2011 9:11 AM

The on-battery processor is to help control charge and discharge rates to prevent the cells from venting with flame. Batteries store quite a bit of energy, and the modern ones tend to be rather unstable. Batteries catching fire is bad for the stock price, since the fires are very hard to put out.

S • July 29, 2011 9:41 AM

Obligatory xkcd: http://xkcd.com/651/

@ Woo – yeah, all laptops will have circuitry similar to this (lithium batteries are pretty finicky about charging/discharging, compared to NiMH/NiCd); I think the advantage of attacking Macs would be that there’s likely to be far fewer combinations of firmware/hardware, since they have relatively fewer models.

Peter A. • July 29, 2011 9:42 AM

@Carl: that’s all true but I still don’t see a rock-solid reason why this logic is built into the battery and not into the charger and the device powered by such a battery. To prevent a luser from short-circuiting it? Simple current limiter will do. (side note: why car batteries do not have embedded CPUs? they store far more energy and get very nasty when overheated)

Even if the reason is to establish a uniform interface to hide details of the battery characterics and to enable old equipment to “talk” to new super-high-tech batteries (which hardly ever happens: each new device comes with its unique battery form factor) – i still don’t get why such a microprocessor is needed – a piece of ROM with charge/discharge characteristics encoded will suffice.

S • July 29, 2011 9:43 AM

Also, as others have noted, it’s a convenient place to hide malware that will survive reformat & MBR reset. Which could be all kinds of handy even if you don’t go as far as exploding some hipsters along the way.

S • July 29, 2011 9:57 AM

@ Peter A – it’s considerably more involved than that.

Yeah, car batteries can get nasty when overheated, but you can trickle charge them absolutely fine just by hooking a 12V supply across the terminals. I’d prefer not to stand too close to you when you attempt that with a lithium battery, if you don’t mind.

More general details on Smart Battery System: http://sbs-forum.org/specs/

Paeniteo • July 29, 2011 10:02 AM

@S: “it’s a convenient place to hide malware”

Sure… However, one still needs to find a way to infect the actual system from there.

I have two thoughts about this:
One, the interfaces to read out data from the battery will probably be very very simple.
Two, nevertheless, nobody will have thought of actively securing the corresponding code against integer-/buffer-overflows.

Captain Obvious • July 29, 2011 10:08 AM

Modern battery controllers don’t just control charge rate, but also charge levels. Via the software you can adjust how high or low the battery is allowed to go.

Just charging to 95% instead of 100% can increase the life of a lithium battery by up to 30%.

OEM electric cars also have this functionality, have the battery top out at 80% and it will last 2x as long, but let it go to 100% when you really need the extra range.

This enhanced functionality requires SW or FW control as opposed to just HW, which introduces this vulnerability. Not that password best practices reduce that functionality significantly.

Both laptops and EVs have been known to burn while charging or in use, so it’s not hard to imagine what can happen if you set the max charge voltage to 110% or the charge or discharge current to 200%.

S • July 29, 2011 10:17 AM

@ Paeniteo: “Sure… However, one still needs to find a way to infect the actual system from there.”

Agreed. I readily admit I don’t have the software engineering chops to figure out how that would be done, but Charlie Miller raised it as a possibility in his interview with Ars, and given what he’s managed in the past that’s good enough for me!

Just thought it worth highlighting given that Bruce’s linked article doesn’t go into that part of it.

Ars link here, for the lazy: http://arstechnica.com/apple/news/2011/07/how-charlie-miller-discovered-the-apple-battery-hackhow-a-security-researcher-discovered-the-apple-battery-hack.ars

moo • July 29, 2011 10:22 AM

@Peter:
Actually, its simple. If they build it into the laptop, then only batteries EXACTLY like the one the laptop is designed for can be safely hooked up to it and charged by it, etc. Inevitably there will be counterfeit batteries, third-party replacement batteries, etc. and if the laptop catches fire and explodes while charging them, its still Apple who will get sued.

If they build the charge control circuitry into the battery, then it stays with the battery cells it was designed for. If they come up with a new battery design that can hold its charge longer, and has different requirements for charging safely or measuring how much charge is left in the battery, these differences are built into the circuits that are part of the battery. But the hardware for charging is generic enough that what this really means, is that each battery carries programmable firmware with algorithms for charging it as fast as possible without overcharging it or otherwise damaging it.

Of course they have business reasons for putting it into the battery, too: It makes it harder for other companies to make compatible replacement batteries that Apple will have to compete against. Also, if a competitor makes a battery which sometimes catches fire or explodes in Apple laptops, having the charging stuff in the battery means its easier for Apple to put the liability for that on the battery maker. Also, if they find a defect in a run of batteries (whether its a physical flaw, or an algorithmic flaw in the charging stuff), they can correct it in future production runs of the batteries without having to patch the OS or firmware on the laptops themselves.

And to anyone who doesn’t believe batteries can be dangerous, have you ever heard of a “cap and nail expulsion”? Its what often happens when a battery cell explodes—the metal disc at one end of the battery, and the metal rod running down the centre of the battery, are violently propelled out of the battery like a bullet. I’ve seen videos of controlled over-charge tests of batteries and the violence of the explosion is pretty amazing. I always recall it when I’m sitting on an airplane with a laptop on my lap.

Clive Robinson • July 29, 2011 10:24 AM

The (suspected) real reason for the uComp on the bateries is revenue protection (which is illegal in this form in the EU).

You see this all the time with printer cartridges and mobile phone batteries.

Bassicaly a battery is regarded by manufactures as a “tied in consumable” for “revenue stream” reasons. Or to put it another way, you have to buy an OEM battery at way way above the market rates that other specialist suppliers of batteries can.

One consiquence of this knowledge will be non OEM batteries that work as well if not bettter than the rather shabby OEM ones.

HOWEVER with the complex charging curves of various battery types and likewise odd curves for the battery charger circuitry on the mother board there is a high likley hood of frying the motherboard if you don’t know what you are doing.

With regards malware being put in the batteries Apple don’t have a good record on this. In the past Apple players got released with PC malware on them. Supposadly put on by somebody within one of Apples subcontracted supply chain organisations.

Now if you think about it all that is realy needed to get malware from the battery to the main mother board is to identify when during the cold boot sequence the motherboard requests the serial number or battery type information and the battery then injects a way to long string in it that triggers some other action…

I suspect this will be found within a month or two at the most…

The problem Apple like most other hardware manufactures have is one of “key managment” few people understand the ins and outs of it and most hardware engineers will go for the quick easy and importantly easily testable solution 99.9 time out of a hundred because that is the sensible engineering solution.

The problem they now have is how to resolve it without getting into the sillyness Sky Broadcasting got into with their set top box cards.

Or get into usin PubKey where the key length is to short. As Texas Instruments found with the signed code for their calculators.

Oh and I realy hope they don’t do something realy dumb such as use the battery serial number etc as the seed for generating an AES or other symetrical cipher key. Esspecialy if they then use their own “private variation” of a public algorithm such as TEA, or use a public algorithm incorrectly (Microsoft did this with TEA in the X-Box).

As I said it’s not an easy problem to solve but then Key Managment never has. Hopefully when the current NIST Hash game is over, they might actually get around to start addressing it.

Adam • July 29, 2011 10:25 AM

Sounds like a great movie plot – hack batteries of mac users to detonate at 1pm precisely, or when they were turned on at any point thereafter. Even if injuries were slight you’d still cause chaos.

Chris S • July 29, 2011 10:40 AM

@Peter A: “I still don’t get why such a microprocessor is needed – a piece of ROM with charge/discharge characteristics encoded will suffice.”

Modern batteries also store information about that particular battery — things like number of change/discharge cycles. On many business laptops, you can query the battery to find out how much it has been used, which is a key determinant in deciding if it needs to be replaced.

You want this information to travel with the battery. If you plug it into a device that has never seen it before, the new device won’t know the battery history unless the battery provides it.

Although you could just write this into a memory area on the battery, I suspect that higher degree of robustness is needed because of warranty replacement. A battery that fails to hold a good change within a year after 25 cycles is a manufacturing defect, whiled a battery that fails to hold a good change within a year after 250 cycles is an exhausted wear item that is no longer covered by warranty.

Nick P • July 29, 2011 10:51 AM

I could see this being useful for competitive advantage by causing a competitor’s new device to fail during the showcase. It would make them look incompetent if their devices kept shutting down.

Target: “I swear it’s the batteries! The software is perfect!”

Audience: “Sure, sure. Next!”

André • July 29, 2011 12:11 PM

@Chris S
I am still with Peter, as your arguments to me seem quite a bit far-fetched. For my part I haven’t seen any battery switch laptops. If the battery in a company’s laptop grows old, we just purchase a new one and that’s it. Well maybe there are other companies who have a “battery-pool” or something, though I can not imagine, why they should.
(and by the way: there are other and better ways to determine its age and its need for replacement than to count chargings and dischargings)
So we’re still to know, why a battery should provide more than a ROM to be read by the laptop it’s put into.

AND: if batteries actually do travel around as much, as you say, I can see a whole new bunch of attack vectors, concerning the “how to get a virus onto MY battery” … shouldn’t they come with even better security then?

Clive Robinson • July 29, 2011 12:51 PM

@ André,

“So we’re still to know, why a battery should provide more than a ROM to be read by the laptop it’s put into.”

Sorry did I not make it clear enough in my earlier post,

“REVENUE PROTECTION”

It started with mobile phones with the likes of Motorola.

In tthe early days of mobile phones the batteries used where standard cell sized NiCad batteries in a fancy plastic moulding.

Motorola charge around 40GBP before VAT for a replacment, the cells inside could be purchased for around 4GBP over the counter less in quantity.

It was not long before quite reputable companies were mass producing their own 100% compatible products selling for arounf 10GBP.

So the likes of Sony started producing non standard sized NiCad cells, and battery packs were designed around those. Well it was not long before various Taiwanese and Korean manufactures produced simmilar or slightly smaller cells so the game was back on.

Then Motorola took a leaf out of the Ink Jet cartridge book and put a chip in their battery, they then aranged for their software to make bateries without the chip show a very very short time.

The game continues today with phone manufacturing companies selling phones to network providers at or slightly below cost (just like games console and ink jet printers) and making the money on consumables and add ons (batteries handsfree kits etc etc).

Technicaly you are not alowed to “sell below cost” in Europe (it’s called “product dumping”) so they sell a package where the profit in the extras brings the price to fractional above cost. You see this with games consoles where a worthless game or two is added into the package.

But at the end of the day they are still “dumping product” and making obscene profit on the consumables and extras.

Tyler • July 29, 2011 3:37 PM

@Paeniteo, yeah, I wasn’t questioning threat. I’m fairly new to all of this stuff, so I was probing for an idea of what could happen with that amount of space.

@Danny Moules, thanks for the link.

@Everyone else Thanks for the discussion!

Natanael L • August 1, 2011 5:06 PM

@Seiran: Ouch! That’s MUCH worse then battery malware!

One thing that I’ve thought of is the ability for this kind of malware to bypass hardware/full-disc encryption – just load it when the computer is shut down and wait! Exploit + shell code is all you need to store on the circuitry.

Dirk Praet • August 2, 2011 2:32 AM

The question being: who’s the genius (or his manager) thinking that a 4-byte password was good enough a protection scheme to prevent folks from tampering with these batteries ? Bit of a fail, no ?

Natanael L • August 2, 2011 7:32 AM

@Dirk: But who would guess a 32 bit password? That’s like 4 294 967 296 combinations! Over four billion! No human could guess all those! 😛

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.