On Tue, 9 Jun 2009 22:27:27 -0700 shai hess <[email protected]> wrote:
:> I found two points which I can address to have some protection in assembler :>code. :> 1, Disable slip per - I investigate some zos structure and find out the :>structure which are use to :> describe the slip. Doesn't help if under VM, among other things. :> This is important because disable slip, which is not tracing your code :>is unacceptable. :> Also slip without instruction fetch are legal for your code as well to :>be able to debug problems :> in your code. :> I thing that the best solution if this is the case is to change the :>slip action from :> action=TRACE to action=IGNORE only if the slip action is trace :>(ACTION=TRACE) and the job name/asid is specify your job. :> is your job name/asid. Will only help against amateurs. :> 2. Disable debugging using software which use SVC for breaking points (for :>instruction tracing) - SVC can not be used if you are SRB or Some SVC types. :>The easy solution is to use MVS lock. :> SVC is also does not allowed in code which is locked (using setlock :>macro). :> I think that the best solution is to setlock in sensitive code range to :>disable tracing :> sensitive instructions which does not issue any SVC or long time :>instruction. Is it danger to use setlock if it is not needed?. Not at all if :>you will use setlock type=local for one time running sensitive code :>(Checking and comparing the encripted serial or other important code). As above. :>My question, if the way I see the solution is acceptable? :>BTW, if you like to see, example of code (for per, action=ignore) I consider :>to use to have some protection to my code, I can do it. Will not beat someone who is trying to do it. Not worth the problems that it may cause, as well as the disclosures that you will have to make. What will you tell to the client that had a hard failure do to you mucking around in undocumented control blocks - for something that has nothing at all to do with the functions of your product? -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
