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