RE: XLS files scrambling

The incentive may be that using that system, you could handle the encrypted
stylesheets.

Of course, the fact that you couldn't handle the encrypted stylesheets
without such a system, might be a disincentive ever to use the stylesheets.

We'll always be able to keep secrets: but for some games, sharing your
stuff might be the price of playing.

Back on topic--!
Wendell

At 05:32 PM 6/23/00 -0400, you wrote:
>And make sure that you support that parser on all platforms, make it
>popular, make binaries available from a high bandwidth server, and keep up
>to date with the state of the art parsers so that there is incentive to use
>your parser.
>
>-----Original Message-----
>From: Paul Tchistopolskii [mailto:paul@xxxxxxx]
>Sent: Friday, June 23, 2000 3:27 PM
>To: xsl-list@xxxxxxxxxxxxxxxx
>Subject: Re: XLS files scrambling
>
>
>
>Hi, George.
>
>Long time ago I was used to work for one paranoid,
>who was thinking that if he encrypt the source code
>of some perl scripts - he benefit on a long run.
>He got that scrambling in 2-3 days.
>
>I think that the pattern of scrambling XSL, perl or
>whatever other interpreter is common and
>straightforward:
>
>1. Write propriatary 'crypt' utility  ( use DES-based
>encryption,  it is strong and  there are open sources
>hanging around ).
>
>2. crypt script.xsl >  script.xsl
>
>The produced ( scrambled ) script.xsl will have a
>magic signature in the first few bytes, or  e t.c.
>
>3. Find the place in perl ( XSL, whatever ) code
>which is loading the stylesheet. If the stylesheet
>starts with magic signature - decrypt it first.
>
> In case of XSL re-capturing SAX Eception
>could work - I mean - "if it is not XML - it is encrypted"
>
>4. To run hacked stylesheets - ship hacked
>interpreter.
>
>5. There are some interesting twists here.
>For example, with perl if was not straightforward,
>because there was more than one place that
>has to be 'closed'. Hacked interpreter written in
>java could also be decompiled e t.c.  e t.c.
>
>Pafranaoya has no limits
>
>Conclusion. If you want to hack XT, for example,
>to read  encrypted stylesheets - just write your
>own ( decrypting ) SAXParser ( similar to
>UxSpecialParser ) and  that's all you need.
>No code changes to XT.  The same could be
>done for any other 'reasonable'  XSLT Engine,
>which has no particular parser hardcoded, but
>allows usage of other SAXParsers.
>
>For detailes on UxSpecialParser - you can
>download Ux source code from  http://www.pault.com/Ux
>
>Rgds.Paul.
>
>
>----- Original Message -----
>From: George Prezerakos
>
>> Cmon you guys,
>>
>> I don't mean to start a new thread here but...
>>
>> We gotta separate between personal and corporate views. Of course I like
>open source
>source projects and freeware distribution (and I have actually developed
>free or low-cost
>s/w a lot of times).
>>
>> However, when working for a company and writing software for the company's
>clients you
>might (just might) be asked to encrypt some stuff. I haven't come across
>this situation
>yet but I posted my original question just in case.
>>
>> Think about it before starting to flame me once more :)
>>
>> Regards,
>>
>> George Prezerakos
>>
>
>
>
> XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>
>
> XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>
>

======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list