mirror of
https://github.com/opsxcq/mirror-textfiles.com.git
synced 2025-08-29 00:39:50 +02:00
377 lines
17 KiB
Plaintext
377 lines
17 KiB
Plaintext
.- XHU Pack #1 -.
|
||
|
||
. Introduction
|
||
. Description of Programs
|
||
. Closing
|
||
|
||
.- Introduction -.
|
||
|
||
XHU stands for Xenocide's Hacking Utilities written by me, Xenocide.
|
||
They mainly deal with hacking, security, and cryptography. You may use
|
||
the programs anyway you like, but I would like to hear your comments.
|
||
You can reach me on Static Line (806.747.0802) or by Internet at
|
||
dan.keisling@windmill.com or at xenocide@big12.metrobbs.com
|
||
|
||
- Xenocide
|
||
|
||
.- Description of Programs -.
|
||
|
||
The archive has these files packaged in them:
|
||
|
||
. brute
|
||
. dzip
|
||
. fakelog
|
||
. isprime
|
||
. netware
|
||
. passwd
|
||
. permute
|
||
. primes
|
||
. winsscrk
|
||
|
||
If you are missing any of these files, please contact me so that I can
|
||
send you them.
|
||
|
||
brute:
|
||
|
||
Brute is a program to show the user why a brute-force attack is a bad
|
||
idea in gaining a key. If you do not understand what a brute-force
|
||
attack is, read the below explanation:
|
||
|
||
For this explanation, I will be using the example of the PKZIP
|
||
password, since everyone is familiar with the program. Generally,
|
||
there are three types of attacks used to gain a password (key) :
|
||
|
||
. Cryptanalysis - mathematical attack used to calculate the key.
|
||
Usually the fastest and best option; although usually the most
|
||
difficult.
|
||
|
||
. Dictionary Attack (see dzip) - using a set of words to guess the key
|
||
(usually a password). Usually very slow, but easy to create.
|
||
|
||
. Brute-force Attack - trying every possible combination of a key
|
||
until the key fits. Usually the slowest, but the only way to solve the
|
||
equation.
|
||
|
||
In simple terms, suppose K=key and our equation we have to solve is
|
||
|
||
K=2*10 (two times five = ?)
|
||
|
||
Note that this is an extremely bad example. This is just to give you a
|
||
basic example of finding a key. Encryption is much more stronger than
|
||
this.
|
||
|
||
We could probably rule out the attack of a dictionary since we aren't
|
||
dealing with letters (see dzip). From a cryptanalysis stand point, we
|
||
would compute 2*5 to find the key. Although encryption usually has
|
||
another variable stopping us from simple computing the left of the
|
||
equal sign, this example will suffice. If you use brute-force, we
|
||
would try every possible combination of K. Since brute-force usually
|
||
starts at the lowest possible value and goes up, we would start at
|
||
K=0. Since 0=2*5 isn't true, we would try 1. Then 2, 3, 4, etc until
|
||
we ended up at 10. Since 10 equal 2 times 5, the program would halt,
|
||
giving us the solution to K.
|
||
|
||
So far, we have only been working with numbers. Now we will be using
|
||
letters, in order to conform to a PKZIP password. So, if our PKZIP
|
||
password is "XHU", how would be go about finding that using brute
|
||
force? Since brute force usually begins at the lowest possible value
|
||
and works its way up, we would begin at the letter 'a.' For now, we
|
||
will say that P is the PKZIP password (in this case, XHU) and P' is
|
||
the password being tried. So when we find that
|
||
|
||
P'=P
|
||
|
||
we have solved the password. Our first try comes out false, since
|
||
a=xhu is false. We would then try the letter 'b' and then 'c' and all
|
||
the way to 'z'. Since none of these work, what now? We have to "loop"
|
||
around to the characters "aa". Since aa=xhu is false, we would then
|
||
try "ab" then "ac" all the way to "az". Once this is reached, we have
|
||
to "loop" around to "ba." We will go all the way to "bz" then "ca" and
|
||
to "cz". All in all, we will finish the 2 character length with "zz".
|
||
We will then loop around to "aaa" and try that. Then we will go to
|
||
"aab" and so forth. Once "aaz" is reached, we loop to "aba" and try
|
||
"abb" then "abc" until we get to "abz" which loops around to "aca".
|
||
After we reach "azz" we loop around to "baa". We only get to a fourth
|
||
character string right after "zzz" is reached. (seems like a long
|
||
time).
|
||
|
||
In dealing with the three character string, we will reach the
|
||
combination "xhu" sometime in the middle giving us:
|
||
|
||
xhu=xhu
|
||
|
||
in which case is true, halting the program and returning P'. If you
|
||
understand C, then we can think of:
|
||
|
||
for (p'=a; p'<zzzz; p'++)
|
||
{
|
||
if (p'=p)
|
||
{ printf("We found the password");
|
||
abort();
|
||
}
|
||
else {}
|
||
}
|
||
|
||
Remember, though, that a PC is extremely fast at finding this
|
||
password. It would generally take a matter of a few seconds to find
|
||
the password "xhu." If you think you now can crack any PKZIPPED
|
||
password, think about these points:
|
||
|
||
. Passwords are generally more than 5 characters in length
|
||
. Passwords in PKZIP are case-sensitive ('a' and 'A' are
|
||
totally different passwords) So far we have been only using lower
|
||
case letters
|
||
. Secure passwords contain numbers, punctuation keys, high ASCII,
|
||
and spaces within them.
|
||
|
||
All of these factors contribute into increasing the time in finding
|
||
the password immensely. First, run brute with 5 characters as the
|
||
password. If you think it didn't take that long to show them all,
|
||
remember that it is just displaying them to the screen. When trying to
|
||
find the password, it uses this sequence:
|
||
|
||
a) Compute password
|
||
b) Try computed password with equation
|
||
c) Return results of try
|
||
d) If false, goto a; if true, goto e
|
||
e) Exit with success
|
||
|
||
More or less. This can more than triple the time to find it all.
|
||
Granted, finding the password "xhu" isn't long at all, but take into
|
||
the factors listed above. For passwords with uppercase, we now have to
|
||
try "aaA" and "gHA." Basically, every combination of upper and
|
||
lowercase letters in the string. Since we are introducing 26 new
|
||
characters (A through Z) we also have to introduce all punctuation
|
||
keys (keys: ~`!@#$%^&*()_+|\=-}]{[:;"'?/>.<,), spaces (just one
|
||
character - but it severely increases the time), numbers (0 through 9)
|
||
and all high ASCII characters (161 characters) all greatly increase
|
||
the time. Most security programs heavily encourage passwords that are
|
||
more than 10 characters in length with spaces and alternative case.
|
||
So, you can say that in a length of 10 characters, you will have the
|
||
try of:
|
||
|
||
kFi&; :l~<7E>
|
||
|
||
This won't usually be a password, but brute force has to check every
|
||
possible solution to the key.
|
||
|
||
If you are using a program that uses brute-force, it is always wise to
|
||
have the option of specifying what characters to use. Suppose you know
|
||
that the password is only in lower case letters. Why would we waste
|
||
all the other time to factor in upper case, spaces, numbers, and high
|
||
ASCII? A brute-force program should have the option to specify only
|
||
using lower case letters, or by only specifying numbers and upper case
|
||
letters.
|
||
|
||
If you STILL don't really know what a brute-force attack is, you
|
||
should follow up to the newsgroup sci.crypt or by contacting me.
|
||
|
||
dzip:
|
||
|
||
Dzip stands for Dictionary Zip which cracks PKZIPPED passwords. A
|
||
dictionary file (also called a wordlist) is simply a text file that
|
||
has one word per line. The program checks that word against the
|
||
password, and if it is false, it tries the next one. The dictionary
|
||
file that dzip looks for is called ZIP_DICT.TXT in the current
|
||
directory. Here is an example of the program:
|
||
|
||
Suppose our ZIP_DICT.TXT file looked like this:
|
||
|
||
oranges
|
||
bananas
|
||
apples
|
||
zowie
|
||
|
||
And the ZIP file with the password is called CRACKME.ZIP. We will
|
||
assign the password "zowie" to CRACKME.ZIP. Now, dzip will more or
|
||
less try the word "oranges" to the CRACKME.ZIP file. If PKZIP tells us
|
||
that "that is not the right password" dzip will then try "bananas".
|
||
Since "bananas" does not work, we will try "apples." It is not until
|
||
we try "zowie" that PKZIP says the password is correct. The program
|
||
now halts, giving us the password to CRACKME.ZIP.
|
||
|
||
So how do you make a ZIP_DICT.TXT file? You certainly do not make up
|
||
words yourself. Static Line has some available for download or you can
|
||
ftp them from sable.ox.ac.uk in the pub/wordlists directory. All of
|
||
these wordlists are setup with one word per line and usually English
|
||
only (although there are different languages there). As you might
|
||
notice, using a dictionary attack has it's limitations. What if the
|
||
password was "sdf(unSdf"? Since most wordlists are usually only whole
|
||
words, this limits us to only a brute-force attack (see brute). If you
|
||
do not plan on making your own dictionary files, only use a dictionary
|
||
attack if the password is a whole word. Also remember that "Apples"
|
||
and "apples" are two separate passwords. Most dictionary files are in
|
||
lower case.
|
||
|
||
One thing about dzip is that it is very fast. I ran it through a one
|
||
meg dictionary file (that's a lot of words; it took over five minutes
|
||
just to type it to the screen) and it returned the password in 47
|
||
seconds. As with a brute-force attack, there is no way of knowing how
|
||
long it will take to find the key. In brute-force, it happens only
|
||
when the correct key is found. Since a dictionary attack starts at the
|
||
top and goes down to the bottom of the file, the time limit is only
|
||
how long it takes to get to the word in the file. If the password was
|
||
somewhere in the middle, it will be quicker than finding the password
|
||
if it was located at the bottom of the file.
|
||
|
||
The password I used for the ZIP file was at the end of the one meg
|
||
ZIP_DICT.TXT file. This theoretically means that it takes about 1
|
||
minute to try a meg of words. However, with the abundance of words in
|
||
the English language, a one meg dictionary is pretty small. A common
|
||
size is around 10 megs or more.
|
||
|
||
If you do not know how to solve a password using cryptanalysis, it's
|
||
always better to at least try a dictionary attack before a
|
||
brute-force. Since it only (theoretically) takes 10 minutes for a 10
|
||
meg dictionary, you might get lucky and find the password - although
|
||
very unlikely. I could simple make my password 10 times more secure
|
||
against a dictionary attack by using these passwords:
|
||
|
||
"apples1"
|
||
"Apples"
|
||
"applesoranges"
|
||
"apples "
|
||
|
||
Remember that the space in the last example does mean that it is
|
||
different from just "apples" with no space. A great more detail can be
|
||
covered using a dictionary attack, but they are pretty simple to
|
||
reason out. Using dzip against different passwords you made up and
|
||
from the dictionary files you downloaded. One good example is to think
|
||
of an English whole word and use that for the ZIP password (using all
|
||
lower case letters). Then run dzip against a 10 meg dictionary and see
|
||
what happens.
|
||
|
||
The only specifications for dzip is:
|
||
|
||
ZIP_DICT.TXT must be in the current directory
|
||
The ZIP to be cracked must be in the current directory
|
||
The ZIP file must have at least 3 files encrypted with the same
|
||
password
|
||
|
||
Although there has not been a real cryptanalysis attack on PKZIP (the
|
||
only one being is that you must know the plain-text of the file to be
|
||
cracked), there will be a day when a program will return the password
|
||
in a matter of seconds. Until now, we are stuck with using brute-force
|
||
and a dictionary attack.
|
||
|
||
fakelog:
|
||
|
||
Fakelog is a login trojan that is designed to capture user names and
|
||
passwords on machines that use a "login" program. This is a demo copy
|
||
simply because all logins are different on every machine. Fakelog will
|
||
simulate the real login on your machine and ask for the user name and
|
||
password. Once a user has entered these items, they will be written to
|
||
a file and an error message will follow, then transferring control to
|
||
real login for the user to enter his info again.
|
||
|
||
The file that the passwords are written to is called PASSWD (you can
|
||
change it if you wish to something less obvious) for you to view
|
||
later. If I was to enter "Xenocide" as my user name and "xhu" as my
|
||
password, the PASSWD file would look like:
|
||
|
||
. Xenocide/xhu
|
||
|
||
Each time a user logs in, it will be added to the end of the file. If
|
||
it cannot find PASSWD in the current directory, Fakelog will create
|
||
it.
|
||
|
||
Here is an example of Fakelog's run time:
|
||
|
||
. Novell NetWare Login
|
||
|
||
. Login: Xenocide
|
||
. Password: XHU
|
||
|
||
. Wrong password entered.
|
||
|
||
The PASSWD file would then look like:
|
||
|
||
. Xenocide/XHU
|
||
|
||
The only problems with Fakelog is that if a user logs in many times,
|
||
he will notice that he somehow mistypes his password the first time.
|
||
|
||
In order for Fakelog to correctly work and fool a user, it must be
|
||
made to look exactly like the real logon. Because I don't know what
|
||
your logon looks like, you must contact me so I can customize it for
|
||
you. You must give me these details:
|
||
|
||
. Welcome Screens (Any text shown before the login prompt)
|
||
. The login prompt (ie: Login: or login: or username: etc)
|
||
. The password prompt (ie: password: or Password: or pass> etc)
|
||
. The error message (That you may get if you mistype your password)
|
||
|
||
isprime:
|
||
|
||
Isprime will tell you if a number you specified is prime. If it is
|
||
false, it will return the reason why. For example, if you entered 10
|
||
as the number, it would return false with the reason that 2*5=10. Due
|
||
to the limits of a personal computer, large numbers aren't handled
|
||
very well.
|
||
|
||
netware:
|
||
|
||
Netware will encrypt a password using Novell NetWare's Password
|
||
Encryption. It uses a simple hashing of the password into a 32 byte
|
||
string and does some mixing and compression to it. Passwords can be up
|
||
to 128 bytes and the hashing can be up to 128 bits. For example, if
|
||
you enter XHU for the password, it will return
|
||
|
||
0E B2 B6 ED F3 8E A4 D9 B2 FF F8 23 07 8E B9 FD
|
||
|
||
passwd:
|
||
|
||
Passwd will let you make a UNIX-like passwd entry commonly found in
|
||
/etc/passwd. It contains the same info (username, home directory, user
|
||
number, etc) and prints it to the file called PASSWD in the current
|
||
directory. This can be used for security programs that can check a
|
||
users password in a specific file. One note is that passwd does not
|
||
modify the strings in any way, such that at the Encryption Password:
|
||
prompt, you must enter the encrypted password. No encryption has been
|
||
implemented yet, although I hope for it to actually encrypt it with
|
||
crypt(3) someday.
|
||
|
||
permute:
|
||
|
||
Permute will display all the permutations of a string. If the string
|
||
is 'ab' it will return:
|
||
|
||
ab ba
|
||
|
||
primes:
|
||
|
||
Primes will calculate all the primes from 2 to 3067. It ends here
|
||
because of the limitations of a personal computer.
|
||
|
||
winsscrk:
|
||
|
||
Winsscrk will decrypt the Windows v3.11 Screen Saver Password normally
|
||
stored in control.ini. It does not specifically look for control.ini -
|
||
I have given you the choice of the file name. The only requirements is
|
||
that the encryption password must be after a Password= prompt. (This
|
||
is what control.ini looks like anyway). It has around a 99% success
|
||
rate, because certain punctuation keys confuse the encryption. I have
|
||
not tested Win '95's encryption (if it is different), but expect a Win
|
||
'95 edition in the next pack.
|
||
|
||
.- Closing -.
|
||
|
||
Please note that these programs are just simple ones to give me a
|
||
"test" for my knowledge. Although they may seem "useless" to you, they
|
||
greatly helped me in learning how to program, and in some cases,
|
||
information on basic (very basic) cryptography. Since these 9 programs
|
||
took me a while to make and get all the bugs out of, I cannot say how
|
||
long, if ever, an XHU Pack #2 will come out. I might also extend the
|
||
releases from other people who would like to distribute these kinds of
|
||
programs. If you would, contact me and we can arrange for it to be in
|
||
a pack. My only thoughts on new programs are duplicated past programs
|
||
(such as dzip), which is still quite a challenge, and to improve on
|
||
them as much as possible. If you also would like to see a program
|
||
made, please contact me so we can figure out how and we can release it
|
||
into a pack some day.
|
||
|
||
My only thanks are to Breed_X, who helped me with the Fakelog program.
|
||
|
||
- Xenocide
|
||
|