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
