SUPERZAP (Re: What level of computer is needed for a computer
Heinz W. Wiggeshoff
References: <393c...@news.sierratel.com> <8hjijl$5...@nnrp4.farm.idt.net> <393D597C...@fspdc.uchicago.edu> <slrn8jqthl.eit.TheCe...@localhost.localdomain> <8hlg48$1ilu$2...@ausnews.austin.ibm.com> <slrn8jspdi....@thebrain.conmicro.cx> <8hlqcs$qc2$1...@ausnews.austin.ibm.com> <slrn8jsvlf....@thebrain.conmicro.cx> <8hm15j$jte$1...@ausnews.austin.ibm.com> <8hn4fp$qgr$1...@freenet9.carleton.ca> <uem684...@mail.adcomsys.net> <jsaum-09060...@192.168.4.5>
Organization: The National Capital FreeNet
Jim Saum (js...@world.std.com) writes:
>
> (OT-comment in passsing.) Don Ludlow was also notable as the author of
> the original 1969 SUPERZAP program (a utility program for patching
> executables) that's familiar to many who've worked on IBM mainframes.
Only if one was a systems programmer. I'm guessing most shops and all
service bureaus Fort Knoxed that program. Perhaps D.L. may be persuaded
to reveal all now.
That program was a step up from 'patching' object decks of assembler or
Cobol programs. In hindsight, that's as unbelievable as desk-checking
before submission is today.
Jim Saum
(Heinz W. Wiggeshoff) wrote:
>Jim Saum (js...@world.std.com) writes:
>>
>> (OT-comment in passsing.) Don Ludlow was also notable as the author of
>> the original 1969 SUPERZAP program (a utility program for patching
>> executables) that's familiar to many who've worked on IBM mainframes.
>
> Only if one was a systems programmer. I'm guessing most shops and all
> service bureaus Fort Knoxed that program. ...
OS/360 was so wide-open that attempts to improve security were often
wishful thinking. But in MVS with access-control software (e.g., RACF,
ACF2), a shop can control who has write access to anything. Yet even
in these very controlled environments, I've had arguments with IT
security auditors about the dangers of ZAP. Some auditors require that
computer installations remove the program or control access to it, as
if the program itself is the security loophole. I used to point out
that write access to the load module (executable program) datatsets
being zapped constitutes the vulnerability, not the ZAP program which
does the writing. Yet when these same auditors confront a Unix system,
they don't try to ban Emacs out of worry that someone will edit an
executable; they control write access to the executable file (or its
directory). Evidently comprehension of system security concepts is not
always portable across platforms.
From MVS on, ZAP has been an "authorized" program, but it only needs
this special status in order to patch VTOCs (disk directories). The
load module-patching capability of ZAP does not require any special
authorization or super-user status. I once contemplated building a
ZAP-emulator, written entirely in PL/I or COBOL, just to prove this.
Presumably after seeing such a demonstration, the auditors would have
wanted access to those languages controlled, too.
But I guess this is too recent to be appropriate for a.f.c.
> ... Perhaps D.L. may be persuaded
> to reveal all now.
I have the source code of the original SUPERZAP in hardcopy. Like all
IBM-distributed software of that era, it was open-source.
- Jim Saum
Jay Maynard
>Some auditors require that
>computer installations remove the program or control access to it, as
>if the program itself is the security loophole.
I had an auditor try to do that to me once. After I pointed out that it was
an integral part of IBM's maintenance process for the OS (SMP calls it,
after all), he went away.
>I have the source code of the original SUPERZAP in hardcopy. Like all
>IBM-distributed software of that era, it was open-source.
Scan! Scan!
Pete Lamasney
> [...snip...]
> OS/360 was so wide-open that attempts to improve security were often
> wishful thinking.
There was a commercial product called DAS (Data Access Security), which
replaced the standard Password SVC. At Open time, instead of asking the
console operator for the password, it would assemble the password from
components of the JCL. Not a commercial success.
> But in MVS with access-control software (e.g., RACF,
> ACF2), a shop can control who has write access to anything.
Defining and determining "who" under MVS (and predecessors) is an
interesting exercise!
Pete
Steve Myers
There are major issues, other than security/integrity, that can make an
auditor nervous.
- All too often, the source update that emulates the S/ZAP update, is not
made, and causes problems downstream. Now, when I say emulate, I mean it.
Especially if a patch area is involved, the source update has little to
do with the S/ZAP update.
- Coding an S/ZAP update is not easy. The programmer has to be very
knowledgable about Assembler, and very careful. YOU try doing base
displacement arithmetic. The error rate is very high, nuch higher than
doing a source update. There have been programs to automate this -- and
they help, but it just reduces the error rate a little.
One issue about being authorized to do a VTOC update that I do not
understand is this is a data access issue, and it should be controlled
through the security system. For example, in RACF, the VTOC resource
should be VTOC.Vvolser (or something similar) and standard RACF access
controls should be used. This authorization issue should be removed, and
RACF controls should be used. This would allow system programmers, for
example, to update their packs, but keep them away from production data
packs. Of course, if a production pack gets screwed up enough to require
S/ZAP to fix it, it's the System Programmer that's going to fix it!
-- Steve Nyers
Jay Maynard
>Of course, if a production pack gets screwed up enough to require
>S/ZAP to fix it, it's the System Programmer that's going to fix it!
This brings up what I feel is an underappreciated point among DP auditors
and management: At some point, you have to trust SOMEONE with total access
to the system, or else you'll run into problem areas that you cannot fix,
and one day, the system will be hard down and possibly unrecoverable without
it. You *CANNOT* assume that you can grant access when needed; sometimes,
the access granting mechanism itself is what's broken, and if you need it
then, you're sunk.
Steve Myers
userid has RACF "special", which means I can fiddle with RACF functions
to my heart's content.
I quite deliberately do not normally have my userid set to "operations".
"Operations" is the RACF authority intended for storage managers: the
userids that do volume image dumps and otherwise manage data sets. It is
too much, and I do not need it for my day to day functioning. Generally,
if a user data set is involved that I cannot get to, I request the user
asking me to look at it to let me look at it with that user's ID. This
does not happen often: too many profiles have UACC read. UACC is RACF
speak for the default access if no other rule provides ir denies data set
access.
If I need operations, I will grant it to myself. I do this very
infrequently; the last time was to purge out some tapes from the tape
management catalog, and I needed operations so CA-1 would let me do it.
That was several months ago.
But as soon as I finished, operations went away.
Only very, very seldom does RACF fail to the point where you can't put
humpty back together. Most shops will work use shared DASD and work from
another RACF database using a test systen when that happens.
-- Steve Myers
Dav Vandenbroucke
>
> (OT-comment in passsing.) Don Ludlow was also notable as the author of
> the original 1969 SUPERZAP program (a utility program for patching
> executables) that's familiar to many who've worked on IBM mainframes.
Interesting. Wasn't superzap the name of a multiple utility program
for CP/M?
Dav Vandenbroucke
dav_and_france...@compuserve.com
gla...@glass2.lexington.ibm.com
>On Fri, 09 Jun 2000 17:03:42 GMT, nos...@nowhere.com (Steve
>Myers) wrote:
>
>>All that has been said about Superzap is true.
>>- Coding an S/ZAP update is not easy. The programmer has to be very
>>knowledgable about Assembler, and very careful. YOU try doing base
>>displacement arithmetic. The error rate is very high, nuch higher than
>>doing a source update. There have been programs to automate this -- and
>>they help, but it just reduces the error rate a little.
>
>were of the form:
>
>NAME module
>VER addr bytes
>REP addr bytes
>
>where bytes may have been limited to 4 or 1-4 range
>and were normally applied to the load modules or text decks
>(object modules).
>
>So you developed the patch by mentally disassembling the module
>to find the patch location, mentally assembled the new
>instructions, overtyped the module in a hex editor (SPF or
>XEDIT), wrote down the address, old and new word contents, and
>saved the patched module.
>Next you converted the written info to SZ input, ran SZ on the
>original module, getting a zapped module.
>Lastly, you compared the two modified output decks to make sure
>you got the same results.
>
>[snip]
>>-- Steve Nyers
>
>Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
>--
>Brian_...@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
> use address above to reply
No, there's no limitation on the number of bytes, as a sample superzap
card deck I have shows:
NAME xxxxxxxx yyyyyyy
VER 0000 E2D3C4D4E5E2E24BC1E4E3C8D3C9C240
VER 0010 40404040404040404040404040404040
VER 0020 4040404040404040404040404040
REP 0000 E4E2C5D94BD9C5E2D3C9C24040404040
REP 0020 4040404040404040404040404040
We also had/have disassemblers that can be used to disassemble the
load module, but it's a real pain to do it that way. It's much
easier to use a listing to determine the code and offsets.
I don't remember ever modifying a module with a hex editor. I always
went directly to the superzap step, possibly disassembling the zapped
module to compare it with what I had zapped. But, usually, I just ran
the module under test and verified the code that way.
I used to average about one zap a week, and was quite good at it at one
time. It's not easy, and it's not for everyone, but it does have a certain
appeal. I found that I was actually capable of writing in machine code.
Dave
P.S. Standard Disclaimer: I work for them, but I don't speak for them.
j...@seasip.demon.co.uk
>
>Interesting. Wasn't superzap the name of a multiple utility program
>for CP/M?
SUPERZAP.COM was a full-screen disc sector editor for CP/M.
It was usually spoken highly of, but I tended to use the command-line
editor DU90.COM or its predecessors instead.
Steve Garwood
official IMASPZAP but the earlier tool)....
Steve Garwood
end....
I actually use superzap to rebuild the critical disk control blocks for a
JES3 system in the early days of MVS (a mod had overwritten it and there
were 1000 jobs in the system!!!)...luck thing we had a core dump from JES3
(a common happening) from an hour or so before ... the blocks were in the
dump ... what a weekend ... then it snowed on the way home (this was in
1977-1978),.,,,
Jim Saum
Garwood <sterling...@worldnet.att.net> wrote:
>Ok now ... what was the last line on every Superzap printout? (not the
>official IMASPZAP but the earlier tool)....
SUPERZAP END - CHOW (CIAO)
- Jim Saum