% = % = % = % = % = % = % = %
                        =                           =
                        %   P h r a c k   X V I I   %
                        =                           =
                        % = % = % = % = % = % = % = %

                              Phrack  Seventeen
                                07 April 1988

                     File 6 of 12 : How to Hack HP2000's



How to Hack an HP 2000

By: ** Grey Sorcerer

Okay, so you've read the HP-2000 basic guides, and know your way around.  I
will not repeat all that.

There's two or three things I've found that allow you through HP 2000
security.

1. When you log in, a file called HELLO on the user number Z999 is run.  A lot
of time this file is used to deny you access.  Want in?  Well, it's just a
BASIC program, and an be BREAKed.. but, usually the first thing they do in
that program is turn Breaks (interrupts) off by the BRK(0) function.  However,
if you log in like this:

HELLO-D345,PASS (return) (break)

With the break nearly instantly after the return, a lot of time, you'll abort
the HELLO program, and be home free.

2. If you can create a "bad file", which takes some doing, then anytime you
try to CSAVE this file (compile and save), the system will quickly fade into a
hard crash.

3. How to make a bad file and other goodies:

The most deadly hole in security in the HP2000 is the "two terminal" method.
You've got to understand buffers to see how it works.  When you OPEN a file,
or ASSIGN it (same thing), you get 256 bytes of the file -- the first 256.
When you need anymore, you get 256 more.  They are brought in off the disk in
discrete chunks.  They are stored in "buffers."

So.  Save a bunch of junk to disk -- programs, data, whatever.  Then once your
user number is full, delete all of it.  The effect is to leave the raw jumbled
data on disk.


Pick a time when the system is REAL busy, then:

1. Have terminal #1 running a program that looks for a file to exist (with the
ASSIGN) statement as quickly as it can loop.  If it finds the file there, it
goes to the very end of the file, and starts reading backwards, record by
record, looking for data.  If it finds data, it lets you know, and stops at an
input prompt.  It is now running.

2. Have terminal #2 create a really huge data file (OPEN-FILE, 3000) or
however it goes.

What happens is terminal #2's command starts zeroing all the sectors of the
file, starting at file start.  But it only gets so far before someone else
needs the processor, and kicks #2 out.  The zeroing stops for a sec.  Terminal
#1 gets in, finds the file there, and reads to the end.  What's there?  Old
trash on disk.  (Which can be mighty damned interesting by the way -- did you
know HP uses a discrete mark to indicate end-of-buffer?  You've just maybe got
yourself a buffer that is as deep as system memory, and if you're clever, you
can peek or poke anywhere in memory.  If so, keep it, it is pure gold).

But.  Back to the action.

3. Terminal #2 completes the OPEN.  He now deletes the file.  This leaves
Terminal #1 with a buffer full of data waiting to be dumped back to disk at
that file's old disk location.

4. Terminal #2 now saves a load of program files, as many as are required to
fill up the area that was taken up by the deleted big file.

5. You let Terminal #1 past the input prompt, and it writes its buffer to
disk.  This promptly overlays some program just stored there.  Result:  "bad
program."  HPs are designed with a syntax checker and store programs in token;
a "bad program" is one that the tokens are screwed up in.  Since HP assumes
that if a program is THERE, it passed the syntax check, it must be okay...
it's in for big problems.  For a quick thrill, just CSAVE it..  system tries
to semi-compile bad code, and drops.

Really, the classier thing to do with this is to use the "bottomless buffer"
to look through your system and change what you don't like.. maybe the
password to A000?  Write some HP code, look around memory, have a good time.
It can be done.

** Grey Sorcerer