View Full Version : Recover Bios Password and Activate Button on Dialog
peterg70
December 29th, 2005, 07:07
Ok background information.
I have received a laptop that had self nuked and need to be rebuild and of course the boot order was incorrect so I wanted access to the bios but no luck (idiot put password on the bios).
Anyway managed to pull the harddisk out and rebuild XP with image booting to command prompt which allow installation of XP onto the harddisk even though boot order was still wrong.
This a newer bios real pain to reset password etc. So instead Downloaded the configuration ultility from the supplier and install Control panel interface. When executed this prompts for the administrator password for the bios.
Okay time to have a look see.
Launched Ollydbg and attached and Scanned for MessageBox. Entered wrong password bang fell into the routine checking the initial password.
Now first question how does this software communicated to bios. Seems to be sendmessageA etc to interface with Bios. I was hoping that the password check was done in the memory but it seems the bios returns an error code depending on the password.
Anyway a quick patch on the EAX allowed me to access the boot sequence and everything else in the bios. So problem solved without password so far.
Interestingly review of password change option shows Power On password button showing "SET" while Administrator password shows "CHANGE". Quick review with reshacker found that there are two buttons located on top of each other.
Obviously the software hides the buttons.
Did a quick trap on ShowWindow (This is a tabbed dialog) which doesn't set the button WS_VISIBLE status. Set Trap on GetDlgItem etc but system doesn't use this.
Now second question
What other API are used to show and hide buttons on the screen. Is there a method to stop the system from hiding the button.
I have used reshacker to change the location of the buttons so they are not ontop of each other.
Anyway any thoughts would be appreciated.
peterg70
December 29th, 2005, 09:11
Okay just a quick update
Used WinInspector Spy to adjust the WS_VISIBLE and WS_DISABLED Options for the "SET PASSWORD" button but using this didn't work anyway.
So back to first question.
How does software talk to the BIOS and can the bios perform a password check or is it done in the software.
CluelessNoob
December 29th, 2005, 11:52
Not to rain on your fun, but why don't you just reset the password the easy way?
Every PC/Laptop I have ever seen can be defeated by simply removing AC power and the backup battery. And 90% of them made in the last 3 - 4 years also include some kind of even easier hardware reset (pushbutton on MB, jumper two pins on a serial port, etc).
Or even easier still, try contacting the manufacturer. Tell them you bought it at an auction as part of a larger lot of computers and you need to know how to reset the BIOS.
naides
December 29th, 2005, 14:33
BIOS interactions are performed, as far as I know, with Ring0, privileged instructions, such as port reading and writing (in, out) and hardware interrupts. Chances are that your configuration utility uses a device driver or similar device to do the actual exchange and resetting the BIOS. Olly will not take you all the way there. Perhaps not even SoftIce will let you see or the password validation at the BIOS level (There is a small chance the configuration utility performs its own independent, password validation, unlikely).
In another thread here one or two years ago, someone had dumped the BIOS content and was trying to reverse it. The problem is that BIOS routines not necessarily need to be in X86 assembly language, so the code may look quite foreign to any one in here.
I once had a similar problem and found some web sites dedicated to by-passing the BIOS password settings: including default/backdoor passwords for certain MB manufacturers, jumper manipulation and to replacing the CMOS battery with inverse polarity( and praying it does not fuck up the MB circuitry)
peterg70
December 29th, 2005, 19:47
Reseting the password is easy to do with this system but I wish to recover the password if possible.
I like not modify someone elses system when I can gain access by recovery of passwords etc.
Using cmospwd recovery tools have proven to not work at all.
Admiral
December 29th, 2005, 20:03
Perhaps this isn't quite in the spirit of 'constructive commenting', but can we even be sure that it is possible to retrieve the password? I mean, it's possible that the BIOS doesn't store the password as-is (or in a reversible way) but rather it maintains a CRC value or something similar.
Well if you are going to be able to recover this password, you'd be extremely lucky to do so using a ring3 debugger. My advice would be (as has already been said) to dredge out that old copy of SoftICE and look for any harware interfacing as described in naides's post.
nikolatesla20
December 29th, 2005, 20:41
Quote:
[Originally Posted by naides]BIOS interactions are performed, as far as I know, with Ring0, privileged instructions, such as port reading and writing (in, out) and hardware interrupts. Chances are that your configuration utility uses a device driver or similar device to do the actual exchange and resetting the BIOS. Olly will not take you all the way there. Perhaps not even SoftIce will let you see or the password validation at the BIOS level (There is a small chance the configuration utility performs its own independent, password validation, unlikely).
In another thread here one or two years ago, someone had dumped the BIOS content and was trying to reverse it. The problem is that BIOS routines not necessarily need to be in X86 assembly language, so the code may look quite foreign to any one in here.
I once had a similar problem and found some web sites dedicated to by-passing the BIOS password settings: including default/backdoor passwords for certain MB manufacturers, jumper manipulation and to replacing the CMOS battery with inverse polarity( and praying it does not fuck up the MB circuitry) |
That bold part sounds interesting - are you talking about a "Jam table" or a small virtual execution engine? I know in the book "Hacking the XBOX" they mention jam tables and that the BIOS runs basically as a type of interpreter at some stages..
-nt20
naides
December 29th, 2005, 22:58
@-nt20:
I do not seem to be able to locate the text/web site right now, but I clearly remember reading somewhere about security features in new motherboards flash BIOS being implemented in proprietary code immune to typical tracing, disassembling and debugging. I will dig it out.
LLXX
December 30th, 2005, 01:02
@naides,nt20: I think you've confused this with Trusted Computing hardware. The BIOS *is* written in x86 Asm, but its code is very convoluted due to its operating environment - it has to fit within the limited confines of a flash ROM while providing all of the necessary services; as virtual machine interpreters can reduce code size, I can see such technology being implemented in the BIOS.
Most BIOS passwords are stored in 'hashed' form in the CMOS memory. However, the 'hash' algorithm is extremely insecure and produces a 16-bit hash in most cases, with large amounts of collisions. For example:
http://cert.uni-stuttgart.de/archive/vuln-dev/2000/07/msg00289.html
naides
December 30th, 2005, 15:12
You are right LLXX. I confused two ideas: Certain chips of ad-on hardware contain microprocessors that run with simplified and non-conventional ASM. That idea got mixed into my mind with debugging the ROM BIOS which is written in conventional X86 ASM and processed by the regular CPU, BUT 1. It is hard to trace with a debugger (Software breakpoints needed for step tracing do not "stick" in ROM and 2. use quite unconventional code and instructions because ther are no APIs and no HAL and nothing else.
My apologies for my incorrect statement.
peterg70
December 30th, 2005, 19:11
Some further Analysis has found the following
Please comment or provide direction if possible
Each key stroke is not stored as a letter but rather a keyboard code. i.e. the letter Q is 0x10 W is 0x11 etc Uppercase/lowercase makes no difference.
The program uses DeviceIOControl a few times but they seem directed to 70 (Window).
Also uses Sendmessage as well.
IS there any API I should monitor for communication to the BIOS. I would think the windows version of the software would load the checksum or similar and do a comparison but I have yet to find it.
The system comes with a Security Chip which may or maynot have an impact on this password (well removing the security chip made no difference for the password).
I accept I may not be able to recover the password directly but I should be able to generate the same checksum and therefore find collisions and perhaps recover the original password by bruteforce.
LLXX
December 30th, 2005, 21:26
Quote:
[Originally Posted by peterg70]Each key stroke is not stored as a letter but rather a keyboard code. i.e. the letter Q is 0x10 W is 0x11 etc Uppercase/lowercase makes no difference. |
This is quite typical of BIOS passwords. One question: Is the maximum length of the password 6, 8, or some other number of characters?
Quote:
[Originally Posted by peterg70]The program uses DeviceIOControl a few times but they seem directed to 70 (Window). |
Port 70? That would be the CMOS memory. http://www.codepedia.com/1/CMOS_C
Quote:
[Originally Posted by peterg70]IS there any API I should monitor for communication to the BIOS. I would think the windows version of the software would load the checksum or similar and do a comparison but I have yet to find it. |
Monitor reads and writes to ports 70 and 71 (h).
Quote:
[Originally Posted by peterg70]The system comes with a Security Chip which may or maynot have an impact on this password (well removing the security chip made no difference for the password). |
I don't think that matters, given the description you've been providing so far.
MarcElBichon
December 31st, 2005, 08:25
maybe this can help you (with source) : http://www.cgsecurity.org/cmospwd.html
peterg70
January 1st, 2006, 06:44
@MarcElBichon
I have already tried cmospwd with no luck as stated above.
Still probing and reviewing but with new year alcohol will need a few days to empty out the volume.
laola
January 1st, 2006, 22:23
I am currently fighting a similar problem, a friend came up with a Thinkpad he bought second-hand which has the supervisor password set. Without this password, no hardware changes are possible and half of the bios options are hidden. I already found out that the system stores "something" (probably a hash) in a serial eeprom on the mainboard which is separated from the common CMOS ram. After googling for more than half a day, I just found tons of websites offering "unlocking" for money. Isn't there any helpful documentation available anywhere? I'd even go for reversing the bios, but of course I wouldn't want to invent the wheel once more

LLXX
January 2nd, 2006, 01:02
Quote:
[Originally Posted by laola]I am currently fighting a similar problem, a friend came up with a Thinkpad he bought second-hand which has the supervisor password set. Without this password, no hardware changes are possible and half of the bios options are hidden. I already found out that the system stores "something" (probably a hash) in a serial eeprom on the mainboard which is separated from the common CMOS ram. After googling for more than half a day, I just found tons of websites offering "unlocking" for money. Isn't there any helpful documentation available anywhere? I'd even go for reversing the bios, but of course I wouldn't want to invent the wheel once more  |
Have you tried filling the CMOS RAM with nulls? That kills all the settings and most times the BIOS will complain and let you into the setup to "correct" the erased settings.
laola
January 2nd, 2006, 01:57
Quote:
[Originally Posted by LLXX]Have you tried filling the CMOS RAM with nulls? That kills all the settings and most times the BIOS will complain and let you into the setup to "correct" the erased settings. |
Thinkpads are a bit different from common PCs concerning the security design. As I mentioned before, at least the supervisor password is not stored in the CMOS ram. Even worse, if you zero out the CMOS ram content of a functioning Thinkpad that has the supervisor password set, the notebook will be practically dead on next boot because reconfiguring the bios requires the supervisor password. That means no more booting at all if the supervisor password is unknown. On suitable hardware, setting the SVP (supervisor password) will even cause a hard disk password (as specified in the ATA specs) to be set - such a hard disk will not work in another comp unless the password is supplied at boot time.
peterg70
January 2nd, 2006, 08:28
@laola
I managed to modify the setting in the bios from Windows by downloading the BiosSetup facility/Control panel interface.
The interface still checks for the password but a quick patch allows the software to update the bios boot options etc.
Hopefully this will assist you.
peterg70
hadicol
January 2nd, 2006, 22:28
The front-end setup application wont do the actual work, it will just interact with the device driver. Only drivers can do that low-level stuff. It sounds like the driver is opened with CreateFile() and the returned handle is passed to DeviceIoControl(). You could find the device driver filename that way and disassemble it to get the important logic. Or debug the driver with a ring0 debugger (softice).
The virtual dos driver lets me dump the first 64 bytes of CMOS memory but then it just repeats. Password bytes are blank too.
laola
January 3rd, 2006, 11:41
The passwords are probably stored elsewhere... in the case of IBM/Lenovo Thinkpads, it is usually a serial eeprom. Now you just have to find out how the windows driver talks to the serial eeprom (if it does that at all...) - or you have to reverse the bios

This isn't necessarily easy as the bios setup is usually compressed and decompressed to main memory when needed. Quite a bit of fiddling, I fear.
Somebody (Naides?) earlier in this thread mentioned that there were some achievements about reversing bioses some time ago, maybe we could use these findings as a starting point (if they can be found *g*). While wading through tons of google results I just managed to find a host of people offering unlocking services of several kinds, but not a single source that would show some detail information about what happens under the hood.
I guess I will have to disassemble this notebook and remove the serial eeprom to dump the content. Maybe this can shed some light on the issue

naides
January 3rd, 2006, 15:02
@Laola:
http://www.woodmann.com/forum/showthread.php?t=6682
_xhp_
January 3rd, 2006, 16:07
This is a very interesting link for anyone into BIOS reversing - there is also some (very interesting) info/links about password restoring
http://community.reverse-engineering.net/viewtopic.php?t=3468
LLXX
January 4th, 2006, 02:26
Quote:
[Originally Posted by laola]I guess I will have to disassemble this notebook and remove the serial eeprom to dump the content. Maybe this can shed some light on the issue  |
"When reversing the software isn't enough, start reversing the hardware!" Sounds like a good idea to me

Powered by vBulletin® Version 4.2.2 Copyright © 2018 vBulletin Solutions, Inc. All rights reserved.