By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,365 Members | 3,095 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,365 IT Pros & Developers. It's quick & easy.

protecting my script from being shared

P: n/a
Hi guys!
Anyone know a way so that users purchasing
my scripts would not be able to share them
with other people ?

Yang
Jul 17 '05 #1
Share this Question
Share on Google+
24 Replies


P: n/a
Yang Li Ke wrote:
Hi guys!
Anyone know a way so that users purchasing
my scripts would not be able to share them
with other people ?


I don't know that it would defeat sharing completely, but there are
products like Zend Safeguard Suite
(http://www.zend.com/store/products/z...uard-suite.php) that could
help.

--
Justin Koivisto - sp**@koivi.com
PHP POSTERS: Please use comp.lang.php for PHP related questions,
alt.php* groups are not recommended.

Jul 17 '05 #2

P: n/a
There are several way,

at the top of the scripts, you can do a server check to see if it is running
on the server you specify, and you can kinda encode it so it is not
readable.

if its not readable, they can not modify the check you placed in it.

you can use the encoder at http:www.gzentools.com to encode the script so
its not readable.
--
Mike Bradley
http://www.gzentools.com -- free online php tools
"Yang Li Ke" <ya******@sympatico.ca> wrote in message
news:v4*******************@news20.bellglobal.com.. .
Hi guys!
Anyone know a way so that users purchasing
my scripts would not be able to share them
with other people ?

Yang

Jul 17 '05 #3

P: n/a
CountScubula wrote:
There are several way,

at the top of the scripts, you can do a server check to see if it is running
on the server you specify, and you can kinda encode it so it is not
readable.

if its not readable, they can not modify the check you placed in it.

you can use the encoder at http:www.gzentools.com to encode the script so
its not readable.


That's not an encoder, that's an obfuscator. Run it through a code
beautifier, and you have manageable code quite quickly...

--
Justin Koivisto - sp**@koivi.com
PHP POSTERS: Please use comp.lang.php for PHP related questions,
alt.php* groups are not recommended.

Jul 17 '05 #4

P: n/a
It clearly states those facts on the site, and if you want to take that
aproach, there is no true encoder, if you have to use a decoder, then you
can just hack the decoder to spit out the source.

I never said it was more than I claim it to be.

--
Mike Bradley
http://www.gzentools.com -- free online php tools
"Justin Koivisto" <sp**@koivi.com> wrote in message
news:fZ****************@news7.onvoy.net...
CountScubula wrote:
There are several way,

at the top of the scripts, you can do a server check to see if it is running on the server you specify, and you can kinda encode it so it is not
readable.

if its not readable, they can not modify the check you placed in it.

you can use the encoder at http:www.gzentools.com to encode the script so its not readable.


That's not an encoder, that's an obfuscator. Run it through a code
beautifier, and you have manageable code quite quickly...

--
Justin Koivisto - sp**@koivi.com
PHP POSTERS: Please use comp.lang.php for PHP related questions,
alt.php* groups are not recommended.

Jul 17 '05 #5

P: n/a
CountScubula wrote:
It clearly states those facts on the site, and if you want to take that
aproach, there is no true encoder, if you have to use a decoder, then you
can just hack the decoder to spit out the source.


Wrong. The Zend Encoder produced an encrypted bytecode that can't be
translated back to the sourcecode. The only requirement is that the
server must run the (free) Zend Optimizer so it can execute the bytecode
without the PHP source.

AFAIK the ionCube Encoder does pretty much the same.

Jochen

Jul 17 '05 #6

P: n/a
> CountScubula wrote:
It clearly states those facts on the site, and if you want to take that
aproach, there is no true encoder, if you have to use a decoder, then you can just hack the decoder to spit out the source.


Wrong. The Zend Encoder produced an encrypted bytecode that can't be
translated back to the sourcecode. The only requirement is that the
server must run the (free) Zend Optimizer so it can execute the bytecode
without the PHP source.

AFAIK the ionCube Encoder does pretty much the same.

Jochen


BTW, if you look at the text you quoted me on, I state: "hack the decoder",
I didnt say you can just regain the source.

Even if it used a whoping DES/SUPER_DUPER/200KB/ENCRYPTION, it still has to
be decrypted to execute.

Well, what do I know?
--
Mike Bradley
http://www.gzentools.com -- free online php tools
"Jochen Buennagel" <za*********@buennagel.com> wrote in message
news:bu*************@news.t-online.com...
Jul 17 '05 #7

P: n/a
"Jochen Buennagel" <za*********@buennagel.com> wrote in message
news:bu*************@news.t-online.com...
CountScubula wrote:
It clearly states those facts on the site, and if you want to take that
aproach, there is no true encoder, if you have to use a decoder, then you can just hack the decoder to spit out the source.


Wrong. The Zend Encoder produced an encrypted bytecode that can't be
translated back to the sourcecode. The only requirement is that the
server must run the (free) Zend Optimizer so it can execute the bytecode
without the PHP source.

AFAIK the ionCube Encoder does pretty much the same.

Jochen

I still hold my position,

Does the Zend decoder require PHP? Or is the Zend decoder passing the
bytecode to PHP? Hmm how does the Zend Decoder know what modules I have
compiled in?

Hmm you said byte code? So then this is passed to PHP? so, PHP understands
source and Bytecode? NO!

Next thing you are going to tell me is the Commodore 64, by storing its
source as bytecode can not be decoded? Gee I wrote one of the first
disasseblers for the C64 when I was 10 years old.

I say this boldy, and I know I will be attacked/flames for it, but if at any
stage it is passed to the cpu, either by byte code, compiled, or assembled,
it can be disassembled to source code.

Every compiler has a uniq way of generating code from the original, and if
you write a compiler, you can decompile as well. Same goes for the Zend
Encoder.

Now, I am not saying the Zend Encoder does not earn its merit, by no means,
it is actualy a wonderfull product.

Just understand there is no true encoding, unless you come up with your own
interpeter/execution app.

Again, I speak boldly, and I know this. As my site states, any good
programmer can decode to the source, that is from one of my encoders (after
all, their free).

Without trying to start a rather long debate about encoding/compiling,
understand that if a CPU can read it, so can a human, therefore it can be
brought back to source.

--
Mike Bradley
http://www.gzentools.com -- free online php tools
Jul 17 '05 #8

P: n/a
Regarding this well-known quote, often attributed to Yang Li Ke's famous
"Wed, 14 Jan 2004 10:17:36 -0500" speech:
Hi guys!
Anyone know a way so that users purchasing
my scripts would not be able to share them
with other people ?

Yang


Well, I had an idea, but don't be mistaken... it's a really horrible idea.

Have the code "call home" to your site for some sort of key (then obfuscate
the code, see other messages), or call home for a piece of its own code
(serve PHP-as-text snippets and include() them).

(It's a really bad idea for everyone involved, but, hey, maybe someone
else'll think of something better spun off from it.)

--
-- Rudy Fleminger
-- sp@mmers.and.evil.ones.will.bow-down-to.us
(put "Hey!" in the Subject line for priority processing!)
-- http://www.pixelsaredead.com
Jul 17 '05 #9

P: n/a
CountScubula wrote:
Hmm you said byte code? So then this is passed to PHP? so, PHP understands
source and Bytecode? NO!
No, that's why I said the Zend Encoder requires Zend Optimizer on the
Server. This is responsible for executing the bytecode.
Next thing you are going to tell me is the Commodore 64, by storing its
source as bytecode can not be decoded? Gee I wrote one of the first
disasseblers for the C64 when I was 10 years old.
I'm not worthy! I'm not worthy! ;-)
I say this boldy, and I know I will be attacked/flames for it, but if at any
stage it is passed to the cpu, either by byte code, compiled, or assembled,
it can be disassembled to source code. .... Again, I speak boldly, and I know this. As my site states, any good
programmer can decode to the source, that is from one of my encoders
(after all, their free). .... Without trying to start a rather long debate about encoding/compiling,
understand that if a CPU can read it, so can a human, therefore it can be
brought back to source.


It can be disassembled to something which might be editable, but it is
still far from the "source" code that was written by the programmer.
I've used disassemblers and decompilers myself, and digging through the
output of those is orders of magnitude more work than working with the
original source.

Jochen

Jul 17 '05 #10

P: n/a
I was thinking of this way too but cant seem to figure how to do it :(

--
"FLEB" <so*********@mmers.and.evil.ones.will.bow-down-to.us> wrote in
message news:17******************************@40tude.net.. .
Regarding this well-known quote, often attributed to Yang Li Ke's famous
"Wed, 14 Jan 2004 10:17:36 -0500" speech:
Hi guys!
Anyone know a way so that users purchasing
my scripts would not be able to share them
with other people ?

Yang
Well, I had an idea, but don't be mistaken... it's a really horrible idea.

Have the code "call home" to your site for some sort of key (then

obfuscate the code, see other messages), or call home for a piece of its own code
(serve PHP-as-text snippets and include() them).

(It's a really bad idea for everyone involved, but, hey, maybe someone
else'll think of something better spun off from it.)

--
-- Rudy Fleminger
-- sp@mmers.and.evil.ones.will.bow-down-to.us
(put "Hey!" in the Subject line for priority processing!)
-- http://www.pixelsaredead.com

Jul 17 '05 #11

P: n/a
Yang Li Ke wrote:
I was thinking of this way too but cant seem to figure how to do it :(


You could store a certain piece in a database, then allow access to the
databse from a single user/pass combo from a certain IP only. Also,
you'd want to have some kind of hash to match with that has something to
do with the $_SERVER['HTTP_HOST'] so that it differentiates between that
particular site and just a domain on that machine.

Again, not really a good way to go about it...

--
Justin Koivisto - sp**@koivi.com
PHP POSTERS: Please use comp.lang.php for PHP related questions,
alt.php* groups are not recommended.

Jul 17 '05 #12

P: n/a
Ok, We both make valid arguments, and it does look like you do understand
what I am trying to say, sorry if I layed in really hard.

--
Mike Bradley
http://www.gzentools.com -- free online php tools
Jul 17 '05 #13

P: n/a
"FLEB" <so*********@mmers.and.evil.ones.will.bow-down-to.us> wrote in
message news:17******************************@40tude.net.. .
Well, I had an idea, but don't be mistaken... it's a really horrible idea.

Have the code "call home" to your site for some sort of key (then obfuscate the code, see other messages), or call home for a piece of its own code
(serve PHP-as-text snippets and include() them).

(It's a really bad idea for everyone involved, but, hey, maybe someone
else'll think of something better spun off from it.)

--
-- Rudy Fleminger
-- sp@mmers.and.evil.ones.will.bow-down-to.us
(put "Hey!" in the Subject line for priority processing!)
-- http://www.pixelsaredead.com


I have done this sorta hacky type of thing in the past (heck it is still in
use for one of my projects)

I didn't want the traffic comming to my servers, so I set up a couple of
free sites that have php on them,
and put all the host names in an array, and had it run through then untill
it got to connect to one of them. This was incase one went down or
something.

Then the client code would send a magic request http://
freesite.com/?magic=_MAGIC_STRING_

the string would contain the client name and the app name and a random
string to use to encode the return response.

the free site would then decode the magic string into the three parts, look
up in a simple text file the client/app and see if it was still valid, if it
was it would simply encode "OK" with the random string that was passed in
the request.

This way, if someone ever sniffed the packets, they would notice the return
response is always different.
well, just my little hacky hack and 2 cents

--
Mike Bradley
http://www.gzentools.com -- free online php tools
Jul 17 '05 #14

P: n/a
Yang Li wrote:

Anyone know a way so that users purchasing
my scripts would not be able to share them
with other people ?


It is possible, but it is evil. Obfuscating code is evil. EVIL.

bblackmoor
2004-01-15

Jul 17 '05 #15

P: n/a
> Hi guys!
Anyone know a way so that users purchasing
my scripts would not be able to share them
with other people ?

Yang


Uh, you could try writing them in C with a php wrapper?
--
Mike Bradley
http://www.gzentools.com -- free online php tools
"Yang Li Ke" <ya******@sympatico.ca> wrote in message
news:v4*******************@news20.bellglobal.com.. .
Jul 17 '05 #16

P: n/a

"Brandon Blackmoor" <bb********@spamcop.net> wrote in message
news:bu************@ID-97660.news.uni-berlin.de...
Yang Li wrote:

Anyone know a way so that users purchasing
my scripts would not be able to share them
with other people ?
It is possible, but it is evil. Obfuscating code is evil. EVIL.


How can protecting your copyright be evil?

Tony Marston
http://www.tonymarston.net
bblackmoor
2004-01-15

Jul 17 '05 #17

P: n/a
Tony Marston wrote:
"Brandon Blackmoor" <bb********@spamcop.net> wrote in message
news:bu************@ID-97660.news.uni-berlin.de...
Yang Li wrote:
Anyone know a way so that users purchasing
my scripts would not be able to share them
with other people ?


It is possible, but it is evil. Obfuscating code is evil. EVIL.

How can protecting your copyright be evil?


Who said protecting your copyright was evil?

Brandon Blackmoor -> "Obfuscating code is evil"

Jul 17 '05 #18

P: n/a

"Peter Hickman" <pe***@semantico.com> wrote in message
news:40***********************@news.easynet.co.uk. ..
Tony Marston wrote:
"Brandon Blackmoor" <bb********@spamcop.net> wrote in message
news:bu************@ID-97660.news.uni-berlin.de...
Yang Li wrote:

Anyone know a way so that users purchasing
my scripts would not be able to share them
with other people ?

It is possible, but it is evil. Obfuscating code is evil. EVIL.

How can protecting your copyright be evil?


Who said protecting your copyright was evil?


Obfuscating your code is an attempt to make it unusable if anybody attempts
to copy it, and it also makes it difficult for unauthorised people to amend
it. Thus if people cannot use it or amend it without the proper authority
then you are protecting your copyright. Or are we talking at cross purposes
here?

Tony Marston
Brandon Blackmoor -> "Obfuscating code is evil"

Jul 17 '05 #19

P: n/a
Tony Marston wrote:
"Brandon Blackmoor" wrote:

Obfuscating code is evil.


How can protecting your copyright be evil?


"I scatter broken glass on the sidewalk in front of my home. I'm just
protecting my home! How can that be evil?"

bblackmoor
2004-01-16

Jul 17 '05 #20

P: n/a
"Brandon Blackmoor" <bb********@spamcop.net> wrote in message
news:bu************@ID-97660.news.uni-berlin.de...
Tony Marston wrote:
"Brandon Blackmoor" wrote:

Obfuscating code is evil.


How can protecting your copyright be evil?


"I scatter broken glass on the sidewalk in front of my home. I'm just
protecting my home! How can that be evil?"

bblackmoor
2004-01-16


This is evil becouse it affects those outside of your home. Keep the broken
glass inside your fence, and we would all be happier.

So, we are to do what ever we want with our own scripts, as long as it stays
inside.

--
Mike Bradley
http://www.gzentools.com -- free online php tools
Jul 17 '05 #21

P: n/a
CountScubula wrote:

So, we are to do what ever we want with our own scripts,
as long as it stays inside.


I agree completely. If some pathetic cretin wants to obfuscate code that
no one else ever sees or uses, that is completely acceptable. It's
preferable, even.

bblackmoor
2004-01-17

Jul 17 '05 #22

P: n/a
Brandon Blackmoor wrote:
I agree completely. If some pathetic cretin wants to obfuscate code that
no one else ever sees or uses, that is completely acceptable. It's
preferable, even.


I recently worked on a project that would have benefited hugely from
code obfuscation. The reason: If the client ever has someone
knowledgeable look at the code, they'll probably sue the developers.

The more I work on open source and commercial projects, the more certain
I am that the quality of the code in open source software is several
orders of magnitude higher than in the commercial world, simply because
the developers know that others will look at the code and judge them by
that, not just by the functionality of the software.

Jochen

Jul 17 '05 #23

P: n/a
"CountScubula" <me@scantek.hotmail.com> wrote in message news:<Hm****************@newssvr29.news.prodigy.co m>...
"Jochen Buennagel" <za*********@buennagel.com> wrote in message
news:bu*************@news.t-online.com...
CountScubula wrote:
It clearly states those facts on the site, and if you want to take that
aproach, there is no true encoder, if you have to use a decoder, then you can just hack the decoder to spit out the source.
Wrong. The Zend Encoder produced an encrypted bytecode that can't be
translated back to the sourcecode. The only requirement is that the
server must run the (free) Zend Optimizer so it can execute the bytecode
without the PHP source.

AFAIK the ionCube Encoder does pretty much the same.


Correct, and furthermore, both Zend Optimiser and the ionCube Loader
contain modified execution engines that execute the compiled code
*inside* their Loaders, and not in the OpenSource PHP engine. As an
example of one complication, ZO uses new opcodes that are not part of
the published OpenSource engine.
Hmm you said byte code? So then this is passed to PHP? so, PHP understands
source and Bytecode? NO!
The restored code is not passed onto PHP, but PHP does understand
source and compiled bytecodes of non-encoded source. The actual
complexities and implementation details go far beyond that of trivial
systems and most peoples expectations.
Just understand there is no true encoding, unless you come up with your own
interpeter/execution app.
There is true encoding, even in the trivial systems, but the point to
understand is that they come with decoding as well. The encoding
systems may be for all intents and purposes 100% secure, but this is
of no consequence if the decoding system is flawed. Conveniently most
PHP encoding tools fail to say how insecure their decoding system is.

The decoding module is the killer for most encoding systems for PHP
other than ionCube and Zend. If we take systems such as codelock, a
simple one line change to the compile_string function in the PHP
engine (just put in a call to puts()) and out pops the restored source
of encoded files. The same goes for files encoded by several other
systems. Whilst no encoding system is 100% immune to the potential for
compromise, compiled code systems offer vastly better protection than
source based encoding that can be undone with a 2 minute edit and
recompile of the PHP sources.
Without trying to start a rather long debate about encoding/compiling,
understand that if a CPU can read it, so can a human, therefore it can be
brought back to source.


Depending on the virtual machine this may be easy, as with Java, or
hard. Techniques such as self-modifying code can substantially
complicate this effort, and reproducing accurate reconstructions of
data structures can require knowledge of the compiler used, and still
be difficult. Instruction reordering and other optimisation techniques
can also complicate matters. Whilst fragments of code can be restored,
producing complete reconstructions and usable/useful code can be
substantially non-trivial and ultimately impossible despite early
perceived progress.

n.
Jul 17 '05 #24

P: n/a

"Jochen Buennagel" <za*********@buennagel.com> wrote in message
news:bu*************@news.t-online.com...
CountScubula wrote:
It clearly states those facts on the site, and if you want to take that
aproach, there is no true encoder, if you have to use a decoder, then you can just hack the decoder to spit out the source.


Wrong. The Zend Encoder produced an encrypted bytecode that can't be
translated back to the sourcecode. The only requirement is that the
server must run the (free) Zend Optimizer so it can execute the bytecode
without the PHP source.


Source code obfuscation (stripping comments and whitespace,
replacing names by nonsense names) isn't "encoding" either, in the sense
that
there isn't any mechanical means to regenerate the original source.
Yes, you do end up with "source code" but it is pretty much unreadable.
See
http://www.semdesigns.com/Products/O...onExample.html

And you can't always insist that your customers install other components,
such as the Zend optimizer.

--
Ira D. Baxter, Ph.D., CTO 512-250-1018
Semantic Designs, Inc. www.semdesigns.com


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Jul 17 '05 #25

This discussion thread is closed

Replies have been disabled for this discussion.