$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$ $$ $$ A Guide to DataPAC $$ $$ $$ $$ A Technical Information File for the Canadian Hacker $$ $$ $$ $$ (C) 1989,1990 The Fixer - A Free Press Publication $$ $$ $$ $$ Edition 1.1 - April 18, 1990 $$ $$ $$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Foreword -------- Welcome to the exciting world of Packet Switched Data Communications. Your position as an outside hacker makes Telecom Canada's Packet Switched Network -- DATAPAC -- an even more magical place for you and all those close to you. Isn't life grand... What is DataPac? ---------------- DataPac is the Packet Switched Network of Telecom Canada, a consortium of major telephone companies across Canada. Originally brought into being in the late 1970's, Datapac's main purpose is to provide effective, reli1ble, high- speed data transfer to the business computing community nationwide. Several different levels of service are available on Datapac, from public-access PACX access that resembles a digitaf telephone system, to dedicated high-speed point-to-point leased lines. Since most hackers aren't likely to have a leased line in their homes, this fihold 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 "Rolded 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 somethi File 4: Have Federal Prosecutors gone too far? (Jim Thomas) (Vol. 1.18) File 5: FBI response to Rep. Don Edwards query of BBS Spying (Vol. 1.18) **************************************************************************** *** Volume 1, Issue #1.19 (June 26, 1990) ** **************************************************************************** File 1: SPECIAL ISSUE: MALICE IN WONDERLAND: THE E911 CHARGES (Vol. 1.19) **************************************************************************** *** Volume 1, Issue #1.20 (June 29, 1990) ** **************************************************************************** File 1: SPECIAL ISSUE: MALICE IN WONDERLAND (PART II) (Vol. 1.20) **************************************************************************** *** Volume 1, Issue #1.21 (July 8, 1990) ** **************************************************************************** File 1: Moderators' Comments (Vol 1.21) File 2: From the Mailbag (Vol 1.21) File 3: On the Problems of Evidence in Computer Investigation (Vol 1.21) File 4: Response to Mitch Kapors Critics (E. Goldstein) (Vol 1.21) File 5: The CU in the News: Excerpts from Computerworld article (Vol 1.21) **************************************************************************** *** Volume 1, Issue #1.22 (July 14, 1990) ** **************************************************************************** File 1: Moderators' Comments (Vol 1.22) File 2: From the Mailbag: More on CU and Free Speech (Vol 1.22) File 3: Response to "Problems of Evidence" (Mike Godwin) (Vol 1.22) File 4: What to do When the Police come a'knocking (Czar Donic) (Vol 1.22) File 5: Observations on the Law (Mike Godwin) (Vol 1.22) **************************************************************************** *** Volume 1, Issue #1.23 (July 18, 1990) ** **************************************************************************** File 1: Moderators' Comments (Vol 1.23) File 2: FTPing Thru Bitnet: BITFTP Help (Vol 1.23) File 3: Phrack as "Evidence?" (Vol 1.23) File 4: CU in the News (Vol 1.23) **************************************************************************** *** Volume 1, Issue #1.24 (July 22, 1990) ** **************************************************************************** File 1: Moderators' Comments (Vol 1.24) File 2: Neidorf Trial: The First Day (Vol 1.24) File 3: Electronic Frontier Update (John Perry Barlow) (Vol 1.24) File 4: Press Release from Atlanta Prosecutor on LoD Guilty Pleas (Vol 1.24) File 5: CU in the News (Vol 1.24) **************************************************************************** *** Volume 1, Issue #1.25 (July 28, 1990) ** **************************************************************************** File 1: Moderators' Comments (Vol 1.25) File 2: Neidorf Trial Over: CHARGES DROPPED (Moderators) (Vol 1.25) File 3: Warning about Continued Harassment of BBSs (Keith Henson) (Vol 1.25) File 4: League for Programming Freedom Protests Lotus Litigation (Vol 1.25) **************************************************************************** *** Volume 1, Issue #1.26 (Aug 2, 1990) ** **************************************************************************** File 1: Moderators' Corner (Vol 1.26) File 2: GURPS: Review of Steve Jackson's Cyperpunk Game (GRM) (Vol 1.26) File 3: Cyberspace Subculture in Real Life (Mike Godwin) (Vol 1.26) File 4: Update on RIPCO BBS and Dr. Ripco (Jim Thomas) (Vol 1.26) File 5: The Current TAP (TAP Editors) (Vol 1.26) **************************************************************************** *** Volume 1, Issue #1.27 (Aug 9, 1990) ** **************************************************************************** File 1: Moderators' Corner (Vol 1.27) File 2: From the Mailbag (Response to Neidorf article) (Vol 1.27) File 3: Dr. Ripco Speaks Out (Vol 1.27) File 4: SJG Gurps Cyberpunk (Vol 1.27) **************************************************************************** *** Volume 1, Issue #1.28 (Aug 12, 1990) ** **---------------------------- This file is copyrighted and wholly owned by The Fixer of The Free Press. You are licensed to distribute this file on bulletin boards as long as the bylines and copyright notices remain intact. All rights reserved. ----------------------------------------------------------------------------- Tommy's Holiday Camp............................ +1 (604) 598-4259 <3-2400> Dark Side of the Moon........................... +1 (408) 245-7726 <3-2400>