home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / zines / phrack1 / phrack17.006 < prev    next >
Encoding:
Text File  |  2003-06-11  |  4.1 KB  |  96 lines
  1.  
  2.                         % = % = % = % = % = % = % = %
  3.                         =                           =
  4.                         %   P h r a c k   X V I I   %
  5.                         =                           =
  6.                         % = % = % = % = % = % = % = %
  7.  
  8.                               Phrack  Seventeen
  9.                                 07 April 1988
  10.  
  11.                      File 6 of 12 : How to Hack HP2000's
  12.  
  13.  
  14.  
  15. How to Hack an HP 2000
  16.  
  17. By: ** Grey Sorcerer
  18.  
  19. Okay, so you've read the HP-2000 basic guides, and know your way around.  I
  20. will not repeat all that.
  21.  
  22. There's two or three things I've found that allow you through HP 2000
  23. security.
  24.  
  25. 1. When you log in, a file called HELLO on the user number Z999 is run.  A lot
  26. of time this file is used to deny you access.  Want in?  Well, it's just a
  27. BASIC program, and an be BREAKed.. but, usually the first thing they do in
  28. that program is turn Breaks (interrupts) off by the BRK(0) function.  However,
  29. if you log in like this:
  30.  
  31. HELLO-D345,PASS (return) (break)
  32.  
  33. With the break nearly instantly after the return, a lot of time, you'll abort
  34. the HELLO program, and be home free.
  35.  
  36. 2. If you can create a "bad file", which takes some doing, then anytime you
  37. try to CSAVE this file (compile and save), the system will quickly fade into a
  38. hard crash.
  39.  
  40. 3. How to make a bad file and other goodies:
  41.  
  42. The most deadly hole in security in the HP2000 is the "two terminal" method.
  43. You've got to understand buffers to see how it works.  When you OPEN a file,
  44. or ASSIGN it (same thing), you get 256 bytes of the file -- the first 256.
  45. When you need anymore, you get 256 more.  They are brought in off the disk in
  46. discrete chunks.  They are stored in "buffers."
  47.  
  48. So.  Save a bunch of junk to disk -- programs, data, whatever.  Then once your
  49. user number is full, delete all of it.  The effect is to leave the raw jumbled
  50. data on disk.
  51.  
  52.  
  53. Pick a time when the system is REAL busy, then:
  54.  
  55. 1. Have terminal #1 running a program that looks for a file to exist (with the
  56. ASSIGN) statement as quickly as it can loop.  If it finds the file there, it
  57. goes to the very end of the file, and starts reading backwards, record by
  58. record, looking for data.  If it finds data, it lets you know, and stops at an
  59. input prompt.  It is now running.
  60.  
  61. 2. Have terminal #2 create a really huge data file (OPEN-FILE, 3000) or
  62. however it goes.
  63.  
  64. What happens is terminal #2's command starts zeroing all the sectors of the
  65. file, starting at file start.  But it only gets so far before someone else
  66. needs the processor, and kicks #2 out.  The zeroing stops for a sec.  Terminal
  67. #1 gets in, finds the file there, and reads to the end.  What's there?  Old
  68. trash on disk.  (Which can be mighty damned interesting by the way -- did you
  69. know HP uses a discrete mark to indicate end-of-buffer?  You've just maybe got
  70. yourself a buffer that is as deep as system memory, and if you're clever, you
  71. can peek or poke anywhere in memory.  If so, keep it, it is pure gold).
  72.  
  73. But.  Back to the action.
  74.  
  75. 3. Terminal #2 completes the OPEN.  He now deletes the file.  This leaves
  76. Terminal #1 with a buffer full of data waiting to be dumped back to disk at
  77. that file's old disk location.
  78.  
  79. 4. Terminal #2 now saves a load of program files, as many as are required to
  80. fill up the area that was taken up by the deleted big file.
  81.  
  82. 5. You let Terminal #1 past the input prompt, and it writes its buffer to
  83. disk.  This promptly overlays some program just stored there.  Result:  "bad
  84. program."  HPs are designed with a syntax checker and store programs in token;
  85. a "bad program" is one that the tokens are screwed up in.  Since HP assumes
  86. that if a program is THERE, it passed the syntax check, it must be okay...
  87. it's in for big problems.  For a quick thrill, just CSAVE it..  system tries
  88. to semi-compile bad code, and drops.
  89.  
  90. Really, the classier thing to do with this is to use the "bottomless buffer"
  91. to look through your system and change what you don't like.. maybe the
  92. password to A000?  Write some HP code, look around memory, have a good time.
  93. It can be done.
  94.  
  95. ** Grey Sorcerer
  96.