BIOS password question

[Chuck]

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"

 

[galen]

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

 

[HAGGIS]

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>

 

[Guest]

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".

 

[galen]

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

 

[Guest]

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.

 

[galen]

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

 

[Chuck]

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"

 

[Guest]

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"

 

[Chuck]

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"

 

[Guest]

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"

 

[galen]

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

 

[Guest]

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

 

[galen]

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

 

[Guest]

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.

 

[Guest]

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 ;-)

 

[galen]

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

 

[Guest]

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.

 

[budgie]

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.

 

[Guest]

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.

 

[Guest]

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.. ;-/