SuperHack/SuperHack CD.bin/Hack/MISC/DATAPAK.ZIP/DATAPAC.ZIP/DATAPAC.HAC

Text File | 1990-04-19 | 15.2 KB | 313 lines

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$                                                                          $$
$$                            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............................ [phone] <3-2400>
Dark Side of the Moon........................... [phone] <3-2400>