Re: System Date - can it be 'intercepted' ?

[CRPence <CRPbottle@xxxxxxxxx>]

On 2/10/11 12:40 PM, Jim Wiant wrote:
> Funny though - that product needs OS/400 6.1.0 or higher. I'm on
> V5R4. I found another product that does so - but it will stop working
> at 6.1.0 *L* - apparently they changed something. It might be worth
> looking at. What I'd really like to then know is how they do it - I
> love writing that kind of stuff myself if possible.
>
> <<SNIP>>

  The implementation of various "intercept" are AFaIK all designed as a 
"Trojan Horse" of some system-date [language-specific and\or OS] SPI and 
system-date API.  As the OS intends to continually improve means of 
maintaining system integrity, various attempts to effect a Trojan Horse 
implementation may be defeated, thus the means to implement them must 
change.  In the distant past it was somewhat "easy" to intercept most 
invocations simply by an update to the System Entry Point Table [*SEPT], 
though at some point only in combination with an appropriately low 
QSECURITY setting allowing for lower integrity-enforcement requirements 
or possibly by just altering the program [on any system] to function in 
the "system domain", though eventually possibly only if altered on "the 
system" where the program was "installed" as a Trojan, given that a 
restore might either be failed [possibly only due to a system value 
setting] or because the program was required to either re-translate or 
be digitally signed.

  The MI400-L archive has a variety of information that should suffice 
to enable one [to learn how] to establish a Trojan Horse on the system 
where altered.  The first step is getting the TRCJOB results to 
determine the %date implementation, to determine what needs to be 
intercepted.

Regards, Chuck