Finding Bios Password With Qbasic!

[Guest_imported]

What is the best way to get information from the bios
If you have any idea please write...

David@Daw Corp, 1999-2002

 

[Alt255]

You can't retrieve that password with Qbasic.

If you PEEK around in the first meg of memory, you'll find lots of other interesting data. Go to thread314-187694 and follow the inter-Tek-Tips links. That's a good start.

You might want to write a little routine to dump the contents of ROM-BIOS memory so you can see what's in there.

 

[logiclrd]

Actually, you CAN obtain the password that way, or at least information about the password, but it is specific to each BIOS. Many older BIOSes store the password in plaintext in the CMOS mapped memory. With these BIOSes, it is simply a matter of knowing where to look for the password. Somewhat more modern BIOSes stored the password XOR encrypted (some new ones today do this too), and you can decrypt the password, as long as you know where it is (but you can't search for it as easily -- you might have to dig through disassembly of the BIOS code). The newest BIOSes, though, usually don't actually store the password itself. They store a number calculated from the password, a so-called "hash" of the password. Then, when you are prompted for the password, it runs the same hash on what you enter and checks it against what is stored. Hashes are typically very difficult to reverse (the term they use in the industry is "computationally infeasible&quot, and thus you cannot actually get the password, nor can you find another password that produces the same hash (if indeed such a password exists -- many hashing functions are specifically designed to be 1-to-1, meaning that every hash corresponds to exactly one input). There are companies and people who specialize in retrieving BIOS passwords, and on most BIOSes the password can be reset with just the right [tt]POKE[/tt]. Also, nearly all newer motherboards have a place for a jumper which, when shorted (i.e., connected), will erase the entire CMOS memory. This is not usually a problem for newer BIOSes either, because they discover nearly all that information for themselves during the POST (Power-On Self Test), though for older BIOSes you should jot down the settings (if you have access to them) before clearing the CMOS. There is a sort of ad-hoc standard for the way at least the simpler information is stored in the CMOS, and there exist DOS programs that can access the CMOS in that way, if it is indeed in that format (I can't remember any names offhand, though). Good luck

 

[Alt255]

This discussion prompted some curiosity on my part. What if I was wrong and the CMOS password was actually stored in RAM?

So I wrote a little utility to allow me to compare the contents of the first meg of memory after adding, modifying and changing the password. I used the memory dumping routine (found in the Tek-Tips Qbasic FAQ section) to save the first meg on bootup after adjusting the various password settings in the CMOS. Then I wrote a few lines of code to compare the various memory dumps to search for differences.

The ROM BIOS area was identical in each instance on my test machine (Award BIOS v4.51PG Release 07/11/1998 S). Not even a flag had been set to indicate that a password was in use.

Of course, logiclrd is right. There are a gazzilion flavors of BIOSes and each one handles passwords differently.

Imagine trying to crack the password scheme on even one of them: let's suppose that the BIOS is ancient and actually stores the password in RAM... first, let's suppose that it is stored in clear text... a curious programmer would only have to search the first meg for interesting strings and then reboot to try them out. (Does anybody see a problem with this logic?) That would be way too easy. Let's say that the password has been stored after some sort of simple XOR transformation... the programmer would only have to do as I did, change the password and search for differences before and after, and then try to find the combination of values that convert the strings into clear text. A bit harder, but still way too easy. Let's say that password isn't actually stored in RAM or any other place... the BIOS only saves a hash value. Now the whole process becomes rather time consuming. The programmer sits at the console trying to guess the password. Failing that, he opens an unabridged dictionary and trys every word in the english language. With no success, he writes a program to generate every possible combination of letters and digits and laborously enters them at the password prompt. This could take, oh, about 3269461294 years, adjusting for fatigue, periodic breaks, vacations, senility, death, etc. (Don't bother asking how I derived that value. I strummed my fingertips on the numeric keypad and it appeared, as if by magic.)

Most of your efforts to evaluate a password scheme will be complicated by the fact that you will have to know the password to discover it. In almost every case, you will have to be able to destroy or change the password in order to find it. There goes any possibility of simply running a Qbasic program to print out the password.

I think I'll have to stick with my original answer. Almost without exception, you can't find the BIOS password using Qbasic.

Of course, if you have a lot of time on your hands, you could always try.

 

[trollacious]

Once you have access to the hard drive, what do you need the BIOS password for on a computer, other than curiosity? Just curious. # (bearded smiley face)

 

[logiclrd]

Reclamation of resources?

Alt255 -- you don't need to search the first megabyte of memory, only the CMOS-mapped memory. I can't remember exactly what this is offhand (I think the size varies between different BIOSes), but it is usually around segment C000h.

 

[Alt255]

Understood, logiclrd. And you are correct... &HC000 and above are reserved for ROM. And although I noted that "the ROM BIOS area was identical in each instance on my test machine...", I actually compared the snapshots taken above C000, and not just the ROM BIOS area, which starts at E000.

Many apologies.

Regarding the passwords... this is the way it used to work.... If anybody has a primitive machine lying around, you might try this to try to figure out the password: First, remove the password from the CMOS and execute these lines of code to get a "baseline":[tt]

CLS
PRINT "The encrypted password is: ";
FOR Re = &H38 TO &H3D
OUT &H70, Re
PRINT HEX$(INP(&H71)); " ";
NEXT
[/tt]
The password seed will be stored at offset &H37 of CMOS memory and you can retreive it with:
[tt]
OUT &H70, &H37
PRINT HEX$(INP(&H71))
[/tt]
Change the password, reboot and record the various values output by Qbasic a few times. Then try to find a way to recreate each password by transforming each encrypted password with the coresponding password seed (note that the actual seed is stored in bits 7-4 at offset &H37).

Good luck.

How will you know your BIOS supports this scheme? If the values stored at offsets &H38 through &H3D do not change after changing your password, you can safely trash this idea and start looking for a more difficult approach.