> Guide to (mostly) Harmless Hacking
> Vol. 5 Programmers' Series
> No. 1: Shell Programming

> 	First, let's walk though the Pico way to create a simple script.
> 
> 1) Open an editor program. We'll use the easiest one: Pico. At the prompt in
> your shell account, simply type in "pico hackphile." ("Hackfile" will be the
> name of the script you will create. If you don't like that name, open Pico
> with the name you like, for example "pico myfilename.")


You should mention that very few unix vendors put PICO on a default
install. Linux and FreeBSD do, but Sun, HPUX, AIX, and other commercial
unix variants do not.

> 2) Write in some Unix commands. Here are some fun ones:
> echo I am a programmer and one heck of a hacker!
> echo Today I am going to
> echo $1 $2 $3 $4 $5 $6 $7 $8 $9
> 
> 5) Now type in: "hackphile forge email from Santa Claus." Press "enter" and
> you will see on your screen: "I am a programmer and one heck of a hacker!
> Today I am going to forge email from Santa Claus."


No, it doesn't. On a SunOS box with BASH, it outputs a little differently.

I am a programmer and one heck of a hacker!
Today I am going to
forge email from Santa Claus.

(Notice the line break? If you do a little creative playing, I am sure you
can get it to output on one line though.)

> 	Then hold down the control key while hitting the letter "d." This will
> automatically end the "cat" command while saving the commands "ls -alK|more"
> and "w|more" in the file "list." Then make it executable with the command:
> "chmod 700 list." (If chmod 700 doesn't work on your system, try the
> alternative ways to make it executable in 4) above.)


If chmod 700 doesn't work on your system, fix chmod. Octel notation is
much more efficient.

> before displaying the next screen.
> What does "lrwxrwxrwx  1 cpm             9 Oct 27 15:35 .bash_history ->
> /dev/null" mean? "l" means it is a linked file. The first set of rwx's mean
> I (the owner of the account) may read, write, and execute this file. The
> second rwx means my group may also read, write and execute. The last set
> means anyone in the world may read, write and execute this file. But since
> it's empty, and will always stay empty, too bad, kode kiddies.


Take your own advice and 'man ln' and read about ln's behaviour. You
should also mention that on several unix boxes, a symbolic link is not
owned by you if you link to a file owned by another user.

On a Sun 4.1.4 box, here is the entry for the link:
lrwxrwxrwx  1 root            9 Oct  1 19:42 .rhosts -> /dev/null

And lets look at the file we are linking to:
crw-rw-rw-  1 root       3,   2 Jan  5 23:22 /dev/null

Notice the file ownership?

Now, lets look at another example:

lrwxrwxrwx  1 jericho         5 Jan  5 23:59 link1 -> test1
-rw-------  1 jericho         0 Jan  5 23:58 test1

What happens when we "echo hi >> link1" and then "cat test1"?

-rw-------  1 jericho         3 Jan  6 00:01 test1

Notice the file size? Jumped from 0 to 3.. because test1 has the word 'hi'
in it. Not exactly as you describe above.

> 	Here's how you can make your bash history disappear. Simply give the
> command "ln -s /dev/null ~/.bash_history."


And that won't do anything for your bash history. Notice the extra "." at
the end of your example? Lets do some more shell fun:

# ln -s /dev/null .test2
# ln -s /dev/null .test2.
# ls 
[...]
lrwxrwxrwx  1 jericho         9 Jan  6 00:03 .test2 -> /dev/null
lrwxrwxrwx  1 jericho         9 Jan  6 00:03 .test2. -> /dev/null
[...]

So your example above will NOT do anything to your real bash history.
UNLESS you define your bash history to be something other than the
default.

> supposed bash history file of mine, the stuff you type in during a "talk"
> session does not appear in the .bash_history file. The guy who faked it
> didn't know this! Either that, or he did know, and put that in to trick the


Or it was redirected into the file. Your bash history is a plain text
file, and can be overwritten, appended to, etc.

> The guys who got caught by this trick tried to get out of their embarrassing
> spot by claiming that a buffer overflow could make the contents of a talk


At no point did anyone claim a buffer overflow was responsible. Several
people mentioned that something could have been stored in a buffer (like
the clipboard of your windows box), and then pasted into that file very
easily.

> 	Another example of haxor Unix cluelessness was a fellow who broke into my
> shell account and planted a Trojan named "ls." His idea was that next time I
> looked at my files using the Unix ls command, his ls would execute instead
> and trash my account. But he forgot to give the command "chmod 700 ls." So
> it never ran, poor baby.


Insulting people that are able to hack into your accounts (and thus have
more knowledge of security than you or your admins), while making such
blatant mistakes above.. 

> 	First, when you name your script, put a period in front of the name. For
> example, call it ".secretscript". What that period does is make it a hidden
> file. Some kode kiddies don't know how to look for hidden files with the
> command "ls -a." 


According to some, you don't even have an alias to do that upon login. So
watch who you call kode kiddie. Most unix users I know set aliases in
their .login or .profile like the following:

alias ls="ls -alF"

The leading period does not make the file hidden at all. If you close your
left eye, does that mean the desk to your left is hidden? No, it means you
simply aren't looking at it.

> 	Remember to save this script by holding down the control key while hitting
> the letter "d". Now try the command: ".lookeehere!" You should get back
> something that looks like:
> bash: ./.lookeehere!: Permission denied
> That's what will stump the average kode kiddie, presuming he can even find
> that script in the first place.


If your umask is 700 as you mention above, it should run just fine. If you
set the umask so it isn't executable by default, then the above would be
expected.

> 	If neither the whereis or locate commands find it for you, if you are a
> newbie, you have two choices. Either get a better shell account, or talk
> your sysadmin into changing permissions on that file so you can execute it.


Or learn the syntax for 'find', which comes with most unix variants, if
not all of them.

find / -name netstat -print

That should search the entire filesystem, looking in every directory you
have permission to go in, and report back what it finds.

Don't like the error output? " 2>/dev/null" at the end of the above command
will supress it.

> *****************************************************
> Evil genius tip: Your sysadmin won't let you run your favorite Unix
> commands? Don't grovel! Compile your own! Most ISPs don't mind if you keep


Many utils will require the ability to open raw sockets (like ping or
traceroute), and will not operate correctly if you compile it yourself.

> ****************************************************
> Evil Genius tip: Bring up the file .login in Pico. It controls lots of what
> happens in your shell account. Want to edit it? You could totally screw up
> your account by changing .login. But you are a hacker, so you aren't afraid,


Since you are fond of using BASH, and mention it above, you should also
mention that editing .login will do nothing if BASH is your default shell.

BASH will look for three files during initalization: .bash_profile  .bash_login
and .profile