Conference noted::hackers_v1

556.0. "Patching SUBMIT and ACCVIO" by COMICS::MEGARITY (To be is to be perceived) Fri Sep 18 1987 06:00

Hi,

A customer phoned in recently with an unusual problem. He had a group of users
on his system who, for various reasons, had been given CMKRNL privilege and a
few of those users had been using commands like SUBMIT/USER=SYSTEM a little too
often for his liking. His solution to the problem was to patch SUBMIT.EXE so
that it sent a message to OPCOM every time the qualifier /USER was used.  Not
the best solution to this management problem, but anyway. 

Now for the problem.  He decided to use the read/write patch area in SUBMIT to
hold his extra code and data, which from ANAL/IMAGE starts at address 3E0B and
was supposedly writeable. When the patched image was used, it ACCVIOed at
PC=3E17 when accessing address 3E14 with reason mask=04. Investigating further,
we've found from ANAL/IMAGE that the ISD$V_WRT bit is set to 0 in the ISD for
the PSECT starting at page 3E00 which we think is the same one which contains
the read/write patch area. 

My questions are:-

	- Is the ACCVIO really due to the fact that ISD$V_WRT bit is set
	  to 0 for that PSECT, effectively making it non-writeable ?

	- If not, what is the reason ?

	- If so, is this done deliberately to stop this image being
	  patched ?

A cut-down version of the patch command file is attached, as is the
ACCVIO output and part of the ANAL/IMAGE output.

BTW, we're talking 4.5 and there is absolutely no support problem here,
as the customer realises that he shouldn't be patching our images. He
is just curious about this and more to the point, so am I.
He got around the 'problem' by allocating some space on the user stack
to hold his writeable data.

Thanks in advance for any replies.


Ian M
Here's his patch commands:

SUBMIT.EXE
! vms 4.5
check not eco 99
set eco 99
verify/inst 0177a='MOVAB W^208, R7'
define start_addr=208
define contin=177f
set patch/init=1ed 3e0b
deposit/inst/patch 3e13
'fred:	.long	0'
'kob:	movl	#1,	fred'
'	jmp	l^contin'
exit
replace/inst 0177A='MOVAB W^208, r7'
'jmp	l^kob'
exit
update
exit

Here's part of the output from ANAL/IMAGE :-

	Patch Information

		DEC eco levels   1- 98: %X'00000001', %X'00000000', %X'00000000'
		user eco levels 99-132: %X'00000000'
		read/write patch area address: %X'00003E0B', length: 501
		read-only patch area address:  %X'00000000', length: 0
		patch command text VBN: 32
		last patch date/time: 22-DEC-1986 15:05:37.52


		5)  image section descriptor (16 bytes)
			page count: 1
			base virtual address: %X'00003E00' (P0 space)
			page fault cluster size: default
			ISD flags:
				(0)  ISD$V_GBL        0
				(1)  ISD$V_CRF        0
				(2)  ISD$V_DZRO       0
>>>				(3)  ISD$V_WRT        0
				(7)  ISD$V_LASTCLU    1
				(8)  ISD$V_COPYALWAY  0
				(9)  ISD$V_BASED      0
				(10) ISD$V_FIXUPVEC   0
				(17) ISD$V_VECTOR     0
				(18) ISD$V_PROTECT    0
			section type: ISD$K_NORMAL
			base VBN: 31

Here's the ACCVIO output :-

%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=00003E13, PC=00003E1B, PSL=03C00000

  Improperly handled condition, image exit forced.

	Signal arguments	      Stack contents

	Number = 00000005		 7FFE6440
	Name   = 0000000C		 7FFE6300
		 00000004		 0000000F
		 00003E13		 7FF8F73B
		 00003E1B		 7FFE640C
		 03C00000		 7FFE64E0
					 00000000
					 7FF84828
					 7FFED052
					 7FFED25A

	Register dump

	R0 = 7FFE6440  R1 = 7FFE6300  R2 = 0000000F  R3 = 7FF8F73B
	R4 = 7FFE640C  R5 = 7FFE64E0  R6 = 00000000  R7 = 7FF84828
	R8 = 7FFED052  R9 = 7FFED25A  R10= 7FFEDDD4  R11= 7FFE33DC
	AP = 7FF22318  FP = 7FF222D8  SP = 7FF22354  PC = 00003E1B
	PSL= 03C00000
    

    Code sections are normally set nowrite. Putting code there will
    work fine.. putting writeable data there won't work. You will
    have to find somewhere else to put FRED. (Unless you want to patch
    the ISD for that section - yucch.)
    	-Rick

	So when ANAL/IMAGE tells us that

>		read/write patch area address: %X'00003E0B', length: 501

	it may be misleading us. Looks like the customer did the best thing
	by allocating some space on the user stack for his data.


	Anyway, thanks for the reply.

	Ian M