% = % = % = % = % = % = % = % = = % 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 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