Someone suggested (now I can't find the original message) that you could place another program higher-up in the library list to circumvent the security routines, and that's true. But even if a program hard-codes the library name (instead of *LBIL) you could easily replace the security service program with one of your own, and bypass security that way.

You could even rename the existing srvpgm, put your own code in it's place, and have your code call the original one. Thus, making the problem very hard to detect. (Basically, you've just written a Trojan) Since the parameters would be going through your program, you could inspect them and reverse-engineer the process to some degree.

Walden suggests that this could also be done with a *MODULE:

True. But can't I just do an updpgm with a new module to replace yours?
I guess the argument is that I'd need to know the signature which is
easier to know for a srvpgm than an embedded module.

It's true that you could potentially do the same thing this way -- the problem is that it's very difficult to find out what the exports of the original module were. (Assuming that the *MODULE object wasn't actually furnished)

You'd have to know exactly which routines were exported from the module in order to duplicate them in your own code.

This is easy with a SRVPGM, since you can see the routine names with the DSPSRVPGM command. However, it's not so easy with bind-by-copy, since the names aren't visible unless you can inspect the *MODULE object.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].