What's New!

Chat with

How to Defend
Your Computer 

The Guides
to (mostly) 
Harmless Hacking

Happy Hacker 
Digests (old stuff) 

Hacker Links 


Meet the 
Happy Hacksters 

Help for 



It Sucks 
to Be Me!

How to Commit
Computer Crime (not)! 

What Is a 
Hacker, Anyhow? 

Have a 
Great Life! 

News from the 
Hacker War Front

Carolyn's most
popular book,
in 4th edition now!

For advanced
hacker studies,
read Carolyn's
Google Groups
Subscribe to Happy Hacker
Visit this group

Mar. 7, 1999
See the Happy Hacker web site at http://www.happyhacker.org
URL of the day: 
http://www.rasterman.com/ - Enlightenment: a cool window manager for X11

Editor's Comments
Nuggets of Info
Reader Questions
Reader Submissions
Buffer Overflows Explained
The BSDs
More UNIX Commands
Recompiling Your Kernel
Next Issue

      *** Editor's Comments

Wow...this issue is going to be more explanation than submission...which
means alot of work for yours truly. I'm going to try to point you to
existing explanations, summarize, then feel free to ask me to clarify in
future issues - I will do my best to answer all clarifications. On a side
note, I won't email anyone directly, so if you're expecting that sort of
response, sorry. All responses will be posted to the digest for the
benefit of all.

      *** URLs

SUN and SGI hardware

BSDI - makers of BSD/OS

Free/cheap shell accounts

UNIX System Administration classes (not free)

A pretty good description of shadowed passwords

Share and get Linux/*BSD CDs

      *** News

On February 22, 1999 AntiOnline unveiled its new sites. After receiving
some venture capital, John Vranesevich expanded his computer-security
site to span 6 sites, with their own offices and a full staff. It's
also received alot of opposition from the hacking underground with this
new site -- John, for example, being labelled as a sellout and such.
Check out our own Carolyn Meinel's article there, "Granny Hacker from
Heck" where she pokes fun at some of the people that go out of their way
to harass her.

Hewlett-Packard has decided to split into two new companies, one sticking
with computing and keeping the Hewlett-Packard name, and the other
becoming a "Testing and Measurements" company. Check


for more info.

      *** Nuggets of Info

1) It is possible to install multiple Linuxes on the same computer in
   different partitions. You can also have many OSs on one computer. I
   once had Debian Linux, Solaris, NT, and 98 installed all at once.

2) If you're trying to dual-boot your Win9x with Linux, it's generally not
   a good idea to remove the hard drive containing Windows, then install
   Linux on a separate one, then reinstall the hard drive. Your
   configuration will certainly be messed up. The chances that you're
   going to screw up your Win9x partition installing Linux is slim if
   you're being careful.

3) A username with UID 0 (zero) has superuser access.

4) Want to set up a dummy listener on a port? Try netcat.

      *** Reader Questions

redpoint <redpoint@gte.net> wrote:

Dear unixeditor,
 I was recently on koan and I typed in the kill -9 command to 
kill off other users.  I was about to type in someone's process number 
when my account was taken over.  I couldn't believe it!  Someone else 
was typing numbers for me.  I didn't touch anything!  I watched my 
process number come up and quickly erased it from the screen.  I decided 
to do an experiment.  I cleared the line and waited, nothing happened.  
I typed in kill and waited, nothing happened.  As soon as I typed kill 
-9 again, someone, or something, started to type my process number.  I 
finally just got tired of screwing around and left.  I was wondering if 
you could explain how this happened.  Was there someone watching my 
commands and taking over my account?  Or did someone write a program to 
keep from getting killed?  Please help.

ps  I know that it's rude to kick people off, but it was getting really 
crowded and really slow.  I usually don't resort to such drastic 
measures, but I, along with everyone else I'm sure, get sick of waiting.

[Ed- Heh. Sounds like somebody hijacked your connection or your tty.
Anybody care to elaborate? I'm pretty sure somebody was playing with 
you. They'd most likely have to be root to do this, so that'd be your
first suspect.]

      *** Reader Submissions

Alex Armstrong <dabugas@usa.net> wrote:

I have noticed that various people are starting to say pico is not good
and emacs and vi are the best. Pico is the worst editor I ever had the
misfortune to use and then I downloaded Midnight Commander which included
a had a symbolic link called "mcedit". Mcedit is nothing less than
Cooledit for the console. If you've never heard of Cooledit, then it's a
very easy editor for X. It's very good for programming (I found) and has
some nice features using a very easy and simple interface. Cooledit is
exactly the same thing, only for the console. If you're a newbie who find
pico too weak and vi/emacs too hard (at least for now), then get Midnight
Commander (which I haven't mentioned - is an excellent Norton Commander
like program for console)and mcedit. Keep up the good work, everyone!


bandix <bandix@id-base.com> wrote:

I have been following HappyHacker for quite a while and I am quite
intrigued by the unique spirit of this organization.  I must say I was
quite excited to see a *n?x publication added to the collection.  However
the first few issues of the UNIX Digest have really disappointed me.
HappyHacker is supposed to be a community of people working together to
help educate each other on computer security.  A community for everyone
from the newest of the newbies to the oldest of the kernel hackers.
Instead of observing this spirit I have seen a typical 'script kiddie'
response from most of you. You have jumped all over our unix editor, a
volunteer who is spending his time and effort working for YOU.  Give the
man a break.  Let me clarify what I mean by typical script kiddie    
response.  I have seen as many holy wars in the first few issues of this
digest as I have ever had a fancy to see. Let us not act like the 13 year
olds on SlashDot, you are supposed to be aspiring computer security
professionals, not holy crusaders.  Stop parading Richard Stallman's face
through Red Square and start acting your ages. The readers as well of the
editor of this digest will be much better served when I hear the end of
vi vs. emacs vs. pico and the end of linux vs. *BSD vs. Solaris.  At
least on IRC I can kickban people with this attitude.  I may not be able
to do that here but I urge those of you who have been flaming our editor 
to grow up.  There is no excuse for your pissing contest of unix

[Ed- Thanks bandix!]


BladerHater <Sweasel18@aol.com> wrote:

Robert Herrenan was talking about he was glad to see a linux box up and
everything.  Well I thought I would just fill him in on what I know about
this box.  I dont think he is giong to be happy.  Smurfette is set up as
a mail router and has no intentional holes in it.  As far as port
scanning goes its best to do that from koan cause knight.rt66.com is a
firewall and im not sure if its blocking your scans or hiding certain
ports, your just best off scanning from koan cause then you dont have to
worry about the firewall.  Bad news on port scanning it.  Well it had
three ports open 23,25 and a really high number, all these ports seemed
to be the same except 23 and 25 timed you out while the high numbered
port never did.  These ports just take in whatever your typeing but never
respond.  Well it seems recently they put a program on it that protects
it from port scans.  My guess is nmap would would get past this program
but I cant find out since nmap doesnt want to run on freeBSD. 23 and 25
are now closed but the high numbered port is open and another port. Could
be more ports open i cant scan it now :-(  i just found two.  Well that
was all bad news maybe someone can give us good news about this box.  
About exploiting remote holes, i would like to learn more about this
myself and I have talked to some people who are or might donate box's to
the wargames and I gave through out the idea of making some remote holes
and easy ones too and then have the easy ones drop you into some sort of
guest account so we don't have everyone in root.  Hopefully someone
running a box will pick up on that idea.  I too am not a fan of
scriptkiddies.  If I come in contact with an exploit program I like to
try and find out how it works, I read the source run it modify it etc.
Thats one thing I like about the wargames is they make there own holes so
these programs dont work yet there are programs from  rootshell and
similar places all over koan.  If you want to practice writing an
overflow the program with the hole that allows you to go from guest2 to
guest3 on koan is overflowable, i havent done it yet but I plan on trying.
The intentional hole for guest2 to guest3 is much easier, doesnt require
any programming but its being left overflowable.  There is supposedly a
file on koan that is overflowable and will give you root, good luck
finding it, I havent been able to and I dont know anyone who has.  I
think that is kinda long, feel free to cut, summarize, edit, it is 5:15am
here not the best time to be trying to write this.  Hope this was of some
help and not too much bad news.


[Ed- First, I'm pretty sure that nmap _will_ compile on FreeBSD. And what
you said about making custom holes to kick someone into a guest account is
what's going on at koan, as far as I can tell. They have 4 levels of guest
now...guest, guest2, guest3, and guest4. Thanks for the insight!]


Sumit Dhar <dhar6ul@ccs.iitb.ernet.in> wrote:

 This is in reply to the guy who had problems with his .rhosts
files. My first suggestion would be to change the mode of his .rhosts
file to 700 and then try rlogin -l username hostname. Though I would think
it would not be a really very good idea. 



Freak A Zoid <phreakazoid69@juno.com> wrote:

>David Webber <dwebber@ie-e.com> wrote:
>I have a Red Hat 4.2 system that I do not know the root password to. The

If you want to just get the job done, think simplistic! There are times
for doing a job "right", and there are times when you just need to "get
it done", then figure out the right way later.

How about this for simple. Boot off a boot/rescue disk, mount the root
partition, rename /etc/passwd to /etc/passwd.orig then cat or echo a new

echo 'root:0:0:::/:' > /etc/passwd

WARNING: Since I don't memorize password files and don't have my UNIX box
handy, I can't guarantee that I got the right number of colons in the
above command. Basically you just want a proper root entry, without a
password.  You don't need a name in the GECOS (name) field, you don't need
a shell (it will default to /bin/sh), you just need root,  UID, GID and
Home Directory. 

Then you can umount the root partition, reboot off the hard disk, login
(no password), and mv the /etc/passwd.orig back over /etc/passwd, the run
'passwd root' and set the password to whatever you want.

-- Freak A. Zoid -- 


Talfa <hahjortland@ah.telia.no> wrote:

Dear hacker friends,

I just want to make all of you aware of this:

b = bit
B = Byte (USUALLY 8 bits, but could be something else)
(Octet = 8 bits)

(m = milli (1/1000))
k = kilo (            1'000 or 1024^1 =             1'024)
M = Mega (        1'000'000 or 1024^2 =         1'048'576)
G = Giga (    1'000'000'000 or 1024^3 =     1'073'741'824)
T = Tera (1'000'000'000'000 or 1024^4 = 1'099'511'627'776)

Quoted from FOLDOC: "Note that the formal SI metric prefix for 1000 is
lower case "k"; some, including this dictionary, use this strictly,
reserving "K" for multiplication by 1024 (KB is thus "kilobytes")."

This means for instance:
mb = millibit (what on earth would that be?)
Mb = Megabit
MB = MegaByte

For files etc.:
kB or KB, MB, GB, TB = 1024^x Bytes

When it comes to kbps, Mbps, Gbps, Tbps... , I think both 1000^x and
1024^x bits per second are used.

Some (all, maybe?) harddrive-manufacturers use the abbreviations
(incorrectly, I'd say) in this way:
kB, MB, GB, TB = 1000^x Bytes

Correct me if I'm wrong, but I think this is the right use of the

It really annoys me when I read about for instance harddrives of 2000 mb.
That would be a two bit drive! Please use correct abbreviations, hackers,
you are the ones that should really know this!

For reference, see:


      *** Buffer Overflows Explained

Buffer overflows are a (nowadays) common way to exploit bugs in software.
Typically this software is created in C or C++, due to the way that these
languages structure their memory allocation. Basically, a fixed-size
array has data sequentially written past its end until this data is
written to important data structures that determine which instruction the
computer will execute next. By cleverly constructing the data that
overwrites the buffer, an attacker can choose the code that the computer
executes, instead of the code the program was intending to run. Well, this
isn't terribly useful in itself. So I write a homework assignment with a
buffer overflow vulnerability. Then I exploit that vulnerability...but it
won't let me do anything more than I could normally. That's because every
running program runs AS a particular user. Programs can access whatever
their user's privileges allow them to. Now the first thing you're thinking
is "hmm..I wonder what programs run as root?" Well, you can see that on
your local machine pretty easily by typing 

ps aux | grep root

This lists all of the current processes, then only prints the lines that
have the word 'root' in them. This will give you a list of the programs
running as root. Ok, that's fine and dandy for a computer that you have
shell access for, but what about remote computers? There's no simple
mechanism for someone to anonymously ask a computer what processes are
running. It turns out, however, that in order to listen on any network
ports lower than 1024, a process needs to run as root. These are called
'privileged ports'. So the program that handles incoming ftp requests
(the FTP daemon) needs to run as root, because it uses port 21. If you
were to be evil and try to overflow a buffer in this daemon, you may very
well be able to execute commands as the superuser. Now, you're wondering
why nothing happens when you enter the character 'a' 7000 times at the
username prompt in your favorite FTP server. Well, most buffers are
checked for length before they're written, which is good coding practice.
Some aren't checked, and this is where the opportunity for exploit
begins. Remember, exploiting a buffer overflow on a computer that you
don't have explicit permission to do so is illegal, and the standard "You
can go to jail" warning applies. Without looking at the source code to a
program, it somewhat difficult to determine where a buffer overflow
exists. Even when you have the source code, small variations in the
system may prevent you from exploiting it properly. Now, you may ask,
"How can I tell if there's a buffer overflow in this source code that
I've been staring at for 3 hours?"  It's going to be somewhat hard if you
don't know any C or C++. In the next issue, I'll provide some source code
that has some obvious buffer overflows, and how the programmer could have
prevented it. So crack out some sendmail source code and find those
overflows in the meantime! ;)

      *** The BSDs

A good page that describes the differences between the *BSDs is at

I will provide a brief synopsis here:

Each BSD variant has a 'theme', I guess you could call it. They all have
their strengths and weaknesses, like anything else in the OS world. All of
them include XFree86, just like most Linux distributions, and have plenty
of free software available. The first three BSDs below are free for
download, or you can buy a CD very cheaply. BSD/OS is commercial software,
and is priced accordingly.

An offshoot of NetBSD whose primary emphasis is security. It supports
nearly the same number of machines that NetBSD does.

NetBSD's founding principle is to support as many different types of
hardware as possible. Most any hardware you can get your hands on can have
NetBSD installed upon it.

Ease of installation is the focus of this variant, and consequently it is
the most widely used variant. It is only available on Intel and Alpha

This is a commercial product of BSDI that only runs on Intel machines and
is thus commercially supported by BSDI

[Ed- As soon as I get another computer to play with, I plan on installing
OpenBSD on it. Two thumbs up here. The article goes into MUCH more detail 
than I did. I encourage you to read it.]

      *** More UNIX Commands

top - Display top CPU processes & realtime info

head - Output the first part of files

wc - Print the number of bytes, words and lines in files

sleep - Delay for a specified amount of time

df - Summarize free disk space

host - Query nameserver about domain names and zones

nice - Run a program with modified scheduling priority

uname - Print system information

      *** Recompiling your kernel

Not a terribly difficult task, recompiling your kernel is important for
many reasons, most of which involve tailoring Linux to your specific
tastes or configuration. The first thing you need to do is get a copy of
the kernel's source code. This is generally on one of the CDs you
received your copy of Linux on. (ooh..bad grammar!) You generally want
to stick with the version of the Linux kernel you're currently using if
you're just playing, until you know the possible consequences. Kernel
source code can be reliably (if not slowly) downloaded from 
ftp.kernel.org in the appropriate directory, if you don't want to get it
from your particular distribution's site. Once that is done, you need to
decompress and untar the files into /usr/src/linux -- I know Debian at
least puts it all there for you when installing the kernel source
package. I would assume Redhat does the same with its RPMs. Ok, now that
you have the source installed, it's time to do the real stuff. PLEASE
PLEASE PLEASE don't use this introduction as an absolute guide to kernel
recompiling. DO read the file /usr/src/linux/README -- it is very
important that you do. Looking over some of the Linux HOWTOs wouldn't be
a bad idea either. Make sure you're logged in as root, then:

cd /usr/src/linux
make mrproper
make config

The last command, 'make config' begins the setup of what will and won't be
in the kernel when you get around to compiling it. Choosing a whole bunch
of extras that you'll probably never use will make your kernel bigger and
probably slower unless it explicitly says so in the description of the
item. You can also replace 'make config' with 'make menuconfig' for a
text-based menu system with lists and dialog boxes and such, or also
'make xconfig' for a X-based display.

[RTC(Random Topic Change)- The README in the source for Linux 2.2.1 refers
to X as 'X windows'. Hmm. At least I'm not _completely_ insane.]

Choose the appropriate drivers for your configuration, and the add-ons
that you plan on using. Don't worry about configuring it wrong...you can
go through this process as many times as you like. In a future issue, I
may go through step-by-step what each of the choices will do for you.
(Assuming there's enough demand for me to do so.)

Once you've configured your kernel to just how you like it, enter the
following command:

make dep

This sets up the dependencies correctly. Now you are ready to actually
compile the kernel. Pick one of the following, depending on what you

Create a compressed kernel image:
make zImage

Create a boot disk (insert a disk in your A: drive):
make zdisk

Create a compressed kernel image and use lilo:
make zlilo

If the kernel is too large for zImage:
make bzImage

If you've made any choices during 'make config' where you set up any parts
of the kernel as modules, you'll need to do the following also:

make modules
make modules_install

It might not be a bad idea to back up your old kernel (generally /vmlinuz
or /zImage directory) and your modules directory in case something messes
up. Don't get frustrated if you end up reinstalling Linux or having to
recompile the kernel if things go wrong. It's happened to me and is
probably the best way to learn. To use the new kernel, make sure you have
a backup copy of your old one, and copy the new kernel
(/usr/src/linux/arch/i386/boot/zImage usually) over the old one. Then you
have to rerun lilo, if you use it. Now shutdown, reboot, and enjoy your
new kernel...hopefully. For problems, check the README file with the
source. I will not respond to any questions about specific kernel
compilation problems. There are much better resources than me out there
for troubleshooting this. Hopefully this is enough to get you all started
down the path of the kernel hacker. :)

      *** Next Issue

More on Buffer Overflows
You mean there's MORE UNIX commands?



For Windows questions, email keydet89@yahoo.com or editor@cmeinel.com
For Unix questions, contact unixeditor@cmeinel.com.
For Macs, email Strider <s.corinth@iname.com> 

Happy Hacker is a 501 (c) (3) tax deductible organization 
in the United States operating under Shepherd's Fold Ministries. Yes! 
This is all a plot to save your immortal souls!

 © 2013 Happy Hacker All rights reserved.