×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Hello,
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.