Hacker News new | past | comments | ask | show | jobs | submit login
Defeating a Laptop's BIOS Password (github.com/skysafe)
357 points by Avery3R on Feb 25, 2020 | hide | past | favorite | 96 comments



I "cracked" my father's laptop's password when he passed away 15 years ago by buying a similar, broken laptop on eBay for cheap, and unsoldering and switching the ROM/EEPROM containing the BIOS.

Probably one of the coolest things I've done as a teenager.


Why re-solder the chip? It seems as though it would be easier to recover data by just yanking the drive, especially since full-disk encryption was quite rare fifteen years ago. Failing that, couldn't you have used a SPI flasher with the existing chip?


Can't you still just remove the battery on the mother board for a few seconds? I used to do that all the time back when I was a repair tech...


EEPROMs are non-volatile. They don't need power to keep their data. AFAIK removing the battery just resets the real time clock.


To a teenager with only a passing experience with electronics, operating a soldering iron is much easier than learning to flash an EEPROM :-)

And I only had one working, locked laptop and a broken one. The whole endeavour was mostly to inherit my father's laptop than to recover any data. What I did with my father's data is probably a story for another time.


Some laptop hard drives have a firmware password you have to enter at the BIOS stage to boot it.


You can buy just the chip on eBay these days. Depending on the model laptop they send you a different chip and they pre-load a BIOS on it for you.


fearless comes to mind


A lot of passwords can be derived from the serial number. This website will do a lot of the work for you.

https://bios-pw.org/


That's a great re-implementation from some stuff I did eons ago [0].

BIOS passwords are indeed a complete joke as means to secure access. There are a bunch of vendors out there who moved the authentication off from the BIOS/CPU to the KBC (keyboard controller) - Toshiba and Lenovo are among them. Still, it's ludicrously easy to circumvent these.

[0] https://dogber1.blogspot.com/2009/05/table-of-reverse-engine...


The linked article did not have info about Thinkpads. I wonder how nowadays one can skip BIOS password of a T series thinkpad. So far it has always ended up with a motherboard change for me.


There is a guy in hungary that offers unlocking services for about 50EUR. He is a bit difficult to work with (insists on a NDA) but the procedure is as follows: you dump the bios via SPI and send it to him. Afterwards you get a patched image back you flash onto the bios chip. Then you boot and you need to enter some numbers he also sends you (I assume some type of copy protection) and it will unlock and reset the bios password. After that you just reflash the bios image you made earlier.


If you don't mind physically opening the laptop, you open it and take out the CMOS battery, boot it up without it then shut it down and put the CMOS battery back in and boot. The BIOS password will no longer bet set. I don't know if this still works but it used to on older laptops.


Modern UEFI uses Flash Storage and CMOS is only relevant for the computer time keeping (though some UEFIs have a full CMOS to emulate BIOS behaviour)


Doesn't work anymore. The data is no longer stored in CMOS.


Sometimes it is the same chip but not the same range, so it's not cleared ever.


i used this method on an old t520 with success.


For slightly older ThinkPads, the method is to short clock and data lines (SCL and SDA), power on the laptop, and press F1 all at the right moment. This website has the locations for many models, for example the X220: http://www.ja.axxs.net/x220.htm (note that this person is/was selling a device to assist with the process but its use is not required, although, predictably, it doesn't say so on the website).

For newer ThinkPads, there is a method to replace the LenovoTranslateService EFI module with a modified version that passes control to another module, which in turn removes the password. This is supposed to be a paid solution (the module will ask for a code that has to be purchased) but apparently there is a "workaround" for that too.

I might not be up to date as I had no need for any of these and my most recent ThinkPad is an X220 but it's safe to say there is always going to be some solution without having to resort to motherboard replacement.


There is a trick that work for some (most?) models in the T-series: if you short the pins of some chip with the right timing, you can bypass the password check. See, for example: https://amp.reddit.com/r/thinkpad/comments/b7jbqq/reset_bios...


I believe you force BIOS to think that it had been lucky but checksums don’t match and EEPROM save is corrupt, then load default and let password go.

Works for straightforward ones like most Lenovo, but not for weirdos like Toshiba. Sometimes I see lots of Toshiba office laptops with locked BIOS waiting to be recycled as the result.


Older Toshibas have pins near the RAM that can be shorted to clear the passwords. There's a big list here: https://biosbypass.com/how-to-clear-toshiba-bios-password/


I seem to remember the last model that works on is the T420, after that you are out of luck.


Way back in the first years of the 00's, working IT support in college, BIOS passwords were common (though not mandatory) on the Faculty/Staff desktops. So, forgetting passwords was common as well, and at the time we could reset them by opening them up and swapping a jumper to another set of pins. It struck me as fairly useless to have a BIOS password at the time.

Forever after, on bootup, "Warning! Case has been opened!" would flash up on the screen. I assumed that was for warranty purposes, but our IT department was certified for repairs so it didn't really matter.


The BIOS should have a reset option for the case open switch. It's just a warning you toggle off in the BIOS. The idea is that only a tech would know the BIOS password to turn it off, so that's how you know that someone knows about it.

It's also unusual that discharging the CMOS removed the boot password. It shouldn't do that. I also worked on similar desktops (they were IBM desktops from before they were spun off) and they didn't have this problem that I can recall. Very few systems had boot passwords, however.

I'm certain that the BIOS passwords didn't clear this way, however, because we had a few systems that had old passwords that nobody knew. Instead, we had a copy of the tech software used to program the BIOS. You had to boot that program and use it to clear the password. HP had a similar program, but that stopped working around 2010 when the computers started to ship with a TPM and you could no longer just clear the content.


> It's also unusual that discharging the CMOS removed the boot password. It shouldn't do that.

That's actually the official way to reset the password for a number of systems. [0][1][2]

[0] https://www.dell.com/support/article/au/en/aubsd1/sln170684/...

[1] https://forums.lenovo.com/t5/ThinkStation-Workstations/How-d...

[2] https://h30434.www3.hp.com/t5/Desktop-Boot-and-Lockup/how-to...


> HP had a similar program, but that stopped working around 2010

Can I obtain this somehow? I have a business grade HP laptop from 2006 (nw8440 I think) and I forgot my BIOS setup password. I need to enable the NX bit to upgrade from win7 to win10! Removing the CMOS battery overnight (and all other power) did not help.


You place a file you _may_ be able to get from support (called SMC.bin) onto a FAT32 USB drive, and then:

1. Power off.

2. Hold the Windows, Up arrow and Down arrow keys all at the same time. Only then hit the power button to start.

3. Release all buttons and press F10.

4. You should see something about "SMC Command" starting.

5. Press File, press "Reset BIOS security defaults" or similar.

The only way to get the SMC.bin file, that I know of, is directly from HP Business Support.


They were Compaqs at the time, but if I recall correctly, we switched to Dell at one point and it was pretty much the same situation.


Hah, I remember this all too well


For my Lenovo Helix 2nd Gen I just need to wait until the battery runs out. This clears the BIOS, including the password.


> Even today's modern 64-bit CPUs begin execution in 16-bit mode. In UEFI, this is called the SEC phase.

Is that true even for the T2 Macs and such?


Yes, because the CPU boots after the T2, and the T2 emulates the SPI ROM to the PCH. There is no actual BIOS Flash chip, only T2 Flash.

Normally the CPU talks to the PCH and the PCH via SPI to a Flash ROM. The CPU has a BOOTROM which can cryptographically verify code blocks, the PCH has a CPU that can do the same, and the firmware has signed code blocks. It starts out with the CPU reading an authenticated code block which contains further code to verify other blocks.

Problem is that you still read SPI Flash which can be modified out of band, so after the CPU ROM reads the ACB it continues reading code which can be altered and if the UEFI firmware is set to 'verify but don't stop running' mode, you can modify all you want and it will work. On the other hand, if it is configured that way but a bit flip happens you can't boot anymore and can repair either. Apple's solution was to get rid of that completely and just emulate that SPI Flash from the T2 chip. The T2 is a complete SoC running an OS and has a secure enclave. Because it doesn't have to support 1980's Intel architecture they had a lot more freedom in designing security from the start, something Intel can't do unless they can break with backwards compatibility.


Apple has been moving their defenses earlier and earlier in the boot process. According to this talk[0] they are even able to foil malicious option ROM[1] and other early boot attacks. I don’t recall if they mention boot passwords specifically, but they claim to lead the industry in this regard.

[0] https://youtu.be/3byNNUReyvE

[1] https://www.blackhat.com/us-19/briefings/schedule/#behind-th...


Verification of option roms as a part of secure boot is a part of the normal uefi spec, however some vendors forgot to implement it

https://docs.microsoft.com/en-us/windows-hardware/manufactur...


I'm not that familiar with Macs, but if they're using an Intel CPU it almost definitely starts in 16-bit mode. From what I understand the T2 chip is more akin to what's called an embedded controller in other laptops.


According to the CPU processor manuals, they all boot in "real mode" which is a 16-bit legacy/bootstrap mode.


Yes, all Intel X86 CPU's start up in 'real mode' which is 16-bit mode.

They start this way because at initial reset none of the required data structures for protected mode operation (page tables, GDT, IDT, etc.) are present. So the CPU starts up as a very fast 8086 who's purpose is to setup just enough page tables, a GDT, an IDT, etc. to be able to switch into protected mode and continue system bootstrap.


There's coverage of that in Apple's Platform Security documentation.

https://support.apple.com/guide/security/uefi-firmware-overv...


Every X86, X86-64 CPU starts in 16bit mode. Because backwards compatibility is king!


The T2's job is to bring the main processor out of reset. The actual booting is standard UEFI, apparently.


There are quite a few laptops on ebay at considerable discounts because the seller doesn't know the BIOS password. This could come in handy.


I'm not sure buying stolen laptops is really the direction we want to go in here.


Stolen? I wouldn't jump to that conclusion so fast. A large source for these are mass sell-offs of old corporate or government gear after the usual 2-5 year upgrade cycle or government sales of impounded devices.


Funny story, I bought a system board on eBay that had a BIOS password on it. The seller didn't answer my messages asking for the password, so I assumed he knew there was a password, but didn't know it (and didn't say in the item description). He just ghosted me. Returning it seemed like a hassle, I really needed it and this was the only one on sale in Europe.

Found the former owner of the laptop where the board came from thanks to the corporate/user name displayed on the password prompt. It was a small IT company.

Contacted them on LinkedIn asking for the password and detailing the situation. Didn't get the password, but the CEO/owner of the company certainly had a surprise.

Turned out one of their guys was selling parts from their laptops/hardware without permission.

Suddenly, the seller on eBay found the message feature and wrote to me, saying I got them in trouble. Shouldn't have ghosted me, then? Just a "sorry, didn't know it had one" and I would've just proceeded to replace the BIOS chip, which was my plan B and it's what I ended up doing.


Stolen is certainly one way laptops (or desktops, I suppose) get locked with unknown passwords. But I've also seen listings for government surplus with unknown passwords.


Thieves are probably more likely to know how to bypass a BIO password than the legit owner.


Agreed. Ask to see the original receipt for anything you buy second hand.


Been a nice little side business for years. So, yeah. Considerable discounts.


Question: how secure are BIOS passwords, really? If you have full-disk encryption anyway, is the BIOS password adding anything?


If you have physical access and a flash programmer they're not secure at all. If you're trying to stop a random passerby from messing with your firmware settings they're great.


The BIOS does control the boot order sequence for instance.

I guess if you have access to it, you could force boot from a malicious USB stick, or the network, that would simulate the disk decryption prompt.

I guess you could also remove security measures that your company put in place to e.g. prevent the usage of USB to prevention information leak.


But to do that you could also just (say) clone the disk drive and install the fake prompt on the disk drive itself, right?


Not if secure boot is enabled, your boot loader most likely would not have a trusted signature.


One is supposed to prevent access to the hardware, one is supposed to prevent access to the data. They're not meant to solve the same problem. But that say, you can only block access to hardware so well, so it's worse in that regard.


well, you could make the machine boot on another device and potentially trick someone into entering their credentials on a "phishing" screen.


They are not secure at all. Full disk encryption is the only way to protect your data in case a stranger has physical access to your device.


That doesn’t help. If they have physical access they can make the system boot into a fake login screen and capture your password.

Securing the bios is necessary.


If someone has that much physical access to your machine they can capture your password far more easily with a physical keylogger assuming you use an external keyboard like one time.


Or apply rubber hose cryptanalysis.

https://xkcd.com/538/


That's not really the same situation, if someone's trying to bug you they don't want to be caught, if they were willing to do illegal violence they'd probably do it first, or if they're a government, you have way bigger problems.


I'm curious if TPM measurements would catch these kind of manipulations. It's probably system specific but the configuration of the BIOS should (as far as I understand it) be captured as part of the measurement process.

If requisite credentials or remote attestation is sealed against a certain measurement value it should protect the system.


The way locking a TPM to firmware config works is that the TPM has several registers called PCRs that contain a hash value. Anything can send data to the TPM and have it update the hash value, and you can lock TPM keys to the PCRs such that you can only use the key when the PCRs you choose have a specific value. The TCG spec defines some of these PCRs to be sent certain information [0], but it's up to the firmware to send it, the TPM doesn't magically know what the state is. If there's even a single setting or nvram variable that you can change to gain code execution that isn't part of the data that's sent to the PCRs that the crypto key is locked to, it's game over.

[0]: https://trustedcomputinggroup.org/wp-content/uploads/TCG-EFI...


BIOS code is PCR 0, config is PCR 1. Software can "extend" certain PCRs as well. Look up Core Root of Trust for Measurement (CRTM) - lot of articles out there. BitLocker can use the capability you describe to protect the hard drive encryption keys. The TPM helps make sure the correct software is in control of the platform before releasing secrets.


It helps but unless you are using the secure channel setup (no one is to my knowledge) attackers can intercept the PCRExtend operations and replace the data being extended.


I was of the impression that BIOS passwords were in general not something one should rely even as a layer when assuming physical access. In the (not that) old days it was usually just a matter of removing the internal battery to reset it. Has this assumption changed in past years?


Still only as secure as cheap padlocks, but battery backed RAMs were replaced with flash, and location for BIOS passwords keeps changing to different locations so not the simple matter of removing the battery anymore.


A bit, as posted in this blog, but for most part having physical unlimited access to a device it's game over. Hence why encrypting your sensitive data should be the norm (I am aware that is not the norm, not by far)


Sure, it's just that the only situation I see a BIOS password making sense is in the presence of some intrusion-detection mechanism that would perform some kind of destruction/lockdown/alarm so that attempting to bypass it would not be without consequences.


They are good for stopping people fiddling in large scale corporate deployments where someones nephew knows how to make the work laptop go faster.


Depends on your definition of encrypted I suppose. Many laptop SSDs are technically encrypted by default, but unless otherwise specified use a default key to unlock the drive.

Sure, they are still not encrypted in any meaningful sense by default, but the barrier to entry is quite far removed by not requiring a long process to enable it. A process which sometimes would require reinstallation, something an average person would likely not bother with.

While installing macOS Catalina the user gets prompted to activate this encryption, providing the system has a disk that supports that kind of full disk encryption I mentioned above.


Catalina doesn't use in-SSD encryption. You either get T2 encryption or FDE via software (FileVault2) which is slower but not disk-dependant either.


I think it's a desktop vs laptop thing. Desktop BIOS is easy to reset by shorting the right jumper/pins, but laptops were made more complicated because they are easier to steal.


Does this also hold for Macbooks?

Edit: A more precise question would be: What is the analogy to Secure Boot and the hardware being locked on a Macbook?


Is there anything actually different? A Macbook is a relatively standard Intel laptop that happens to run MacOS.

The only additional complication might be the T2 chip in the same way that TPMs might be an additional issue in other business laptops.


I don't know. The reason why I ask this is that I want to replace my Macbook's startup chime with something else.


we just use this on the dells at work https://bios-pw.org/


can someone tell me which flash programmer is used here? I also want to play around with UEFI.


We used J-Link with a J-Flash SPI license. https://www.segger.com/products/debug-probes/j-link/tools/j-...

Any SPI flash programmer should work though. The protocol is simple enough that you could even implement it with an arduino if you really needed too.


Not sure what they used here, but I've had good success using a FlashcatUSB on various embedded devices and it has support for a pretty broad variety of flash memory chips.


Not sure what they used, but even a Raspberry Pi + a Pomona clip will do the trick. Have a look at the flashrom wiki, see https://flashrom.org/ISP.


Careful though, and read the datasheet first! AM4, for example, uses 1.8V SPI flash chips. Connecting them to Raspberry Pi directly will at the very least fry the chip, if not the whole board.


TL;DR but why not "open laptop, disconnect BIOS battery for 10 sec, reassemble, done"


I think the article explains that the state they needed to change was stored in flash.


TLDR; remove battery.


Sadly (or fortunately?) that stopped working around 2006


This is about laptops, not desktops. Battery removal only resets the clock, but the password stays on.


Doesn’t matter if it’s laptop or desktop, depends more on how old PC is. I think UEFI machines use NAND or NOR ROM as actually nonvolatile NVRAM.


> We found a laptop laying around the office that had BIOS password enabled.

I really wanted to be a laptop from someone on vacation and that at his come back finds this post instead of the laptop xD


Oh sure, to defeat a BIOS password I'm supposed to have IDA Pro lying around, with license.


So use ghidra or radare2 or free other alternatives instead?


This is cool, but if this is how SkySafe engineers spend their time, they're not gonna be a business for long. There's absolutely zero way that NUM_ENGINEERS * SALARY_PER_HOUR * HOURS_SPENT for this task is even remotely sane compared to just tossing the laptop and buying a new one.

I get that this is kind of content marketing for their engineering department, but damn if they could've prooooobably spent that money on something with more impact


> if this is how SkySafe engineers spend their time, they're not gonna be a business for long

This is the cheapest way of recruiting people in their target field. I have a strong interest in reverse engineering and actually checked out their jobs page. Too bad they are in San Diego.


According to crunchbase they've been around since 2015 and had their last funding round in mid 2017. I doubt they're in such a crunch that they can't spend a few days for the team to focus on a fun and common interest without breaking the company.


But if you let them have fun once, they're going to want to have fun ALL THE TIME. ;D


Or you can bill it as internal education. Not everything has to be min/maxed like that, even in this late stage capitalism world.


Doing it once is R&D. Doing it multiple times is a service. Having the capability if it's needed for something more valuable? Priceless.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: