HI, 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. 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. 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). 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. Thanks, Shai On Tue, Jun 9, 2009 at 9:48 PM, Timothy Sipples <e99...@jp.ibm.com> wrote: > I am not endorsing or recommending that vendors take extra steps to > obfuscate code, nor am I endorsing any particular products. However, that > said, I am answering the original poster's question directly. > > There are a number of such products. Each tends to be focused on a specific > programming language. Here are a few examples. > > 1. There are many obfuscators for Java. Just use Google or a comparable > search engine to find "Java source code protection" and you'll see a bunch > pop up. Most if not all of those should be entirely applicable to Java > deployments to z/OS and to Linux on System z. > > 2. There are also obfuscators for C/C++ which probably are highly relevant > to both z/OS and Linux on System z. Stunnix, for example, produces a > cross-platform obfuscator that turns original, maintainable C/C++ source > code into hard-to-maintain (but still compilable) C/C++ source code. There > are other companies that produce similar tools. > > 3. IBM's REXX Compiler does not *paticularly* obfuscate code, but > recipients of the compiled REXX code have to work slightly harder to > extract some kind of source. These compiled REXX programs can run using the > licensed library or the no charge Alternate Library for REXX, so they can > run on all z/OS machines. > > 4. For COBOL, Redvers offers an obfuscator: > > http://www.redversconsulting.com/cloaking_device.php > > 5. The Redvers obfuscator probably also works as an intermediate step with > the Rational Enterprise Generation Language (EGL) deployment choices to IBM > Language Environment, if you're working with EGL. (Although some would > argue that intermediate code is already obfuscated. :-)) > > - - - - - > Timothy Sipples > IBM Consulting Enterprise Software Architect > Based in Tokyo, Serving IBM Japan / Asia-Pacific > E-Mail: timothy.sipp...@us.ibm.com > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html