The Hacker's Encyclopedia 1998

home *** CD-ROM | disk | FTP | other *** search

/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / hacking / systems / rsts_oz.txt < prev next >

Wrap

Text File | 2003-06-11 | 13.7 KB | 242 lines

:-----------------------------------------------------------: : : : 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--------------------------: