C Exploit programs--
How to Make them Run
_________________________________________________________
Guide to (mostly) Harmless Hacking
Vol. 5 Programmers' Series
No. 4: How to Program in C, part 2
_________________________________________________________
Now, on to some common problems with getting C programs to
compile and run. in the case of exploit programs, there often
are references to other programs on your target computer. For
example, in Leshka's sendmail exploit,
the sendmail program is assumed to exist in /usr/sbin/sendmail.
This works fine for a Linux computer. However, on the Sun
OS computer I like to use, sendmail is in /usr/lib/sendmail.
So you can see that an important first check on an exploit is
to make sure all the locations of files match those of the operating
system you are targeting. His exploit also assumes the command
to run the C compiler is "cc".
However, your victim computer may have the GNU C compiler,
and it may require that you give the command "gcc"
instead of "cc".
Another problem is that sometimes hackers purposely cripple
their exploit code in order to keep total idiots from running
them. For example, the syn flood exploit program written by Daemon9
and released in the fall, 1996 issue of Phrack had a crucial
line of code commented out.
*****************************************************
Newbie note: "Comments" are parts of a program meant
for humans to read, not for the compiler to work on. Comments
help people understand a program. Sometimes a part of a program
might be something that you don't always want to run, in which
case it is "commented out" by marking it as a comment
to make it so the compiler can't compile it.
*****************************************************
So if you see something that looks like code between a "/*"
and "*/" (which denote comments in C programs) try
removing these comment marks and then run the program. However,
a lot of code commented out may be simply debugging code the
programmer used to make sure it was running properly. You might
be able to use that debugging code to figure out what your problem
(bug) is.
Another reason why many people were unable to run that syn
flood program was that it had to be installed with root permissions.
As mentioned above when we were discussing the commands "setuid(0);
setgid(0", normally you only have the right to set root
permissions on a program when you are root.
A syn flood program needs root permission in order to manipulate
the creation of packets so as to send floods of them out to the
victim with only the syn flag set, never an ack flag.
Another of your problems may be the include files at the beginning
of a C program. For example, you might find something like this:
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in_systm.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <netinet/tcp.h>
#include <netinet/ip_icmp.h>
#include <netdb.h>
If you try to find the file sys/socket.h, you will see it
is not a list of ports, nor is it a table of active sockets.
It is merely a C header file. It contains system specific information
which is needed to write network programs. It varies slightly
among different variants of Unix.
There are many types of files that might need to be included
in a C program before it can run. You can get an idea of they
type of file by the extension (the character(s) that follow the
period).
.h = header file
.a = archive (library) file
.c = source file
.h = header file
.o = object module (compiled from a .c file)
.sa = shared library stubs linked to your program
What if your shell account doesn't have all the include files?
First, you have to find the missing library functions. Don't
email me if you don't know where they are! First try a search
within the computer you are using with commands such as whereis,
which, apropos, man -a and man -k. If that doesn't work, ask
tech support at your ISP. If you have a free shell account, it
probably doesn't offer free tech support. To do serious programming,
it helps to get a commercial shell account. Then tech support
can come to your aid.
If this doesn't work, stand on a street corner holding a sign
that reads "Will work for include files." Whatever
you do, DON'T EMAIL ME about this problem. I can't help you on
this!
OK, OK, I feel sorry for you. Meino Christian Cramer has a
solution for the problem of finding where library functions might
be. He has written a bash shell script to automatically find
them in Linux computers. (This script may not work in other shells
on other operating systems.) Save the code below in a file named
obcheck.sh and remember to make it executable.
#!/bin/sh
#
# scan libraries for a certain function
#
######################################################
if [ -z $1 ]
then
echos "usage: obcheck <function to search for>
exit
fi
for i in $( cat /etc/ld.so.conf )
do
for j in $( find "$i" -type f -name 'lib*.so.*' )
do
if nm -D "$j" | grep "$1" | egrep "^[0-9A-Fa-f]"
then
echo "$j"
fi
done
done
---------------------------------------------------------
How do you use this script? For example, if you are searching
for "printf" call the script by giving the command:
-> obcheck ' printf '
Reports Cramer, "This will display a couple of messages.
Because this only works on shared libraries, all other libraries
are printed with an error message. Why use ' printf ' instead
of simply printf? Cause there are more functions, all with a
"printf" inside their names. But you are only searching
for THE printf."
Now suppose you have found each and every include file your
C program needs
to run. The next trick is, you have to tell your compiler where
to look for them. You will use a shell command such as this:
cc -o myhardprogram myhardprogram.c -L/library1/lib -lmylibrary
Where "/mylibrary" is where you put those include
files that your compiler didn't automatically find in the standard
libraries of your computer. Be sure to have this command all
on one line without a return, or it won't work!
If this doesn't work, read Cramer's
C tutorial for more help.
More on C --->>
