Copy Link
Add to Bookmark
Report
Phrack Inc. Volume 02 Issue 17 File 05
% = % = % = % = % = % = % = %
= =
% P h r a c k X V I I %
= =
% = % = % = % = % = % = % = %
Phrack Seventeen
07 April 1988
File 5 of 12 : How to Hack Cyber Systems
How To Hack A CDC Cyber
By: ** Grey Sorcerer
Index:
1. General Hacking Tips
2. Fun with the card punch
3. Getting a new user number the easy way
4. Hacking with Telex and the CDC's batch design
5. Grabbing a copy of the whole System
6. Staying Rolled In with BREAK
7. Macro Library
8. RJE Status Checks
9. The Worm
10. The Checkpoint/Restart Method to a Better Validation
I'm going to go ahead and skip all the stuff that's in your CDC reference
manuals.. what's a local file and all that. If you're at the point of being
ready to hack the system, you know all that; if not, you'll have to get up to
speed on it before a lot of this will make sense. Seems to me too many "how
to hack" files are just short rewrites of the user manuals (which you should
get for any serious penetration attempt anyway, or you'll miss lots of
possibilities), without any tips on ways to hack the system.
General hacking tips:
Don't get caught. Use remote dialups if possible and never never use any user
number you could be associated with. Also never re-use a user number.
Remember your typical Cyber site has a zillion user numbers, and they can't
watch every one. Hide in numbers. And anytime things get "hot", lay off for
awhile.
Magtapes are great. They hold about 60 Meg, a pile of data, and can hold even
more with the new drives. You can hide a lot of stuff here offline, like
dumps of the system, etc., to peruse. Buy a few top quality ones.. I like
Black Watch tapes my site sells to me the most, and put some innocuous crap on
the first few records.. data or a class program or whatever, then get to the
good stuff. That way you'll pass a cursory check. Remember a usual site has
THOUSANDS of tapes and cannot possibly be scanning every one; they haven't
time.
One thing about the Cybers -- they keep this audit trail called a "port log"
on all PPU and CPU accesses. Normally, it's not looked at. But just remember
that *everything* you do is being recorded if someone has the brains and the
determination (which ultimately is from you) to look for it. So don't do
something stupid like doing real work on your user number, log off, log right
onto another, and dump the system. They WILL know.
Leave No Tracks.
Also remember the first rule of bragging: Your Friends Turn You In.
And the second rule: If everyone learns the trick to increasing priority,
you'll all be back on the same level again, won't you? And if you show just
two friends, count on this: they'll both show two friends, who will show
four...
So enjoy the joke yourself and keep it that way.
Fun With The Card Punch
Yes, incredibly, CDC sites still use punch cards. This is well in keeping
with CDC's overall approach to life ("It's the 1960's").
The first thing to do is empty the card punch's punchbin of all the little
punchlets, and throw them in someone's hair some rowdy night. I guarantee the
little suckers will stay in their hair for six months, they are impossible to
get out. Static or something makes them cling like lice. Showers don't even
work.
The next thing to do is watch how your local installation handles punch card
decks. Generally it works like this. The operators love punchcard jobs
because they can give them ultra-low priority, and make the poor saps who use
them wait while the ops run their poster-maker or Star Trek job at high
priority. So usually you feed in your punchcard deck, go to the printout
room, and a year later, out comes your printout.
Also, a lot of people generally get their decks fed in at once at the card
reader.
If you can, punch a card that's completely spaghetti -- all holes punched.
This has also been known to crash the cardreader PPU and down the system. Ha,
ha. It is also almost certain to jam the reader. If you want to watch an
operator on his back trying to pick pieces of card out of the reader with
tweezers, here's your chance.
Next, the structure of a card deck job gives lots of possibilities for fun.
Generally it looks like this:
JOB card: the job name (first 4 characters)
User Card: Some user number and password -- varies with site
EOR card: 7-8-9 are punched
Your Batch job (typically, Compile This Fortran Program). You know, FTN.
LGO. (means, run the Compiled Program)
EOR card: 7-8-9 are punched
The Fortran program source code
EOR card: 7-8-9 are punched
The Data for your Fortran program
EOF card: 6-7-8-9 are punched. This indicates: (end of deck)
This is extremely typical for your beginning Fortran class.
In a usual mainframe site, the punchdecks accumulate in a bin at the operator
desk. Then, whenever he gets to it, the card reader operator takes about
fifty punchdecks, gathers them all together end to end, and runs them through.
Then he puts them back in the bin and goes back to his Penthouse.
GETTING A NEW USER NUMBER THE EASY WAY
Try this for laughs: make your Batch job into:
JOB card: the job name (first 4 characters)
User Card: Some user number and password -- varies with site
EOR card: 7-8-9 are punched
COPYEI INPUT,filename: This copies everything following the EOR mark to the
filename in this account.
EOR Card: 7-8-9 are punched.
Then DO NOT put an EOF card at the end of your job.
Big surprise for the job following yours: his entire punch deck, with, of
course, his user number and password, will be copied to your account. This is
because the last card in YOUR deck is the end-of-record, which indicates the
program's data is coming next, and that's the next person's punch deck, all
the way up to -his- EOF card. The COPYEI will make sure to skip those pesky
record marks, too.
I think you can imagine the rest, it ain't hard.
Hacking With Telex
When CDC added timeshare to the punch-card batch-job designed Cyber machines,
they made two types of access to the system: Batch and Telex. Batch is a
punch-card deck, typically, and is run whenever the operator feels like it.
Inside the system, it is given ultra low priority and is squeezed in whenever.
It's a "batch" of things to do, with a start and end.
Telex is another matter. It's the timeshare system, and supports up to, oh,
60 terminals. Depends on the system; the more RAM, the more swapping area (if
you're lucky enough to have that), the more terminals can be supported before
the whole system becomes slug-like.
Telex is handled as a weird "batch" file where the system doesn't know how
much it'll have to do, or where it'll end, but executes commands as you type
them in. A real kludge.
Because the people running on a CRT expect some sort of response, they're
given higher priority. This leads to "Telex thrashing" on heavily loaded CDC
systems; only the Telex users get anywhere, and they sit and fight over the
machine's resources.
The poor dorks with the punch card decks never get into the machine, because
all the Telex users are getting the priority and the CPU. (So DON'T use punch
cards.)
Another good tip: if you are REQUIRED to use punch cards, then go type in
your program on a CRT, and drop it to the automatic punch. Sure saves trying
to correct those typos on cards..
When you're running under Telex, you're part of one of several "jobs" inside
the system. Generally there's "TELEX," something to run the line printer,
something to run the card reader, the mag tape drivers (named "MAGNET") and
maybe a few others floating around. There's limited space inside a Cyber..
would you believe 128K 60-bit words?.. so there's a limited number of jobs
that can fit. CDC put all their effort into "job scheduling" to make the best
of what they had.
You can issue a status command to see all jobs running; it's educational.
Anyway, the CDC machines were originally designed to run card jobs with lots
of magtape access. You know, like IRS stuff. So they never thought a job
could "interrupt," like pressing BREAK on a CRT, because card jobs can't.
This gives great possibilities.
Like:
Grabbing a Copy Of The System
For instance. Go into BATCH mode from Telex, and do a Fortran compile.
While in that, press BREAK. You'll get a "Continue?" verification prompt.
Say no, you'd like to stop.
Now go list your local files. Whups, there's a new BIG one there. In fact,
it's a copy of the ENTIRE system you're running on -- PPU code, CPU code, ALL
compilers, the whole shebang! Go examine this local file; you'll see the
whole bloody works there, mate, ready to play with.
Of course, you're set up to drop this to tape or disk at your leisure, right?
This works because the people at CDC never thought that a Fortran compile
could be interrupted, because they always thought it would be running off
cards. So they left the System local to the job until the compile was done.
Interrupt the compile, it stays local.
Warning: When you do ANYTHING a copy of your current batch process shows up
on the operator console. Typically the operators are reading Penthouse and
don't care, and anyway the display flickers by so fast it's hard to see. But
if you copy the whole system, it takes awhile, and they get a blow-by-blow
description of what's being copied. ("Hey, why is this %^&$^ on terminal 29
copying the PPU code?") I got nailed once this way; I played dumb and they let
me go. ("I thought it was a data file from my program").
Staying "Rolled In"
When the people at CDC designed the job scheduler, they made several "queues."
"Queues" are lines.
There's:
1. Input Queue. Your job hasn't even gotten in yet. It is standing outside,
on disk, waiting.
2. Executing Queue. Your job is currently memory resident and is being
executed, although other jobs currently in memory are
competing for the machine as well. At least you're in
memory.
3. Timed/Event Rollout Queue: Your job is waiting for something, usually a
magtape. Can also be waiting for a given time. Yes, this
means you can put a delayed effect job into the system. Ha,
ha. You are on disk at this point.
4. Rollout Queue: Your job is waiting its turn to execute. You're out on
disk right now doing nothing.
Anyway, let's say you've got a big Pascal compile. First, ALWAYS RUN FROM
TELEX (means, off a CRT). Never use cards. If you use cards you're
automatically going to be low man on the priority schedule, because the CPU
doesn't *have* to get back to you soon. Who of us has time to waste?
Okay, do the compile. Then do a STATUS on your job from another machine.
Typically you'll be left inside the CPU (EXECUTE) for 10 seconds, where you'll
share the actual CPU with about 10-16 other jobs. Then you'll be rolled-out
(ROLLOUT), at which time you're phucked; you have to wait for your priority to
climb back up before it'll execute some more of your job. This can take
several minutes on a deeply loaded system.
(All jobs have a given priority level, which usually increments every 10 sec
or so, until they start executing).
Okay, do this. Press BREAK, then at the "Continue?" prompt, say yes. What
happened? Telex had to "roll your job in" to process the BREAK! So you get
another free 10 seconds of CPU -- which can get a lot done.
If you sit and hit BREAK - Y <return> every 10 sec or so during a really big
job, you will just fly through it. Of course, everyone else will be sitting
and staring at their screen, doing nothing, because you've got the computer.
If you're at a school with a Cyber, this is how to get your homework done at
high speed.
Macro Library
If you have a typical CDC site, they won't give you access to the "Macro
library." This is a set of CPU calls to do various things -- open files, do
directory commands, and whatnot. They will be too terrified of "some hacker."
Reality: The dimbulbs in power don't want to give up ANY of their power to
ANYONE. You can't really do that much more with the Macro library, which
gives assembly language access to the computer, than you can with batch
commands.. except what you do leaves lots less tracks. They REALLY have to
dig to find out what your program did if you use Macro calls.. they have to
go to PPU port logs, which is needle in a haystack sort of stuff, vs. batch
file logs, which are real obvious.
Worry not. Find someone at Arizona State or Minnesota U. that's cool, and get
them to send you a tape of the libraries. You'll get all the code you can
stand to look at. By the way they have a great poster tape... just copy the
posters to the line printer. Takes a long time to print them but it's worth
it. (They have all the classic ones.. man on the moon, various playmates,
Spock, etc. Some are 7 frames wide!).
With the Macro library, you can do many cool things.
The best is a demon scanner. All CDC user numbers have controlled access for
other users to individual files -- either private, (no access to anyone else),
semiprivate (others can read it but a record is made), or public (anyone can
diddle your files, no record). What you want is a program (fairly easy to do
in Fortran) that counts through user numbers, doing directory commands. If it
finds anything, it checks for non semi-private (so no records are made), then
copies it to you.
You'll find the damnedest stuff, I guarantee it. Try to watch some system
type signing in and get the digits of his user number, then scan variations
beginning with that user #. For instance, if he's a SYS1234, then scan all
user #'s beginning with SYS (sysaaaa to sys9999).
Since it's all inside the Fortran program, the only record, other than
hard-to-examine PPU logs, is a "Run Fortran Program" ("LGO.") on the batch
dayfile. If you're not giving the overworked system people reason to suspect
that commonplace, every-day student Fortran compile is anything out of the
ordinary, they will never bother to check -- the amount of data in PPU logs is
OVERWHELMING.
But you can get great stuff.
There's a whole cool library of Fortran-callable routines to do damned near
anything a batch command could do in the Minnesota library. Time to get some
Minnesota friends -- like on UseNet. They're real cooperative about sending
out tapes, etc.
Generally you'll find old files that some System Type made public one day (so
a buddy could copy them) then forgot about. I picked off all sorts of stuff
like this. What's great is I just claimed my Fortran programs were hanging
into infinite loops -- this explained the multi-second CPU execution times.
Since there wasn't any readily available record of what I was up to, they
believed it. Besides, how many idiot users really DO hang into loops? Lots.
Hide in numbers. I got Chess 4.2 this way -- a championship Chess program --
and lots of other stuff. The whole games library, for instance, which was
blocked from access to mere users but not to sysfolk.
Again, they *can* track this down if you make yourself obnoxious (it's going
to be pretty obvious what you're doing if there's a CAT: SYSAAAA
CAT: SYSAAAB CAT: SYSAAAC .. etc. on your PPU port log) so do this on someone
else's user number.
RJE Status Checks
Lots of stupid CDC installations.. well, that doesn't narrow the field much..
have Remote Job Entry stations. Generally at universities they let some poor
student run these at low pay.
What's funny is these RJE's can do a status on the jobs in the system, and the
system screeches to a halt while the status is performed. It gets top
priority.
So, if you want to incite a little rebellion, just sit at your RJE and do
status requests over and over. The system will be even slower than usual.
The Worm
Warning: This is pretty drastic. It goes past mere self-defense in getting
enough priority to get your homework done, or a little harmless exploration
inside your system, to trying to drop the whole shebang.
It works, too.
You can submit batch jobs to the system, just as if you'd run them through the
punchcard reader, using the SUBMIT command. You set up a data file, then do
SUBMIT datafile. It runs separate from you.
Now, let's say we set up a datafile named WORM. It's a batch file. It looks
like this:
JOB
USER,blah (whatever -- a user number you want crucified)
GET,WORM; get a copy of WORM
SUBMIT,WORM.; send it to system
SUBMIT,WORM.; send it to system
SUBMIT,WORM.; send it to system
SUBMIT,WORM.; send it to system
SUBMIT,WORM.; send it to system
SUBMIT,WORM.; send it to system
SUBMIT,WORM.; send it to system
SUBMIT,WORM.; send it to system
SUBMIT,WORM.; send it to system
SUBMIT,WORM.; send it to system
SUBMIT,WORM.; send it to system
SUBMIT,WORM.; send it to system
SUBMIT,WORM.; send it to system
SUBMIT,WORM.; send it to system
SUBMIT,WORM.; send it to system
SUBMIT,WORM.; send it to system
(16 times)
(end of file)
Now, you SUBMIT WORM. What happens? Worm makes 16 copies of itself and
submits those. Those in turn make 16 copies of themselves (now we're up to
256) and submit those. Next pass is 4096. Then 65536. Then...
Now, if you're really good, you'll put on your "job card" a request for high
priority. How? Tell the system you need very little memory and very little
CPU time (which is true, Submit takes almost nothing at all). The scheduler
"squeezes" in little jobs between all the big ones everyone loves to run, and
gives ultra-priority to really tiny jobs.
What happens is the system submits itself to death. Sooner or later the input
queue overflows .. there's only so much space .. and the system falls apart.
This is a particularly gruesome thing to do to a system, because if the guy
at the console (count on it) tries the usual startup, there will still be
copies of WORM in the input queue. First one of those gets loose, the system
drops again. With any luck the system will go up and down for several hours
before someone with several connected brain cells arrives at the operator
console and coldstarts the system.
If you've got a whole room full of computer twits, all with their hair tied
behind them with a rubber band into a ponytail, busily running their Pascal
and "C" compiles, you're in for a good time. One second they will all be
printing -- the printers will be going weep-weep across the paper. Next
second, after you run, they will stop. And they will stay stopped. If you've
done it right they can't get even get a status. Ha, ha.
The faster the CPU, the faster it will run itself into the ground.
CDC claims there is a limit on the number of jobs a user number can have in
the system. As usual they blew it and this limit doesn't exist. Anyway, it's
the input queue overflow that kills things, and you can get to the input queue
without the # of jobs validation check.
Bear in mind that *anything* in that batch file is going to get repeated ten
zillion times at the operator console as the little jobs fly by by the
thousands. So be sure to include some charming messages, like:
job,blah
user,blah
* eat me!
get,worm
submit,worm .. etc.
There will now be thousands of little "eat me!"'s scrolling across the console
as fast as the console PPU can print them.
Generally at this point the operator will have his blood pressure really
spraying out his ears.
Rest assured they will move heaven and earth to find you. This includes past
dayfiles, user logs, etc. So be clean. Remember, "Revenge is a dish best
served cold." If you're mad at them, and they know it, wait a year or so,
until they are scratching their heads, wondering who hates them this much.
Also: make sure you don't take down a really important job someone else is
doing, okay? Like, no medical databases, and so forth.
Now, for a really deft touch, submit a timed/event job. This "blocks" the job
for awhile, until a given time is reached. Then, when you're far, far away,
with a great alibi, the job restarts, the system falls apart, and you're
clear. If you do the timed/event rollout with a Fortran program macro call,
it won't even show up on the log.
(Remember that the System Folk will eventually realize, in their little minds,
what you've done. It may take them a year or two though).
CHECKPOINT / RESTART
I've saved the best for last.
CDC's programmers supplied two utilities, called CheckPoint and Restart,
primarily because their computers kept crashing before they would finish
anything. What Checkpoint does is make a COMPLETE copy of what you're doing -
all local files, all of memory, etc. -- into a file, usually on a magtape.
Then Restart "restarts" from that point.
So, when you're running a 12 hour computer job, you sprinkle checkpoints
throughout, and if the CDC drops, you can restart from your last CKP. It's
like a tape backup of a hard disk. This way, you only lose the work done on
your data between the last checkpoint and now, rather than the whole 12 hours.
Look, this is real important on jobs that take days -- check out your local
IRS for details..
Now what's damned funny is if you look closely at the file Checkpoint
generates, you will find a copy of your user validations, which tell
everything about you to the system, along with the user files, memory, etc.
You'll have to do a little digging in hex to find the numbers, but they'll
match up nicely with the display you of your user validations from that batch
command.
Now, let's say you CKP,that makes the CKP file. Then run a little FORTRAN
program to edit the validations that are inside that CKP-generated file. Then
you RESTART from it. Congratulations. You're a self made man. You can do
whatever you want to do - set your priority level to top, grab the line
printer as your personal printer, kick other jobs off the system (it's more
subtle to set their priority to zilch so they never execute), etc. etc.
You're the operator.
This is really the time to be a CDC whiz and know all sorts of dark, devious
things to do. I'd have a list of user numbers handy that have files you'd
like made public access, so you can go in and superzap them (then peruse them
later from other signons), and so forth.
There's some gotchas in here.. for instance, CKP must be run as part of a
batch file out of Telex. But you can work around them now that you know the
people at CDC made RESTART alter your user validations.
It makes sense in a way. If you're trying to restart a job you need the same
priority, memory, and access you had when trying to run it before.
Conclusion
There you have it, the secrets of hacking the Cyber.
They've come out of several years at a college with one CDC machine, which I
will identify as being somewhere East. They worked when I left; while CDC may
have patched some of them, I doubt it. They're not real fast on updates to
their operating system.
** Grey Sorcerer
