Reset BIOS Passwords – An Explanation and Tool
I’ve been seeing a lot of sites throwing around a “how to reset BIOS passwords” tip that revolve around using the DOS/Windows DEBUG tool. In case you haven’t seen it, it goes a little like this:
- Create a boot floppy/disc with the debug tool on it
- Type -o 70 2e
- Type -o 71 FF
- Type quit
- Reboot
Curious as to why this works? So was I, but none of the sites I saw included an explanation. So after some googling, I uncovered the nitty-gritty details.
The CMOS memory is actually accessible to the user for reading and writing. I’m not aware of a recent operating system that doesn’t restrict write access to the administrator/super user, but it is there nontheless. It contains a lot of information, such as the system time (direct access to the real-time clock), BIOS information, and CMOS data. With this knowledge, I would suggest taking a look at this link, which is a reference to how the CMOS memory is laid out. It is what I used to determine what the hex values being output were doing.
The -o option of debug just outputs a value to an io port. The CMOS memory is accessed through ports 70 and 71, which explains the first parameter of the steps above. The second part can be seen from the CMOS reference I linked to above – by latching the address 0×2e for writing, and then setting its value to 0xff, we are manually telling the CMOS that it has an invalid checksum. The behavior when this occurs is to revert to the default BIOS, a feature which is supported independent of operating system or processor architecture – ie, any AT/ATX motherboard will do this.
None of the sites list instructions for if you are a Linux user, and assume you’ll have access to the debug program. So, now understanding how this specific utilization of debug worked, I wrote my own version in C. It can be compiled using gcc, and is compatible with all *nix distributions – so add it to your rescue LiveCD toolkit, you never know when you’ll need it :)
Here is the source:
resetBIOS.c
#include <stdio.h > #include <stdlib.h> #include <unistd.h> #include <sys/io.h> /* Written by Robert Peaslee - www.robertpeaslee.com */ /* compile: gcc -o resetBIOS resetBIOS.c */ /* Run as superuser. */ int main() { /* Allow writing to ports 70 and 71 */ if( ioperm(0x70, 1, 1) || ioperm(0x71, 1, 1) ) { perror("Error setting write permissions"); printf("\n"); exit(1); } /* output 0x2e to port 70, which is the address where the * CMOS checksum is stored */ outb(0x2e, 0x70); /* Small sleep to allow the changes to take effect. */ usleep(100000); /* Tell the CMOS that the checksum is bad, forcing it to * load the default BIOS on reboot. */ outb(0xff, 0x71); /* Reset the port permissions to not be writeable */ if( ioperm(0x70, 3, 0)) { perror("Error restoring permissions"); printf("\n"); exit(2); } exit(0); }And if you only want the assembly specific portions without relying on external libraries:
out 70, 0x2e out 71, 0xff…but note you’ll have to add your own data/text sections and a main: entry point if you want to actually assemble it. Additionally, you’ll have to convert this to at&t syntax if you want to inline it in C code using the gcc compiler.
So there you have it – a full explanation of why it works, an example in C, and a complete reference of the layout of CMOS memory. If you still have questions, leave them in the comments!
Very informative; I never even knew that you could reset the BIOS on a running machine.
Feb 19th, 2008 at 10:38 am
Now, let’s suppose we could fire this code off arbitrarily on an unsuspecting computer. What exactly can we do to the bios other than resetting the password?
Jun 12th, 2009 at 12:55 am
@Dzugavili – not much. First, you would have to have administrative access on that machine before you could use this script. If you have administrative access remotely, you probably don’t care about any restrictions at the BIOS level anyway, as changes there aren’t going to affect you too much. The exception to this is if hardware restrictions are enforced in the BIOS and you would like those removed.
Alternatively, if you have local access, removing the BIOS password grants you the ability to set your own password and change any options.
From a security standpoint for most users, neither of these are really a big deal.
Jun 17th, 2009 at 9:39 pm
I think more can be done, though not with this script.
I have seen on my own machines several examples of how the bios can be altered without my knowledge or permission. I’ve had the time and date changed on me, usually the symptom I look for to know when “something” was at work! I never did find out why, but I once had to re-flash my bios before I could install XP after installing a linux os. In that example, all I could see by looking through the bios settings was that the time and date were changed. I have to consider that the linux installation left my bios non-windows friendly, as I remember being able to re-install the linux several times all the while not getting anywhere with putting XP back in place.
I have the UBCD4Win, and it has a utility that was able to read the user and supervisor password to my gateway solo, without deleting the passwords. That utility was also supposed to be able to reset the passwords, but failed at that. So strange things are possible…
Jun 23rd, 2009 at 4:43 pm
@BkWdsDrftr: I definitely agree that you can cause strange things to happen by playing with the BIOS, my response was only that there are no real extravagant security implications from doing being able to do so. I hadn’t heard of your problems with the BIOS causing problems at a level higher than hardware before – thanks for putting it on my radar :D
Jun 29th, 2009 at 1:45 pm