Conference noted::hackers_v1

    Seems that they don't have their terminals protected properly. 
    This sort of system is ripe for being hit with a login emulator.
    
    /Bevin

    Sounds like more than just the terminals are set wrong.
    How come people got into an account that had privileges like "SHARE"
    in it? I realize customers don't always see things the same way
    as internal DEC does but...
    
    I remember (so does Jym probably) a certain OPERATOR account on
    a certain college's computer that had the password set to OPERATOR
    for the longest time...
    
    The point I was trying to make is that a hack like that comes about
    from a whole series of questionable security/integrity practices.
    The terminals notwithstanding, this gets executed from a privileged
    account, right? It won't run without them, right?
    
    I always liked the hack of using NETDCL.COM and setting the process
    name to SERVER_pid or something inocuous like that. It always keeps
    system managers on their toes...

.0 is a nice way of hiding a process, but has anyone ever
created a way to make a process vanish completely ?
Ie not seen by either a Show System or a Show User  ?

No I'am not planning on breaking VMS security, this is just idle
interest

Peb


If the answer to this is Yes, please don't post the code
here since it may be frowned on by the powers that be

    Re .4:
    
    I know that there are a number of flags in the process header that
    will make you invisible to $GETJPI's (DELPEN for example), but most
    of the system commands don't use system services for this, instead
    they just read the process database.
    
    Therefore, the only thing that I could imagine that would fool them
    would be to zero your process index pointer.  As this would likely
    fool a lot of VMS also the side effects could be enormous.

    --  Barry

>    fool a lot of VMS also the side effects could be enormous.


yes that (or nearly that) is one method that works, and yes the side
effects are strange (any image that does a GETJPI fails !! (ie sho proc))

Any other methods ?


Peb

Well...I managed to get a process into an interesting state:  It was doing
direct Ethernet I/O (XEDRIVER QIO's) and, due to a bug, just kept doing them
until it went into a resource wait state, having run out of BIOLM.  In the
process, it tied up access to the alternate protocol I was using.  The
process was unkillable, and was preventing me from doing any further work;
for reasons I don't completely understand, I was unable to send it any
packets, which should have caused some of the outstanding I/O to complete,
at which point the resource wait state would finish, and the process - which
by now had DELETE PENDING set - would go away.

So...I patched the process header to give it a bunch more BIOLM.  This got
the process well into rundown - it closed down its I/O channels, gave up
most of its working set, and seemed intent on going away...except...it never
quite managed.  Instead, it just went into a permanent COM state.  Most
utilities - SHOW PROCESS, STOP, etc. - claim it doesn't exist.  Fortunately,
for obscure reasons SET PROCESS/PRIO found it, so I dropped it to priority 0.
It now shares the machine with the null process.

Just before this happened, the machine involved had had some hardware problems,
and was up and down a lot.  As fate would have it, these were all cleared up;
the system has now been up for some 17 days, and my process has run up an
impressive amount of CPU time (8 days or so worth).

8 days of 8600 CPU - IMAGINE what it's computed!

							-- Jerry

re: -1

You need a VM/VAX operating system ala IBM's VM/370!  Just the ticket for
projects like yours :-)  (ha ha...)

    re: .7
    I had one of those too, once.
    
    I don't recall the details (it's been a few months); we had some
    sort of network hiccup, and ended up with several network processes.
    SHO SYS/NET said they were there, STOP/ID said they weren't. Weird...
    
    Dave

    I heard about a fellow that did that once.  He carved a hunk out
    of non-paged pool, copied his program into it, then created a fork
    process pointed to that section of non-page pool.  His original
    process then went away and the fork process could play all day.
    
    In it, he did such things as periodically check to see who was logged
    in, sending them different messages at different times of the day.
    You're sitting at your terminal and get some kind of strange message
    like "Mornin' toad, how ya doin'?" and you're the only one logged
    in.  No batch jobs, no SHOW SYS, none of those things work so well.
    Of course, SDA is always around but still, 'twas a pretty nifty
    way to hide a process.

    re .10 etc.:
    
    The best way to do that is to copy your routine into pool and set it up
    as a repeating system subroutine that will do your periodic work. 
    
    However, neither a fork process nor a system subroutine is by any means
    a real process. There are all sorts of things that you can't do when
    you're on the interrupt stack. Like execute system services. Which
    means that you have to go to a lot of trouble to do any real work. I
    wrote something that I call the Loch Ness Monster that is driven by a
    repeating system subroutine. The Monster (which lives in pool and
    sticks its head out every so often) goes through incredible conniptions
    to do the simple work of creating a process. Once you have a real
    process, you're home free. 
    
    There is a variant of the Monster floating around called UISBUGLOA. It
    uses the monster to make a picture of a cockroach walk across the
    screen of a workstation every ten minutes. 
    
    As for the delete-pending bit, it is a good idea to be careful dinking
    this. It means that there is a $DELPRC in progress (or at least queued)
    in that process. Most things that deal with processes (e.g. $GETJPI)
    don't bother with that process if there's a delete pending. This is why
    the processes that you do a STOP/ID on are sortof there -- they have
    the delete pending bit set. SHOW SYSTEM still sees them because it
    scans the PCB vector directly and cares not a whit for the delete
    pending bit.
    
    I was given a program by someone in Ed. Services in Reading that did a
    *real* neat hack to make you truely invisible, even to SHOW SYSTEM. It
    tried to look for unused space off the end of the PCB vector and
    relocate your PCB index to an unused cell. It's a marvelous hack, but
    really dangerous. 
    
    	Jon, VMS hacker currently hacking for the VMS exec group

>    *real* neat hack to make you truly invisible, even to SHOW SYSTEM. It
>    tried to look for unused space off the end of the PCB vector and
>    relocate your PCB index to an unused cell. It's a marvelous hack, but
>    really dangerous. 


Thats almost exactly what I do !!!, I test the PCB vector at index offset
1  (farthest from sch$gl_pcbvec) and if not in use then switch the pointer
for my process and the empty (null) cell, build a new Ipid so
everything works ok, then decrement sch$gl_maxpix, this is the 'counter'
that controls how many processes to search for a show sys etc, so
now I am 100% invisible (see below), BUT a lot of utilities now
fail since I do not exist, to LOGOUT I have to exit from Exec mode
(by running the original proc once more )







! Run the program to 'switch' me from (in this case) pcb index 3
! to index 1 (if null) then decrement maxpix so I cannot be seen

JC $ r switch
Index = 3

! Show I cannot be seen
JC $ sho sys
VAX/VMS V4.5  on node JC 27-MAY-1987 21:48:23.83   Uptime    0 07:10:50
  Pid    Process Name    State  Pri      I/O       CPU       Page flts Ph.Mem
20200020 NULL            COM      0        0   0 06:02:28.07         0      0   
20200021 SWAPPER         HIB     16        0   0 00:00:01.47         0      0   
20200025 ERRFMT          HIB      8      491   0 00:00:04.02        70     88   
20200026 CACHE_SERVER    HIB     16      119   0 00:00:00.57        60     82   
20200027 CLUSTER_SERVER  HIB     10        6   0 00:00:00.67       109    182   
20200028 OPCOM           LEF      9     2752   0 00:00:40.88       934    124   
20200029 JOB_CONTROL     HIB      8      110   0 00:00:00.58        86    195   
2020002A CONFIGURE       HIB      8       67   0 00:00:00.42       105    122   
2020002B NETACP          HIB     10     1497   0 00:00:37.36       365    266   
2020002C EVL             HIB      4     2768   0 00:00:43.87     43560     32  N
2020002D $NICONFIG_1026  HIB      5    18895   0 00:10:04.29       600    218  N
2020002E REMACP          HIB      9       66   0 00:00:00.38        76     39   

! small (?) problems now I cannot be seen
JC $ sho proc
%SYSTEM-W-NONEXPR, nonexistent process
JC $ mail
%SYSTEM-W-NONEXPR, nonexistent process
JC $ 
JC $ 
JC $ lo
%SYSTEM-W-NONEXPR, nonexistent process

! run the program to 'logout', test if invisable then exits from Exec mode
JC $ r switch

re .11

>    There is a variant of the Monster floating around called UISBUGLOA. It
>    uses the monster to make a picture of a cockroach walk across the
>    screen of a workstation every ten minutes. 
    

any chance the location of this UISBUGLOA program might be divulged??

- marty

    Re: UISBUGLOA:
    Grab UFP::UISBUGLOA.EXE and RUN it.
    (I'll let you figure out how to stop it short of a reboot; unless
    Jon wants to divulge the secret of how to kill it!)
    	-Rick

 How about a look at the sources? (for educational purposes)

    UISBUGLOA only works on a QVSS. It will *not* work on a GPX (it
    bypasses the windowing system and hacks the QVSS hardware). I don't
    know if it'll work on a VS2000, but I doubt it. The VS2000 isn't
    *quite* enough like a QVSS. 
    
    I'll think about posting the sources.
    
    	Jon

    re .10 etc
    
    I can understand why executing as a system subroutine would make
    doing things that assume process context difficult, but couldn't
    you simply queue an ast to any handy process, using the address of 
    your routine in npp you want executed?
    
    The only complication I can see is you'd have to make sure the pages
    in npp containing your code had appropriate protections for the
    access mode of your queued ast.
    
    Or am I missing something?

    Nope, you're not missing a thing. That's *precisely* what you have to
    do -- hijack a suitable process. The problem come in deciding what a
    "suitable process" is, what mode you want to put the AST in (pool is
    ERKW, but you can't do some system services from some modes -- some
    won't work from KAST, some won't work from EAST or below (RMS
    especially), some (image activation springs to mind) require supervisor
    mode or outer. Also, dinking the page protection of pool without cause
    is definitely Bad Form. You can easily do horrible things to the
    system. 
    
    The real point I'm trying to make is that a fork "process" is not a
    process. You can't use any RTLs, and you can't do anything that's fun,
    at least not without a lot of work. You have no decent debugger, and
    you have to be very, very careful, because one false move brings the
    system down around your ears. 

    	Jon

    re .16
    
    Is there any chance a program like this will be (re)written for
    the QDSS?

.12> < Note 383.12 by IOSG::BAILEY "Been down so long;looks like up to me" >
.12> 
.12> >    *real* neat hack to make you truly invisible, even to SHOW SYSTEM. It
.12> >    tried to look for unused space off the end of the PCB vector and
.12> >    relocate your PCB index to an unused cell. It's a marvelous hack, but
.12> >    really dangerous. 
.12> 
.12> Thats almost exactly what I do !!!, I test the PCB vector at index offset
.12> 1  (farthest from sch$gl_pcbvec) and if not in use then switch the pointer
.12> for my process and the empty (null) cell, build a new Ipid so
.12> everything works ok, then decrement sch$gl_maxpix, this is the 'counter'
.12> that controls how many processes to search for a show sys etc, so
.12> now I am 100% invisible (see below)

Any chance of posting this or mailing it to me just for laffs?

= Giles =

    Re: .2
>                                -< Set Proc/Priv=SHARE >-
>    
>      Sounds like more than just the terminals are set wrong.
>      How come people got into an account that had privileges like "SHARE"
>      in it? I realize customers don't always see things the same way
>      as internal DEC does but...
>
    Bill Landreth in his book 'Out of the Inner Circle' mentions a hack
    he used on vaxen some years ago to do privileged things from an
    unprivileged account - in particular, give himself SETPRV.
    
    He would request some simple task for which he had privilege,
    but while VMS went to check if he was allowed to perform it 
    he substituted a different command into the buffer.  When VMS had
    decided he could perform the original command it then performed
    the new command that had been substituted.
    
    Any ideas how he did this, or if it is still possible?
    
    Paul M.
    (Too busy to take the time to investigate this himself)
    

    Re: .-1
    
    Maby the buffer was in shared memory so he could have another process
    change the buffer while the first process (operating out of user
    mode) executes the call.

    re: .20: Sounds like utter BS to me. VMS doesn't check for required
    privs depending on a COMMAND; the image that the command invokes
    performs some function that needs the privs; you can't change the
    image code on the fly (^Y removes any privs it has). You can't get
    CMKRNL just because VMS thinks you typed "SHOW SYSTEM" when you typed
    "SET PROC/PRIV".... unless there is a very badly screwed up system
    manager..
    	-Rick

    .21 is indeed utter BS. Sounds like Mr Landreth was free-associating so
    as to put plausible-sounding stuff in his book to pad out the pages. 
    
    	Jon

Way, way back - maybe VMS V1, perhaps only in BLxx's before that - it was
possible to run a privileged image, CTRL/Y it, use DEPOSIT to change stuff,
then CONTINUE.  .A privileged image could, of course, protect itself by
intercepting CTRL/Y's - but not all did.  Nowadays, DCL provides the pro-
tection by strictly limiting what you can do at CTRL/Y state within a
privileged image.  Anything like DEPOSIT will cause the image to exit,
taking its privileges with it.
							-- Jerry

    	Since this is the hackers notes file ... It was a bit more recent
    than you remember. BL4 of VMS did not have privileged images.
    Non-privileged users could not log out, since that requires privileges,
    and even privileged users had to be careful not to turn them off.
    
    	Vms V1 had privileged images, but I think you could use DEPOSIT
    anywhere. V2 I think you could still deposit on the supervisor mode
    stack after CTRL/Y and do nasty things. (DCL can write to supervisor
    mode pages, right?). I have not heard of anything in quite that area
    since V3, so the above information is too stale to be of any use to a
    hacker.