313 lines
15 KiB
Plaintext
313 lines
15 KiB
Plaintext
|
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
|
||
|
$$ $$
|
||
|
$$ 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>
|
||
|
|