:-----------------------------------------------------------:
: :
: M A K I N G T H E M O S T O F :
: R S T S / E S Y S T E M S :
: ====================================== :
: :
: Written by : Captain Hack :
: : of Melbourne, :
: : Australia. :
: Written on : 01-Feb-86. :
: File No. : V01A-01 :
: :
:-----------------------------------------------------------:
Originally Displayed in the U.S. on:
P-80 Int'l Information Systems
INTRODUCTION.
This file is a tutorial on making the the most of a
RSTS/E system, making the most could mean anything from
making the system do so neat tricks, to using it to you
advantage, to taking it over completely; depending on your
needs!
For most of the examples you will need an account,
obviously non-privilaged, else you would not be reading this
tutorial. Bear in mind that most, if not all, of the
techniques described can be changed by the sysop. I found
this out while trying them, but most sysop's don't realize
everythings full potential and how it will be used; needless
to say that I most likely have missed out on things. Anyway I
hope you like the tutorial and you have an educational
experience! I will rely on also using your imagination and
ingenuity, as this is often needed.
OBTAINING OLD FILES.
If ever you have a valuble file that you don't want
people to see the contents of for one reason or another,
always write other information (random of fixed) over the
entire file before deleting it. When the system creates a
file it likes to have it continuous if possible, which means
many blocks will be consecutive. When a file is created the
system alters information in a system file indicting that a
particular block or set of blocks have been allocated so as
they will not be over-written. The directory knows which
which blocks are associated with which file, but when you
delete a file, the system flags the used blocks as available
and delete the directory entry. The system doesn't wipe the
information.
To dig up these old blocks, write yourself a program to
open a large file, I will leave the size up to you. You use
the filesize option in the OPEN statement to do this, then
just read in the blocks. When possible use block I/O for file
manipulation because of its speed and convienience. Look
through the blocks any if one if worth keeping save if to
another file.
-2-
Seeing as BASIC programs have line numbers, as long as you
find all the blocks, file reconstruction is easy.
There of course is no guarantee that you will find them
all. Some may have been reallocated, but it's amazing what
you can find! The bigger the block cluster size used in files
the easier it is to reconstruct them. Just experiment!
ANNOYING THE USERS.
A way to annoy the users of the system is a techinque
discovered just after we found out about the block recovery.
After finding remnants of some of my data strewn across the
system I decided the best thing to do was to zero all the
available disk space. One Sunday night we wrote a program to
open a very large file (all free disk space in fact) and
proceeded to zero this. This was sucessful, except when the
system was supposed to kill the file something went wrong and
the file was not deleted. The next morning, before the sysops
arrived, the users tried to login. Because there was no free
space to write login records or do anything! No-one could
login! Apparently this had the operators mystified why they
couldn't get into their system. They had to reboot, or so I
heard, they later worked out what had happended. They then
asked why!
THE PSEUDO KEYBOARD.
The pseudo keyboard (device PKnn:) must be about the most
useful and versatile device. This is the device to be used
for the perfect hack! Originally, like many people, I saw it
in a manual and really didn't read about it but as usual when
I was going over the manuals with a fine tooth comb I read
into it. Although most of the weak-points discussed in this
tutorial can be removed by patching implemented by the system
operator, they are likely to ignore them. The pseudo keyboard
is a keyboard which doesn't physically exist! When you open
the channel and do I/O's with it it appears like another
keyboard. It even has a keyboard number. This is useful for
extracting inormation for your programs that can only be
accessed in command mode. An example of this is SYSTAT. I
recommend that you get hold of a PROGRAMMING MANUAL and read
it thoroughly, including the section on pseudo keyboards.
PASSWORD CATCHING.
Password catching is always desirable if you want access
to a privilaged account! When I first started out we ran a
crude program which did I/O's to the desired terminal and
gave the responses that the system would give. A number of
problems that we ran into was that you cannot fake the whole
system, that is impossible using those methods, and also this
did not allow for timing delays which most users were used to
and expected.
-3-
With these old programs, the passwords obtained never
lasted long because the user almost always knew they had been
caught because users get suspicious when they get an INVALD
ENTRY - TRY AGAIN message when they put in their correct
password. This problem left me pondering how could you write
the "perfect" password catcher. When I discovered pseudo
keyboards I was thinking of applications, then it hit me. Why
not simulate the whole job of another user? It was possible
too!
To do this you write a program to open a channel to the
keyboard where the person will enter the desired account
number and password. You also open a pseudo keyboard.
Basically from then on you pass the data from one to the
other, and you keep checking what is being typed and when the
account number and password are detected save them to a disk
file encoded or what ever. You should continue to simulate
the job until the person logs off. There are a few things to
be careful about. When the person runs SYSTAT make sure the
output is sent to the terminal replaces the pseudo keyboard
number with his keyboard number. Make sure he doesn't see a
channel is open to his terminal and other things like that.
Another things to be careful of is that he doesn't run
programs to tell him his keyboard number or a few other
things like that or a program where the terminal where it is
run from affects its operation, if he does it could be quite
hard to deal with. All of the techniques I describe will need
practice and perfection. Perfect things before using them and
don't tell people what you are doing. Another thing to be
careful of are operators who look at the files in your
account. A simple way to deal with those people is to
encrypt/code those files and keep decoded copies online for
as little time as possible. If you can't stay at a terminal
to have the password catcher program running don't despair
because I will show you how to detach jobs later. My biggest
piece of advice is always stalk and watch the target system
first for a while. Get to know what most or all of the
programs in the project 1 accounts do, and only after you are
sure should you try and pull a stunt like I decribe. Once you
have a privilaged password you must use your own imagination
to how you use it. Remember always be security conscious.
Don't take unneccessary risks and by the time you get to a
privilaged account you should know all the SYS functions
possible and how to use them to your advantage. If you system
keeps login and logout records remember to edit them, because
depending on what you do, your activities should be able to
go on undetected!
DETACHING JOBS.
There is one way a non-privilaged user can detach a job.
This is done using pseudo keyboards. You will need to read
the PROGRAMMING MANUAL (the RSTS/E bible for hackers!) and
write yourself a program to almost simulate a job except you
do it to your terminal and you don't log the passwords etc..
-4-
When you are logged into your account and you run this
program it will look on your terminal like you are logged out
again and you will have to log into the system again. Log
into the account which you want to detach the job from and
you must have access to the program from this account. You
should execute the program you want detached then have a
special key sequence that will close the channel to the
pseudo keyboard. You detacher program will finish and that is
how you do it. ut you say that doesn't work, it just kills
the job you started when you closed the channel to the pseudo
keyboard, but you didn't wait for the most important piece!
When opening the pseudo keyboard you must have included MODE
1 in the OPEN statement which tells the system to detach the
job when you close the channel instead of killing the job.
When you do a SYSTAT you will see your job running detached.
Don't forget opertors mightn't like you detaching too many
jobs so do it when they aren't around. For a job to terminate
itself you may try getting it to run LOGOUT, but when it
tries to output something like a message saying your disk
space or have a nice afternoon it will sit there helpless in
a HB wait state until someone attaches to it (like you or an
operator) or an operator kills it. To get around this take
notice of the message you get when you log in and you have a
job detached. The system tells you that and asks if you want
to attach. So you what you do is make you detached program
open a pseudo keyboard in a mode that won't detach it and get
that job to log into your account. Don't worry about
entrusting your password to the program as others can't
obtain it. Anyway when you get the new job to log in make it
attach to the job you wanted killed, then when your original
program closes the channel to the pseudo keyboard the job
running on the pseudo keyoard is killed and it effectively
kills itself as it attached to itself in a manner of
speaking, and thus the job disappears! (Well it worked on the
system I tried it on)
RECOMMENDATIONS.
When you attempt to do all of this I advise you to get
hold of (buy ($20) or borrow) the RSTS/E PROGRAMMING MANUAL.
There would be at least one with the system and are also
available from DEC (Digital Equipment Corporation).
Finally, non of the above methods and techniques are
guaranteed as they can be removed or altered by the system
operators. All of the techniques are valid and are not bugs
in the operating system. Whether your operator knows about
them or what they can do is a different matter! Anyhow have
fun, RSTS/E is a good operating system, and don't do anything
that I wouldn't do!
:--------------------------THE-END--------------------------:
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
