BIOS password question

Archived from groups: microsoft.public.win98.gen_discussion (More info?)

I recently had to use a BIOS password cracking utility to recover my
forgotten supervisor password. The password it gave me was all numbers
and I know I wouldn't have used that when I originally set the password.
Does it really store the password, or does it store some sort of
checksum, whereby any password that produces the same checksum would work?

BTW it took about .5 seconds for the program to crack the password, so
anyone who thinks as I did previously that bios passwords are a good way
to secure a machine is sadly mistaken. Sort of reminds me of an old Dr
Who episode

"There's nothing more useless than a lock with a voice print" - Dr Who,
The Invasion of Time, 02/11/1978

--
To reply by email remove "_nospam"
20 answers Last reply
More about bios password question
  1. Archived from groups: microsoft.public.win98.gen_discussion (More info?)

    In news:37h7b9F5a0ns8U1@individual.net,
    Chuck <skilover_nospam@softhome.net> had this to say:

    > Does it really store the password, or does it store some
    > sort of checksum, whereby any password that produces the same
    > checksum would work?

    No. Not as far as I know at any rate. Low battery power maybe??? An odd
    result I suppose but I don't really know what else could have caused that
    unless someone else had physical access to the computer. Heck, I don't even
    know if a low battery could cause it but I can't think of anything else that
    might have caused it other than a rather old virus that was embedded in a
    BIOS update but do people even write those any more?

    Galen
    --

    "My mind rebels at stagnation. Give me problems, give me work, give me
    the most abstruse cryptogram or the most intricate analysis, and I am
    in my own proper atmosphere. I can dispense then with artificial
    stimulants. But I abhor the dull routine of existence. I crave for
    mental exaltation." -- Sherlock Holmes
  2. Archived from groups: microsoft.public.win98.gen_discussion (More info?)

    "Galen" <galennews@gmail.com> wrote in message
    news:OQJ5QiEFFHA.3728@TK2MSFTNGP14.phx.gbl...
    > In news:37h7b9F5a0ns8U1@individual.net,
    > Chuck <skilover_nospam@softhome.net> had this to say:
    >
    >> Does it really store the password, or does it store some
    >> sort of checksum, whereby any password that produces the same
    >> checksum would work?
    >
    > No. Not as far as I know at any rate. Low battery power maybe??? An odd
    > result I suppose but I don't really know what else could have caused that
    > unless someone else had physical access to the computer. Heck, I don't
    > even
    > know if a low battery could cause it but I can't think of anything else
    > that
    > might have caused it other than a rather old virus that was embedded in a
    > BIOS update but do people even write those any more?
    >
    > Galen
    > --
    >
    > "My mind rebels at stagnation. Give me problems, give me work, give me
    > the most abstruse cryptogram or the most intricate analysis, and I am
    > in my own proper atmosphere. I can dispense then with artificial
    > stimulants. But I abhor the dull routine of existence. I crave for
    > mental exaltation." -- Sherlock Holmes
    >
    >

    here is something i came across

    <snip>
    Award BIOS treats its password as an ASCII string of maximum length 8,
    consisting only of characters in the range ' '-'', which have values
    32-127. Each of those values is expanded to an unsigned word and rolled
    two bits further left than the next one in the string, where the last
    character is rolled zero bit positions. Then they are all added together
    to produce one word, which is stored in CMOS (LSB in register 0x1c, MSB
    in 0x1d).
    /<snip>
  3. Archived from groups: microsoft.public.win98.gen_discussion (More info?)

    "Haggis" <bingsnapREMOVE@THIShotmail.com> wrote in message
    news:%23F3u$XFFFHA.2828@TK2MSFTNGP09.phx.gbl...
    >
    > here is something i came across
    >
    > <snip>
    > Award BIOS treats its password as an ASCII string of maximum length 8,
    > consisting only of characters in the range ' '-'', which have values
    > 32-127. Each of those values is expanded to an unsigned word and rolled
    > two bits further left than the next one in the string, where the last
    > character is rolled zero bit positions. Then they are all added together
    > to produce one word, which is stored in CMOS (LSB in register 0x1c, MSB
    > in 0x1d).

    Giving rise to Candlin's Eighth Law of Computing

    "For every encrypter, there is an equal and opposite decrypter".
  4. Archived from groups: microsoft.public.win98.gen_discussion (More info?)

    In news:%23F3u$XFFFHA.2828@TK2MSFTNGP09.phx.gbl,
    Haggis <bingsnapREMOVE@THIShotmail.com> had this to say:

    > <snip>
    > Award BIOS treats its password as an ASCII string of maximum length 8,
    > consisting only of characters in the range ' '-'', which have values
    > 32-127. Each of those values is expanded to an unsigned word and
    > rolled two bits further left than the next one in the string, where
    > the last character is rolled zero bit positions. Then they are all
    > added together to produce one word, which is stored in CMOS (LSB in
    > register 0x1c, MSB in 0x1d).
    > /<snip>

    I just downloaded the source (pascal) for a BIOS password recovery tool.
    It's interesting to look into at any rate but I don't see why/how a bunch of
    numbers would create the hash value of the original password as each letter
    and number has an assigned value before it's encrypted and each would create
    a unique key based on those and that key would be unlike any other key.
    Example would be if my password were "password" no amount of numbers should
    create the same values that are stored. It could be decrypted (and from the
    looks of the information you've given us that wouldn't be *too* difficult
    for someone with the knowledge though I don't think I'd try it personally)
    but the decrypted password should still be the password that you started
    with and in this case it wasn't.

    From the looks of the source code that this has with it:

    http://www.11a.nu/index.php?menuValue=15&chooseType=art&chooseValue=27

    They have a function called blasters which aren't very safe from what they
    say. What could have happened might have been that the application that the
    OP used was one that did that and then wrote a generic password over the
    original values and gave the OP that value instead of the older one. Faster
    perhaps than decryption might have been? Just vague ideas but they seem to
    be on track.

    Galen

    --

    "My mind rebels at stagnation. Give me problems, give me work, give me
    the most abstruse cryptogram or the most intricate analysis, and I am
    in my own proper atmosphere. I can dispense then with artificial
    stimulants. But I abhor the dull routine of existence. I crave for
    mental exaltation." -- Sherlock Holmes
  5. Archived from groups: microsoft.public.win98.gen_discussion (More info?)

    "Galen" <galennews@gmail.com> wrote in message news:evzsF2FFFHA.1188@tk2msftngp13.phx.gbl...
    > In news:%23F3u$XFFFHA.2828@TK2MSFTNGP09.phx.gbl,
    > Haggis <bingsnapREMOVE@THIShotmail.com> had this to say:
    >
    >> <snip>
    >> Award BIOS treats its password as an ASCII string of maximum length 8,
    >> consisting only of characters in the range ' '-'', which have values
    >> 32-127. Each of those values is expanded to an unsigned word and
    >> rolled two bits further left than the next one in the string, where
    >> the last character is rolled zero bit positions. Then they are all
    >> added together to produce one word, which is stored in CMOS (LSB in
    >> register 0x1c, MSB in 0x1d).
    >> /<snip>

    > I just downloaded the source (pascal) for a BIOS password recovery tool.
    > It's interesting to look into at any rate but I don't see why/how a bunch of
    > numbers would create the hash value of the original password as each letter
    > and number has an assigned value before it's encrypted and each would create
    > a unique key based on those and that key would be unlike any other key.
    > Example would be if my password were "password" no amount of numbers should
    > create the same values that are stored.

    Using the above algorithm, there are a good number of strings that
    will produce same word values. All you have to do is take a bit out of
    one char, and place it in another in the correct bit[x] position to
    end up with the same sum. It's not really a hash or encyption , but
    just a simple algorithm to "compress" the value, which has the side
    effect of also hiding it a little.

    You'd still have to know where it is and how to work back through the
    algorithm. But it wouldn't be too hard to work through. The odds of
    getting the exact password string that the user entered (assuming more
    than 1 or 2 characters) would still be fairly high, though apparently
    not really necessary.
  6. Archived from groups: microsoft.public.win98.gen_discussion (More info?)

    In news:%23JL5dAKFFHA.3376@TK2MSFTNGP12.phx.gbl,
    Bill Blanton <bblanton@REMOVEmagicnet.net> had this to say:

    > Using the above algorithm, there are a good number of strings that
    > will produce same word values. All you have to do is take a bit out of
    > one char, and place it in another in the correct bit[x] position to
    > end up with the same sum. It's not really a hash or encyption , but
    > just a simple algorithm to "compress" the value, which has the side
    > effect of also hiding it a little.
    >
    > You'd still have to know where it is and how to work back through the
    > algorithm. But it wouldn't be too hard to work through. The odds of
    > getting the exact password string that the user entered (assuming more
    > than 1 or 2 characters) would still be fairly high, though apparently
    > not really necessary.

    *thinks* So (and this is entirely made up) for example a password value of
    "mypass" could have the same value as 112211? Meaning that if I were to sit
    there long enough and enter random numbers into the bios password prompt
    that eventually (think the 100 monkeys and the 100 typewritters) the numbers
    would work while the original password was made of alphabetic characters?
    I'd never known this. I have no intentions of trying this with the various
    utilities that are out there for me already but I suppose that's interesting
    to know.

    Galen
    --

    "My mind rebels at stagnation. Give me problems, give me work, give me
    the most abstruse cryptogram or the most intricate analysis, and I am
    in my own proper atmosphere. I can dispense then with artificial
    stimulants. But I abhor the dull routine of existence. I crave for
    mental exaltation." -- Sherlock Holmes
  7. Archived from groups: microsoft.public.win98.gen_discussion (More info?)

    Galen wrote:
    > In news:%23JL5dAKFFHA.3376@TK2MSFTNGP12.phx.gbl,
    > Bill Blanton <bblanton@REMOVEmagicnet.net> had this to say:
    >
    >
    >>Using the above algorithm, there are a good number of strings that
    >>will produce same word values. All you have to do is take a bit out of
    >>one char, and place it in another in the correct bit[x] position to
    >>end up with the same sum. It's not really a hash or encyption , but
    >>just a simple algorithm to "compress" the value, which has the side
    >>effect of also hiding it a little.
    >>
    >>You'd still have to know where it is and how to work back through the
    >>algorithm. But it wouldn't be too hard to work through. The odds of
    >>getting the exact password string that the user entered (assuming more
    >>than 1 or 2 characters) would still be fairly high, though apparently
    >>not really necessary.
    >
    >
    > *thinks* So (and this is entirely made up) for example a password value of
    > "mypass" could have the same value as 112211? Meaning that if I were to sit
    > there long enough and enter random numbers into the bios password prompt
    > that eventually (think the 100 monkeys and the 100 typewritters) the numbers
    > would work while the original password was made of alphabetic characters?
    > I'd never known this. I have no intentions of trying this with the various
    > utilities that are out there for me already but I suppose that's interesting
    > to know.
    >
    > Galen

    I guess one way to test these theories is to rerun the password cracker
    and see if it comes up with what I now know the password to be (I reset
    it to something else recovering it). If not, and both passwords work,
    it's a simple hash or checksum algorithm and neither is very safe. If I
    get a chance to do this I'll post the results. If someone else wants to
    try it first, have at it.

    BTW this is an AWARD bios that's in question. Can't remember the exact
    version number though and that PC is currently in another state.

    --
    To reply by email remove "_nospam"
  8. Archived from groups: microsoft.public.win98.gen_discussion (More info?)

    Not quite - rerun the password cracker, and when it comes up with a password
    tell it to continue (if there is such an option) and it will find the next
    match, and the next etc until it eventually finds the one you actually used.
    The fact that it's finding numeric passwords indicates it's starting from
    the bottom and working up.
    --
    Jeff Richards
    MS MVP (Windows - Shell/User)
    "Chuck" <skilover_nospam@softhome.net> wrote in message
    news:37k8kkF5f7evpU1@individual.net...
    > Galen wrote:
    >snip <
    >
    > I guess one way to test these theories is to rerun the password cracker
    > and see if it comes up with what I now know the password to be (I reset it
    > to something else recovering it). If not, and both passwords work, it's a
    > simple hash or checksum algorithm and neither is very safe. If I get a
    > chance to do this I'll post the results. If someone else wants to try it
    > first, have at it.
    >
    > BTW this is an AWARD bios that's in question. Can't remember the exact
    > version number though and that PC is currently in another state.
    >
    > --
    > To reply by email remove "_nospam"
  9. Archived from groups: microsoft.public.win98.gen_discussion (More info?)

    Jeff Richards wrote:
    > Not quite - rerun the password cracker, and when it comes up with a password
    > tell it to continue (if there is such an option) and it will find the next
    > match, and the next etc until it eventually finds the one you actually used.
    > The fact that it's finding numeric passwords indicates it's starting from
    > the bottom and working up.

    But if the first match it finds works as the password, and so does the
    one I know it to be, it proves my point. That all it's doing is hashing
    or checksumming what you enter at the password prompt and comparing that
    to some stored value that is NOT the actual password.

    --
    To reply by email remove "_nospam"
  10. Archived from groups: microsoft.public.win98.gen_discussion (More info?)

    Yes - I was agreeing that it's simply a form of checksum, and that the
    checksum will be the same for many different passwords. But simply
    re-running the cracker is not going to create a different result - it will
    give you the same number, because it's simply starting at the beginning (eg
    00000000) and working forward. You need to force it to find the _next_
    result (if it has such a facility).

    You can work out approximately how many passwords will match by calculating
    the possible number of passwords and the possible number of checksums. If
    passwords can be 8 upper case letters or 0 to 9, then there can be 36^8
    passwords. If the checksum is 16 bits then there can be 65536 checksums.
    That's an awful lot of passwords for each checksum.
    --
    Jeff Richards
    MS MVP (Windows - Shell/User)
    "Chuck" <skilover_nospam@softhome.net> wrote in message
    news:37kjgdF5epdg8U1@individual.net...
    > Jeff Richards wrote:
    >> Not quite - rerun the password cracker, and when it comes up with a
    >> password
    >> tell it to continue (if there is such an option) and it will find the
    >> next
    >> match, and the next etc until it eventually finds the one you actually
    >> used.
    >> The fact that it's finding numeric passwords indicates it's starting from
    >> the bottom and working up.
    >
    > But if the first match it finds works as the password, and so does the
    > one I know it to be, it proves my point. That all it's doing is hashing
    > or checksumming what you enter at the password prompt and comparing that
    > to some stored value that is NOT the actual password.
    >
    > --
    > To reply by email remove "_nospam"
  11. Archived from groups: microsoft.public.win98.gen_discussion (More info?)

    In news:eXecjSUFFHA.3908@TK2MSFTNGP12.phx.gbl,
    Jeff Richards <JRichards@msn.com.au> had this to say:


    > Yes - I was agreeing that it's simply a form of checksum, and that the
    > checksum will be the same for many different passwords. But simply
    > re-running the cracker is not going to create a different result - it
    > will give you the same number, because it's simply starting at the
    > beginning (eg 00000000) and working forward. You need to force it to
    > find the _next_ result (if it has such a facility).
    >
    > You can work out approximately how many passwords will match by
    > calculating the possible number of passwords and the possible number
    > of checksums. If passwords can be 8 upper case letters or 0 to 9,
    > then there can be 36^8 passwords. If the checksum is 16 bits then
    > there can be 65536 checksums. That's an awful lot of passwords for
    > each checksum. --
    > Jeff Richards
    > MS MVP (Windows - Shell/User)

    And that's what lacks any logic to me. Why, if nothing else, would the
    checksum be the authorative value and not the original password? I've known
    for a long time that BIOS passwords could be cracked but never had to do so.
    I just pull the jumper or remove the battery and wait a while. Up until this
    post, which I find interesting, I had *assumed* (and we know what that makes
    me) that the password was kept in encrypted form and the exact password had
    to be entered in order to gain access not that any random sum that equaled
    the same values would work. 'Tis rather lax I'd say... Shoddy coding or just
    no other way?

    Galen
    --

    "My mind rebels at stagnation. Give me problems, give me work, give me
    the most abstruse cryptogram or the most intricate analysis, and I am
    in my own proper atmosphere. I can dispense then with artificial
    stimulants. But I abhor the dull routine of existence. I crave for
    mental exaltation." -- Sherlock Holmes
  12. Archived from groups: microsoft.public.win98.gen_discussion (More info?)

    Passwords are usually stored in an encrypted form, using a mode of
    encryption ('trapdoor') that cannot be decrypted. That way it's never
    possible to simply look at what's been stored (for instance, in BIOS memory)
    and discover the password.

    Whether or not there are multiple passwords for one encrypted value depends
    on the algorithm chosen, and can be guessed from the size of the encrypted
    value - if the encrypted value cannot encode as many distinct values as
    there are possible passwords, then there must be multiple passwords per
    encrypted value. If the encrypted value can encode more values than there
    are passwords then there might be only one encrypted value per password.
    Note that having a unique encrypted value per password is not necessarily
    more secure - algorithms that encrypt every distinct password to a unique
    value can be susceptible to cracking by encrypting a large number of
    passwords and working out the relationship between each password and its
    encrypted value - if multiple passwords map to one encrypted value then this
    approach is much harder. OTOH, if too many passwords encrypt to the same
    value, the possibility of success with a brute force attack (trying every
    possible password) is increased, as in this case.

    I suspect that the BIOS password process has been roughly matched to the
    difficulty of subverting the security by other means - there's a not a lot
    of point in a very complex encryption scheme when the alternative is to lift
    the lid and remove the battery.
    --
    Jeff Richards
    MS MVP (Windows - Shell/User)
    "Galen" <galennews@gmail.com> wrote in message
    news:ul26hsWFFHA.548@TK2MSFTNGP14.phx.gbl...
    > In news:eXecjSUFFHA.3908@TK2MSFTNGP12.phx.gbl,
    > Jeff Richards <JRichards@msn.com.au> had this to say:
    >
    > snip <
    > And that's what lacks any logic to me. Why, if nothing else, would the
    > checksum be the authorative value and not the original password? I've
    > known
    > for a long time that BIOS passwords could be cracked but never had to do
    > so.
    > I just pull the jumper or remove the battery and wait a while. Up until
    > this
    > post, which I find interesting, I had *assumed* (and we know what that
    > makes
    > me) that the password was kept in encrypted form and the exact password
    > had
    > to be entered in order to gain access not that any random sum that equaled
    > the same values would work. 'Tis rather lax I'd say... Shoddy coding or
    > just
    > no other way?
    >
    > Galen
  13. Archived from groups: microsoft.public.win98.gen_discussion (More info?)

    In news:O262DnXFFHA.3504@TK2MSFTNGP12.phx.gbl,
    Jeff Richards <JRichards@msn.com.au> had this to say:

    > I suspect that the BIOS password process has been roughly matched to
    > the difficulty of subverting the security by other means - there's a
    > not a lot of point in a very complex encryption scheme when the
    > alternative is to lift the lid and remove the battery.

    Which is why I'd never bothered using one and didn't realize that they were
    that easy to break or that their could be multiple values assigned to the
    hash. I find that a lot of batteries are difficult to remove so I look for
    the jumper closest to the battery first and try that. So much for security
    :)

    Galen
    --

    "My mind rebels at stagnation. Give me problems, give me work, give me
    the most abstruse cryptogram or the most intricate analysis, and I am
    in my own proper atmosphere. I can dispense then with artificial
    stimulants. But I abhor the dull routine of existence. I crave for
    mental exaltation." -- Sherlock Holmes
  14. Archived from groups: microsoft.public.win98.gen_discussion (More info?)

    "Galen" <galennews@gmail.com> wrote in message news:OX9wR%23RFFHA.936@TK2MSFTNGP12.phx.gbl...
    > In news:%23JL5dAKFFHA.3376@TK2MSFTNGP12.phx.gbl,
    > Bill Blanton <bblanton@REMOVEmagicnet.net> had this to say:
    >
    >> Using the above algorithm, there are a good number of strings that
    >> will produce same word values. All you have to do is take a bit out of
    >> one char, and place it in another in the correct bit[x] position to
    >> end up with the same sum.
    >>
    >> You'd still have to know where it is and how to work back through the
    >> algorithm. But it wouldn't be too hard to work through. The odds of
    >> getting the exact password string that the user entered (assuming more
    >> than 1 or 2 characters) would still be fairly high, though apparently
    >> not really necessary.
    >
    > *thinks* So (and this is entirely made up) for example a password value of
    > "mypass" could have the same value as 112211? Meaning that if I were to sit
    > there long enough and enter random numbers into the bios password prompt
    > that eventually (think the 100 monkeys and the 100 typewritters) the numbers
    > would work while the original password was made of alphabetic characters?


    Just as a simple example to show how it's possible mathematically,
    take the two character password "pa"

    Here's the original algorithm as was posted-

    > <snip>
    > Award BIOS treats its password as an ASCII string of maximum length 8,
    > consisting only of characters in the range ' '-'', which have values
    > 32-127. Each of those values is expanded to an unsigned word and
    > rolled two bits further left than the next one in the string, where
    > the last character is rolled zero bit positions. Then they are all
    > added together to produce one word, which is stored in CMOS (LSB in
    > register 0x1c, MSB in 0x1d).
    > /<snip>

    I assume "rolled" means rotated where the high bit is rotated into the
    low. This won't matter with a 2 character string since set bits won't
    ever make it to the high bit positions of the word, but it matters for
    longer ones.


    "p" = 0x70
    "a" = 0x61

    expand these to an unsigned word, per the algorithm

    0x0070
    0x0061

    the binary representation

    00000000 01110000
    00000000 01100001

    Rotate 2 and 0 bits to the left respectively

    00000001 11000000 (rotated left 2)
    00000000 01100001 (rotated left 0)

    The sum as held in the BIOS
    0x0221

    Looking at those two binary words, you can see how easy it would be to
    have two entirely different characters add up to the same sum. All you
    have to do is swap a bit between the two and then rotate them back to
    come up with a different set of characters.

    swap bit-5
    00000001 11100000
    00000000 01000001

    It's still the same sum

    rotate back-
    00000000 01111000 (rotated right 2)
    00000000 01000001 (rotated right 0)

    0x78 = "x"
    0x41 = "A"


    "pa" = "xA"


    Of course that's just a simple example, and I cheated because I knew
    what the original string was. The real math test would be to write the
    algorithm to go backwards from the sum. You have to account for the
    subtraction and "carry", the rotate, and the stripping of the high
    byte in the formula, so you don't end up with any "illegal characters,
    or lose bits in the high byte. This is probably harder to do than I
    originally thought, ;-) but still should be doable.

    I'd guess different BIOSs use different methods too.
  15. Archived from groups: microsoft.public.win98.gen_discussion (More info?)

    "Galen" <galennews@gmail.com> wrote in message news:%23$toWmhFFHA.3384@tk2msftngp13.phx.gbl...
    > In news:O262DnXFFHA.3504@TK2MSFTNGP12.phx.gbl,
    > Jeff Richards <JRichards@msn.com.au> had this to say:
    >
    >> I suspect that the BIOS password process has been roughly matched to
    >> the difficulty of subverting the security by other means - there's a
    >> not a lot of point in a very complex encryption scheme when the
    >> alternative is to lift the lid and remove the battery.
    >
    > Which is why I'd never bothered using one and didn't realize that they were
    > that easy to break or that their could be multiple values assigned to the
    > hash. I find that a lot of batteries are difficult to remove so I look for
    > the jumper closest to the battery first and try that.

    There's another method where you can corrupt the CMOS checksum, and
    the BIOS will revert to its default state and lose the password (as
    well as other non-default values). That can be risky and YMMV depending
    on the BIOS.

    > So much for security
    > :)

    I'd have to wonder what that dude is doing sitting at my desk in the
    first place ;-)
  16. Archived from groups: microsoft.public.win98.gen_discussion (More info?)

    In news:%233VlbIpFFHA.1836@tk2msftngp13.phx.gbl,
    Bill Blanton <bblanton@REMOVEmagicnet.net> had this to say:

    > I'd guess different BIOSs use different methods too.

    Sorry to snip up such a great post but I've been spending a large amount of
    time researching this and while I haven't any justification for wasting this
    much time I truly haven't anything better to do which, I suppose, is
    justification enough. Indeed the initial concern is, "What are you doing at
    my desk and what do you have on that floppy?" Or, "Why do you have the side
    panel off my computer? You do realize that the plastic tweezers from a
    hospital suture removal kit is the best tool for removing jumpers don't you?
    Now get your greasy fingers away from my motherboard."

    After reviewing a number of sites, many located in an area which I prefer to
    term the "dark side of the internet," I've found that most BIOS password
    cracking utilities just use assigned algorithms for decryption and are often
    limited to a specific brand. A few claim to use a brute force attack though
    I didn't see any word lists associated with the application and they seemed
    likely too small to include random key generation utilities. I suppose that
    they might have though. A smaller number used the method of corrupting the
    sum which caused the password to default to a null value (a strikingly silly
    idea when one could simply remove the jumper with little or no risk or the
    battery should a jumper not exist) and those SEEMED to be more generic from
    what I observed though I am certain that I've not looked at all of them. A
    number of the various applications included source code which I've taken a
    bit of time to review as well. Quite interesting really.

    Anyhow, after wasting all of this time and wondering why it was so simple to
    do (in regards to the ease of decrypting the password from the hash) all of
    this, I finally decided to apply logic. Perhaps it's so simple because,
    well, really... All they'd have to do is remove the battery or jumper.
    Password protecting your BIOS isn't going to keep anyone out of your PC if
    they have any idea what they are doing. The vendors know this, we know this,
    and I suspect that's why it's not very advanced or difficult to crack. I use
    that term difficult liberally as I don't think that I'd have an easy time
    writing an app to do this.

    Galen

    --

    "My mind rebels at stagnation. Give me problems, give me work, give me
    the most abstruse cryptogram or the most intricate analysis, and I am
    in my own proper atmosphere. I can dispense then with artificial
    stimulants. But I abhor the dull routine of existence. I crave for
    mental exaltation." -- Sherlock Holmes
  17. Archived from groups: microsoft.public.win98.gen_discussion (More info?)

    "Galen" <galennews@gmail.com> wrote in message news:uggqGgrFFHA.3972@TK2MSFTNGP15.phx.gbl...
    > In news:%233VlbIpFFHA.1836@tk2msftngp13.phx.gbl,
    > Bill Blanton <bblanton@REMOVEmagicnet.net> had this to say:
    >
    >> I'd guess different BIOSs use different methods too.
    >
    > Sorry to snip up such a great post but I've been spending a large amount of
    > time researching this and while I haven't any justification for wasting this
    > much time I truly haven't anything better to do which, I suppose, is
    > justification enough.

    What's time for, if not to waste ;-) I learned some things I didn't know
    anyway..

    > After reviewing a number of sites, many located in an area which I prefer to
    > term the "dark side of the internet," I've found that most BIOS password
    > cracking utilities just use assigned algorithms for decryption and are often
    > limited to a specific brand. A few claim to use a brute force attack though
    > I didn't see any word lists associated with the application and they seemed
    > likely too small to include random key generation utilities.

    Brute force can be implemented just by running the gamut of strings
    possible. AAA AAB AAC etc ... until you hit a match. Of course, in this
    case that's also dependent on other variables, such as knowing the
    checksum or value and knowing the algorithm to decode or decrypt it.

    > Anyhow, after wasting all of this time and wondering why it was so simple to
    > do (in regards to the ease of decrypting the password from the hash) all of
    > this, I finally decided to apply logic. Perhaps it's so simple because,
    > well, really... All they'd have to do is remove the battery or jumper.
    > Password protecting your BIOS isn't going to keep anyone out of your PC if
    > they have any idea what they are doing. The vendors know this, we know this,
    > and I suspect that's why it's not very advanced or difficult to crack.

    I'd say that's probably true. Also, CMOS memory (and to a lesser extent the
    BIOS real estate, needed to do the encode/decode) is very limited. Stronger
    encryption requires more resources.
  18. Archived from groups: microsoft.public.win98.gen_discussion (More info?)

    On Sat, 19 Feb 2005 14:20:04 -0500, "Galen" <galennews@gmail.com> wrote:

    (snip)

    >After reviewing a number of sites, many located in an area which I prefer to
    >term the "dark side of the internet," I've found that most BIOS password
    >cracking utilities just use assigned algorithms for decryption and are often
    >limited to a specific brand.
    (snip)
    >A smaller number used the method of corrupting the
    >sum which caused the password to default to a null value (a strikingly silly
    >idea when one could simply remove the jumper with little or no risk or the
    >battery should a jumper not exist)

    If the BIOS (CMOS RAM/RTC chip) is battery- backed, you may well have a very
    long wait before there is any change after removing every visible battery. The
    expression "don't go without a bath" is appropriate here. Also there aren't a
    lot of recent laptops with a CMOS defeat jumper.

    Those utilities (I use one in particular) are quite handy for laptops -
    presuming that it is ONLY a BIOS password and the machine will boot.

    Also, the corrupting of the CMOS checksum doesn't cause the password to default
    to a null value - it doesn't change the stored value at all. It causes the POST
    to initiate a "CMOS checksum error" process which invites/demands user
    intervention and bypasses the password step entirely.
  19. Archived from groups: microsoft.public.win98.gen_discussion (More info?)

    "budgie" <me@privacy.net> wrote in message news:s6rf11tpdat4kuk4bckqtiaitvl39kqrqb@4ax.com...
    > On Sat, 19 Feb 2005 14:20:04 -0500, "Galen" <galennews@gmail.com> wrote:
    >
    > (snip)
    >
    >>After reviewing a number of sites, many located in an area which I prefer to
    >>term the "dark side of the internet," I've found that most BIOS password
    >>cracking utilities just use assigned algorithms for decryption and are often
    >>limited to a specific brand.
    > (snip)
    >>A smaller number used the method of corrupting the
    >>sum which caused the password to default to a null value (a strikingly silly
    >>idea when one could simply remove the jumper with little or no risk or the
    >>battery should a jumper not exist)
    >
    > If the BIOS (CMOS RAM/RTC chip) is battery- backed, you may well have a very
    > long wait before there is any change after removing every visible battery. The
    > expression "don't go without a bath" is appropriate here. Also there aren't a
    > lot of recent laptops with a CMOS defeat jumper.
    >
    > Those utilities (I use one in particular) are quite handy for laptops -
    > presuming that it is ONLY a BIOS password and the machine will boot.
    >
    > Also, the corrupting of the CMOS checksum doesn't cause the password to default
    > to a null value - it doesn't change the stored value at all. It causes the POST
    > to initiate a "CMOS checksum error" process which invites/demands user
    > intervention and bypasses the password step entirely.

    It's been my experience the couple of times that I've done this (corrupting
    the checksum), that it does invalidate the need for a password. Whether it
    erases the stored value in the CMOS memory or not, it defaults back to not
    asking for a password, so the stored value is irrelevent.
  20. Archived from groups: microsoft.public.win98.gen_discussion (More info?)

    "Bill Blanton" <bblanton@REMOVEmagicnet.net> wrote in message news:uTwI$VvFFHA.3368@TK2MSFTNGP10.phx.gbl...
    >
    > "budgie" <me@privacy.net> wrote in message news:s6rf11tpdat4kuk4bckqtiaitvl39kqrqb@4ax.com...
    >> On Sat, 19 Feb 2005 14:20:04 -0500, "Galen" <galennews@gmail.com> wrote:
    >>
    >> (snip)

    >> Also, the corrupting of the CMOS checksum doesn't cause the password to default
    >> to a null value - it doesn't change the stored value at all. It causes the POST
    >> to initiate a "CMOS checksum error" process which invites/demands user
    >> intervention and bypasses the password step entirely.
    >
    > It's been my experience the couple of times that I've done this (corrupting
    > the checksum), that it does invalidate the need for a password. Whether it
    > erases the stored value in the CMOS memory or not, it defaults back to not
    > asking for a password, so the stored value is irrelevent.

    Rereading your post ...I think that may be what you already said.. ;-/
Ask a new question

Read More

BIOS Microsoft Checksum Windows