obfuscating code

[Rajeev Prasad]

freinds,

what is the advice just for obfuscating code? platform is solaris.

ty.

[Lawrence Statton]

Don't.

[Paul Anderson]

Simple, step by step directions:

1. Obtain large gun.
2. Load with ammunition.
3. Fire squarely into foot.
4. Reload if necessary and repeat.



Sent from my iPhone

[Mike Dunaway]

If you have to ask, you're not good enough to obfuscate or maintain your
obfuscated code.

[Kevin Walzer]

Perl is self-obfuscating.

Sent from my iPhone

[Rajeev Prasad]

sorry, idea is dropped.




________________________________
From: Rajeev Prasad <rp.n...@yahoo.com>
To: perl list <begi...@perl.org>
Sent: Tuesday, February 12, 2013 11:01 AM
Subject: obfuscating code

[Jim Gibson]

I like the advice given in the Perl FAQ "How can I hide the source for my Perl program?", which says:

"Delete it."

See 'perldoc -q hide' for more details.

[Nitay Artenstein]

It's Perl. The obfuscation is built in.

[David Crouse]

That goes in my list of "best answers ever" ;)

[John SJ Anderson]

>> On Feb 12, 2013 7:05 PM, "Rajeev Prasad" <rp.n...@yahoo.com> wrote:
>>> what is the advice just for obfuscating code? platform is solaris.

I think you're getting the idea, at this point, that this is
considered a bad idea, regardless of what platform you're targeting.

You may have an actual issue, but unless you explain to us what you
thought you were going to achieve via obfuscating your code, we're not
going to be able to help with that.

Also, I'm a little disappointed in the "it's Perl, it's already
obfuscated" answers. If you think the Perl you're writing is
pre-obfuscated, you're doing it wrong. My Perl code is idiomatic, easy
to read and understand, and as clear, if not more so, than code
written in any other language. One of the common criticisms of Perl is
that it's a "write-only language". This is, frankly, bullshit -- but
having people on a list aimed at helping Perl beginners promote that
bullshit only makes it more odorous. Please stop.

thanks,
john.

[Michael Smith]

I don't know if he was speaking of making the code you can see hard to understand (like some sigs I've seen) or keeping others, online perhaps, from the seeing the code (like object code). You can of course "see" object code but you would have to be able to read machine code, in hex, and most don't bother.

Two very different things.

________________________________
From: Rajeev Prasad <rp.n...@yahoo.com>
To: perl list <begi...@perl.org>
Sent: Tuesday, February 12, 2013 11:01 AM
Subject: obfuscating code

[timothy adigun]

+1 John. I can't agree more.
>
> thanks,
> john.
>
> --
> To unsubscribe, e-mail: beginners-...@perl.org
> For additional commands, e-mail: beginne...@perl.org
> http://learn.perl.org/
>
>

[jbiskofski]

I see everyone is eager to judge this as a terrible idea, its the exact
same response Ive gotten to this question on mailing lists on IRC.

HOWEVER, I think this can be a valid concern. We are always talking about
how the best way to shine good light on Perl is writing cool stuff in it.

Well Ive actually gone out a built a company that does a HUGE LMS in Perl,
its used by over 300K students in Mexico ( www.algebraix.com ), and employs
18 people. I dont think its stupid of me to worry about someone getting
into my servers somehow and stealing the code. I have to think of the
people who work here and their job security, I also have to worry about my
competitors, I dont know how ethical they are or are not.

So yeah I think this questions should be given more thought and not just
discarded as immediate stupidity.

my $two_cents.

- Jose Biskofski

[Bob McConnell]

You cannot obfuscate the input to an interpreter. It has to be in a format that the interpreter will recognize, which necessarily means that people can also read it. If you really need to hide your source code, you have to switch to a compiled language with an actively optimizing compiler. Then only distribute the output from the compiler. Even then there may be de-compilers or disassemblers that can reconstruct much of your source in readable form.

Bob McConnell

[jbiskofski]

I understand that obfuscating code is not a real detriment to a seriously
motivated knowledgeable hacker. Yet I still think some security is
preferable to no security at all. Also I wish this problem could be
attacked somehow other than suggesting to switch to a different language.

[John SJ Anderson]

On Tue, Feb 12, 2013 at 10:39 AM, jbiskofski <jbisk...@gmail.com> wrote:
> I understand that obfuscating code is not a real detriment to a seriously
> motivated knowledgeable hacker. Yet I still think some security is
> preferable to no security at all. Also I wish this problem could be
> attacked somehow other than suggesting to switch to a different language.

Obfuscation is not security. Other people have explained why
obfuscation doesn't make any technical sense. Let me venture a little
bit off topic and explain why it doesn't make any business sense
either.

With your LMS, you're in, fundamentally, a service-oriented business.
The source code that implements your LMS is a tool that helps you
deliver that service -- but it's not really the most important part of
that service, not by a long shot. (It's about as important as the
office copy machine, in fact.)

Do you really think that you if you gave that code to somebody outside
your line of business they would overnight turn into a competitor for
you? No, they wouldn't, because they won't have the assets that you
have that are _really_ important for your business -- like those 18
people that work for you, that have an intimate knowledge of the
problem domain, and of the needs of your customers, and the history of
your service. They also won't have another critical asset you have:
those 300K users, which simultaneously give you a selling point for
future customers and an available pool of people that I bet are happy
to suggest new features and test them out and provide you in-depth
feedback.

Figure out how to protect and nurture *those* assets, and it doesn't
matter who sees your code, because even if they put up an exact clone
of your service, you'll still out-perform and out-innovate them, which
means you'll out-sell them.

chrs,
john.

[Rob Coops]

Hi Bob,

The problem with obfuscation is that if does not work. No mater how far you
go (all database tables are called T<number> with every column being
C<number>) all variables being single letter things like $a and @a and %b
one that wants to will always be able to read it. The only thing that you
are going to achieve is that the people that are unfortunate enough to have
to maintain you product will cures you, reverse engineer the code and write
a maintainable version to replace your code.

I have been supporting various systems for various companies in several
different branches of industry for over 13 years now. At all companies I
have seen the same thing, some perl script build by a perl "guru" (often
self proclaimed). That is near impossible to read and/or enormously big;
often very difficult to work with in terms of the environment requirements,
command line options that have to be in a certain order, undocumented
command line parameters that might or might not do something. Every single
time I ended up having to replace that code with something much simpler
cleaner and easier maintain because the old code was simply not able to
grow with the companies needs and the previous perl guy had left a long
time ago.

Obfuscation is not security, it is just a way to get remembered as the guy
that left the code that no one could maintain.

Even switching to a different language will not help, after all code that
gets executed can be reverse engineered. When you slap enough copyrights
and other wonderful "protection" on your code then the mere input and
resulting output can be emulated in any language of your choice. In the end
the beautiful thing of computers is that given a certain program and a
certain input the result of that program combined with that input will
always be the same, which means there is no way to "hide" what you are
doing just to make it harder to figure out which as I explained above is
never a good idea and your code will normally out live you by many years.
And the next person is not going to be singing your praises for making
their live miserable thanks to code that no one can figure out.

Of course other languages that are compiled for instance make it a little
harder to read the code because of this compilation step, but this does not
stop people from reading the code it just means they have to take an extra
step. Which they will if needed simply because copying a working solution
is always better then inventing the wheel all over again.

The only semi "obfuscation" that works a little bit is today's buzzword
'cloud computing' it allows you to keep your code in your own hands away
from the customer thus better hidden then ever before. Of course this does
not mean that you or me could not for instance build our own Facebook or
Google. It will just be a whole lot harder to do as we are missing one
important bit of information: the input, at least the bit of input that is
running on their servers...
But all in all when you end up working for Google or for Facebook you can
be certain that the code is not obfuscated as it would not be feasible to
maintain a code base of that size with so many people if it where
obfuscated.

Or as the perl help says, Obfuscation only works if you simply delete the
code.
All other solutions will simply frustrate those with good intentions and
just make it more interesting for those with bad intentions.

[Brandon McCaig]

On Tue, Feb 12, 2013 at 08:15:18PM +0100, Rob Coops wrote:
> The problem with obfuscation is that if does not work.

Perhaps a good real world example is video game copyright
infringement ("piracy"). Several publishers spend big money
having the developers implement various "DRM" and obfuscation
schemes, but in most cases it only slows the crackers down by a
matter of hours or days, if at all. Compare that to the time and
money that was spent to implement these techniques, not to
mention the increased costs to debug not only the obfuscation
itself, but the obfuscated result. It doesn't make any sense.

Nevermind that the end result is that the cracked version of the
software is more user-friendly and less intrusive than the legit
copy, increasing the incentive for the average user to run the
cracked version to make their lives easier.

Obfuscation is not security. If you're worried about somebody
breaking into your servers to steal the code then you should be
worrying about securing your servers instead. That's a legitimate
concern. That will be way more effective and is a much more
important thing to do anyway.

Regards,


--
Brandon McCaig <bamc...@gmail.com> <bamc...@castopulence.org>
Castopulence Software <https://www.castopulence.org/>
Blog <http://www.bamccaig.com/>
perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'

[Bill Stephenson]

On Feb 12, 2013, at 11:01 AM, Rajeev Prasad wrote:

> what is the advice just for obfuscating code? platform is solaris.

I played with "Acme::Bleach"

http://search.cpan.org/~dconway/Acme-Bleach-1.150/lib/Acme/Bleach.pm

It takes a different approach to obfuscating code, but it sort of works.

[David Crouse]

Seriously, I took it as just funny... get off your soapbox.
I'm fairly sure that the comment was just in good fun.

As a systems admin, i've had to "decipher" my share of perl,
and while it "can" be written great, it "can" also be written poorly.

[Kevin Walzer]

On 2/12/13 12:54 PM, John SJ Anderson wrote:
> Also, I'm a little disappointed in the "it's Perl, it's already
> obfuscated" answers. If you think the Perl you're writing is
> pre-obfuscated, you're doing it wrong. My Perl code is idiomatic, easy
> to read and understand, and as clear, if not more so, than code
> written in any other language. One of the common criticisms of Perl is
> that it's a "write-only language". This is, frankly, bullshit -- but
> having people on a list aimed at helping Perl beginners promote that
> bullshit only makes it more odorous. Please stop.

I'm an experienced developer in several other languages (Python, Tcl,
AppleScript, JavaScript, C/Objective C), so I'm quite familiar with
structuring a program--but as I work on learning Perl, I find it
somewhat obscure, if not downright obfuscated. None of the other
languages I've worked with have the equivalent of the $_ implicit var,
for instance. Looking at some sample code online, I had to spend a
considerable amount of time looking up the various bits with sigils and
annotating them, cf:

open (INPUT, "< $_"); ##input from default $_ var
foreach (<INPUT>) {
if(/$searchstring/i) { ##case-insenstive regex for
$searchstring
$_ = substr($_, 0, 60); ##trim string to 60 chars
s/^\s*//; #trim leading space
print "$File::Find::name\:$.\:\t$_\n"; #print filename
followed by line number followed by tab followed by matching line

}
}
close INPUT;

Perhaps this is idiomatic to you, but it's very dense to me. And I have
a decade of development experience.

All kidding aside, perhaps one way the OP could obfuscate his code is to
deploy it in a PAR file--how hard are those to unwrap? Does Perl have
the equivalent of Python bytecode files, i.e. pyc, that are obfuscated?
If not, the OP's options may be limited.

--Kevin

--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

[John SJ Anderson]

On Feb 12, 2013, at 2:50 PM, David Crouse <da...@crouse.us> wrote:

> Seriously, I took it as just funny... get off your soapbox.
> I'm fairly sure that the comment was just in good fun.

I'm happy you were amused. I wasn't, and I imagine anybody that's had to deal with the "Perl is a write-only language" perception wasn't too amused either.

> As a systems admin, i've had to "decipher" my share of perl,
> and while it "can" be written great, it "can" also be written poorly.

Which makes Perl like, oh, every other programming language ever. I don't see your point.

j.


--
John SJ Anderson // gene...@genehack.org

[John SJ Anderson]

On Feb 12, 2013, at 3:05 PM, Kevin Walzer <k...@codebykevin.com> wrote:

> I'm an experienced developer in several other languages (Python, Tcl, AppleScript, JavaScript, C/Objective C), so I'm quite familiar with structuring a program--but as I work on learning Perl, I find it somewhat obscure, if not downright obfuscated. None of the other languages I've worked with have the equivalent of the $_ implicit var, for instance. Looking at some sample code online, I had to spend a considerable amount of time looking up the various bits with sigils and annotating them, cf:
>
> open (INPUT, "< $_"); ##input from default $_ var
> foreach (<INPUT>) {
> if(/$searchstring/i) { ##case-insenstive regex for $searchstring
> $_ = substr($_, 0, 60); ##trim string to 60 chars
> s/^\s*//; #trim leading space
> print "$File::Find::name\:$.\:\t$_\n"; #print filename followed by line number followed by tab followed by matching line
>
> }
> }
> close INPUT;
>
> Perhaps this is idiomatic to you, but it's very dense to me. And I have a decade of development experience.

There's nothing idiomatic about that. I'd write that code as:

# do whatever needed to get filename out of $_ into $filename here
open( my $INPUT , '<' , $filename ) or die( "Can't open $filename ($!)" );
foreach my $line ( <INPUT> ) {
if( $line =~ /$searchstring/i ) {
my $trimmed_line = substr( $line , 0 , 60 );
$trimmed_line =~ s/^\s*//; ## NOTE: Possible logic bug;
## $trimmed_line now may be < 60 chars

printf "%s:%s:\t%s\n" , $filename , $. , $trimmed_line;
}
}
close( $INPUT );


I might initially write the foreach loop and the regex with $_, but as soon as I hit that substr, it would be named variables all the way.

> All kidding aside, perhaps one way the OP could obfuscate his code is to deploy it in a PAR file--how hard are those to unwrap? Does Perl have the equivalent of Python bytecode files, i.e. pyc, that are obfuscated? If not, the OP's options may be limited.

No such critter in Perl.

[John SJ Anderson]

On Feb 12, 2013, at 3:33 PM, Jim Gibson <jimsg...@gmail.com> wrote:

>
> On Feb 12, 2013, at 3:18 PM, John SJ Anderson wrote:
>
>>
>> There's nothing idiomatic about that. I'd write that code as:
>>
>> # do whatever needed to get filename out of $_ into $filename here
>> open( my $INPUT , '<' , $filename ) or die( "Can't open $filename ($!)" );
>> foreach my $line ( <INPUT> ) {
>

> I am guessing that you would actually write that with a while loop instead of a foreach loop (and put the dollar-sign in front of INPUT):
>
> while( my $line = <$INPUT> ) {
>
> For the foreach loop, Perl at one time would have to read in the entire file, form a list from the lines, and then iterate over that list, at a big cost in memory for large files. That may have been improved in recent Perls, but unless you know for sure, sticking with the while() loop, which reads lines one-at-a-time, is safer.
>
> You will also want to add the line:
>
> chomp($line);
>
> If the line is less than 60 characters, a newline character will be left at the end of the line. If it is greater than 60, it will be removed. So if you have any short lines in the input, you will get extra blank lines in your output.

Oh, man, did I leave off my "code is untested and written completely off the top of my head" disclaimer? It seems I did. 8^)

Thanks for the corrections, Jim. Honestly, my fingers typed 'while' initially, but I flipped it back to a 'foreach' to better match what was there -- I should have noted that in a comment. The lack of a sigil on INPUT was just silliness.

I'm going to claim the lack of chomp() was also to match the code that was provided ... that's my story, I'm sticking to it. 8^)

thanks,
john.

[Jim Gibson]

On Feb 12, 2013, at 3:18 PM, John SJ Anderson wrote:

>
> There's nothing idiomatic about that. I'd write that code as:
>
> # do whatever needed to get filename out of $_ into $filename here
> open( my $INPUT , '<' , $filename ) or die( "Can't open $filename ($!)" );
> foreach my $line ( <INPUT> ) {

I am guessing that you would actually write that with a while loop instead of a foreach loop (and put the dollar-sign in front of INPUT):

while( my $line = <$INPUT> ) {

For the foreach loop, Perl at one time would have to read in the entire file, form a list from the lines, and then iterate over that list, at a big cost in memory for large files. That may have been improved in recent Perls, but unless you know for sure, sticking with the while() loop, which reads lines one-at-a-time, is safer.

You will also want to add the line:

chomp($line);

If the line is less than 60 characters, a newline character will be left at the end of the line. If it is greater than 60, it will be removed. So if you have any short lines in the input, you will get extra blank lines in your output.

[Shlomi Fish]

Hi all,

thanks all for the great responses. Here is something I have written about it
in the context of using Python bytecode files (.pyc) for hiding the source,
which some people erroneously believe is an advantage of Python:

http://shlomif-tech.livejournal.com/39732.html

I think it is important in the computer business to trust your users,
customers, clients, etc. and also not treat them like idiots. Amazon.com has
been making a lot of money selling 100% DRM-free .mp3s of popular songs
(although it is only unfortunately available for .us-customers only) and many
music artists have opted to sell their music on other online stores, completely
DRM-free and available for any person in the World who is willing to pay for
them. Yes, they can be pirated and often are, but it makes good business sense.

* http://en.wikipedia.org/wiki/Hakuna_matata

* http://www.amazon.com/Feel-Much-Better-That-Given/dp/0880071478 - “I feel
much better now that I've given up hope”.

Regards,

Shlomi Fish

--
-----------------------------------------------------------------
Shlomi Fish http://www.shlomifish.org/
List of Text Editors and IDEs - http://shlom.in/IDEs

Trying to block Internet pornography is like climbing a waterfall and trying
to stay dry. (— one of Shlomi Fish’s Internet Friends)

Please reply to list if it's a mailing list post - http://shlom.in/reply .

[Octavian Rasnita]

From: "Shlomi Fish" <shl...@shlomifish.org>

Hi all,

On Tue, 12 Feb 2013 09:01:27 -0800 (PST)
Rajeev Prasad <rp.n...@yahoo.com> wrote:

> freinds,
>
> what is the advice just for obfuscating code? platform is solaris.
>
> ty.

thanks all for the great responses. Here is something I have written about it
in the context of using Python bytecode files (.pyc) for hiding the source,
which some people erroneously believe is an advantage of Python:

http://shlomif-tech.livejournal.com/39732.html

Well, I don't agree.

First, in some parts of the world, the recommendation of using user license agreements or lawyers is futile, because the laws are not the same all over, and even where the laws should be respected, they are not.

Second, I have read for many times that it is easy to decompile a bytecode, or to clean the obfuscated code, but I couldn't find "easy" to follow examples about how to do that. It is true that I haven't searched on the web for programs that can be used for this, but if someone needs to search for such programs that might also include malware, it means that it is not an easy task.

So as a promotor of an open source language I can recommend to offer open source programs, but if you need to sell the programs for living, to a public you can't trust, respect your public, but force them to pay, because otherwise they won't pay absolutely anything they can get for free.

The fact that Perl doesn't have tools that make the encryption/obfuscation so easy as for other languages is another reason for which the software companies prefer other languages.

A pretty good solution for hiding the source code is to package the Perl programs using a paid application like ActiveState PDK.
For most users it would be too complicated and it would require a too big effort to do that, so they might prefer to pay because this would be easier.

Otherwise... for some users the payment itself may be a complicated thing, even they will accept to give the money, so if the source code can be used for free, it is clear that they won't pay at all.

It would be nice if Perl would allow us to choose what programs we want to offer as open source and which ones we want to protect as good as possible, but in an easier way.

Perl has other advantages. In this field it doesn't have an advantage.

Octavian

[Tiago Hori]

Read Stalmmans free as in freedom on why software should always be free, not as in Free Beer but as in freedom. The GPL hás ira viral nature for a purpose. The body of work in which you and I really to write software solutions is not based on the idea of one man, but in the collective work and efforts of mankind, which I thinks renders the idea or intellectual property moot. We overrate the creation of something new as a miracle when it is just a reorganization of existing ideas. It is because of that, I believe that culture, and software like music or literature, parts of culture should always be free. And I despise the argument that some places are lawless and therefore you need encryption and DRM. Those places you are probably thinking of are the one more in need of free culture. Poor third world countries. I think that the hardest part is that we are immersed in a system that would have as believe otherwise. I, for one, do not use 100% free software stuff and admire those who do. I believe however that as professor and in an area that would never have been where is at without free software I can help by letting people k ow that for every commericial bioinformatics tool out there, there is a better open source. As for the challenge of making a living out of it and saying that there is no other choice, I feel bad if that is true, I like to think based on companies like o'reilly and others who opt for DRM free that it is possible, but those are bigger companies. Maybe the only solution is in educating the next generations. However, I think ignoring the fact that things like perl and Linux are what they are because of community not individual and therefore should be treated as so, a product of the community, is wrong. I think there is an ethical issue and choice behind this discussion which is as important as the all the more practical issues.

T.



Sent from my iPhone

[John W. Krahn]

Kevin Walzer wrote:
>
> I'm an experienced developer in several other languages (Python, Tcl,
> AppleScript, JavaScript, C/Objective C), so I'm quite familiar with
> structuring a program--but as I work on learning Perl, I find it
> somewhat obscure, if not downright obfuscated. None of the other
> languages I've worked with have the equivalent of the $_ implicit var,
> for instance. Looking at some sample code online, I had to spend a
> considerable amount of time looking up the various bits with sigils and
> annotating them, cf:
>
> open (INPUT, "< $_"); ##input from default $_ var

It is very bad to use a system function like open() without determining
if it succeeded or failed. Also, most modern Perl programmers use the
three argument version of open() and lexical filehandles.

open my $INPUT, '<', $_ or die "Cannot open '$_' because: $!";

Also, the File::Find::find() function callback function, which this code
is part of, only allows you to access the current file name through the
$_ variable, while in other contexts a lexical variable can be used
instead of $_.


> foreach (<INPUT>) {

A foreach loop operates on a list so perl has to read the entire file
into a list in memory. This is usually written with a while loop which
only reads one line at a time.

while (<INPUT>) {

> if(/$searchstring/i) { ##case-insenstive regex for $searchstring

Case-insenstive regex for the contents of $searchstring. A match
operator does interpolation basically the same as a double quoted
string. A better way would be to create $searchstring using the qr//
operator with the /i option.

> $_ = substr($_, 0, 60); ##trim string to 60 chars

That is an inefficient way to truncate a string. A better way would be:

substr( $_, 60 ) = ''; ##trim string to 60 chars

Or perhaps better:

substr( $_, 60, length(), '' ); ##trim string to 60 chars

As this modifies the string in-place.

> s/^\s*//; #trim leading space

That modifies every string, whether it contains leading whitespace or
not. It should be written to only modify strings that actually contain
whitespace:

s/^\s+//; #trim leading space

> print "$File::Find::name\:$.\:\t$_\n"; #print filename followed by line
> number followed by tab followed by matching line

The $. (current line number) variable only contains useful information
from inside a while loop but does nothing useful from inside a foreach loop.

> }
> }
> close INPUT;
>
> Perhaps this is idiomatic to you,

No, it is not. It looks like someone who doesn't understand Perl wrote
this. You should be careful what you download off the internet. ;)

> but it's very dense to me. And I have
> a decade of development experience.

John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein

[Octavian Rasnita]

From: "Tiago Hori" <tiago...@gmail.com>

> I despise the argument that some places are lawless and therefore you need encryption and DRM. Those places you are probably thinking of
> are the one more in need of free culture. Poor third world countries.

Yep. The problem is that there are more people living in those countries than on rich countries. Not everyone lives in USA. :-)
And the culture cannot be changed by a few software developers that try to earn for living.

> I believe however that as professor and in an area that would never have been where is at without free software I can help by letting people k ow
> that for every commericial bioinformatics tool out there, there is a better open source.

This is not true. Open Office and Libre Office are not better than MS Office.
The best OCR programs are commercial.
The best programs which are used to improve the accessibility for the blind are also commercial. From the accessibility point of view, which is the most important point for that category of people, MS Windows is the best OS because it has the best accessibility.
And there may be many other examples...

> As for the challenge of making a living out of it and saying that there is no other choice, I feel bad if that is true

Yes there is another choice. To do something else than programming.
In some countries the programmers create open source programs and sell books, training or other additional services.
In other countries the books are scanned and OCRed and read for free, or downloaded from torrents, and very few people pay for training, so these are not a choice.

> Maybe the only solution is in educating the next generations.

Yes. That is the solution. But it is also a solution for the next generations of programmers, not for the current one.
But from what I see, the world actually goes in the opposite direction.

However, I think ignoring the fact that things like perl and Linux are what they are because of community not individual and therefore should be treated as so, a product of the community, is wrong.

I agree. This is why I said that the recommendation is to also create open source, as a contribution to the community.
But this doesn't mean that the users of an open source language should never write proprietary applications.

Octavian

[Tiago Hori]

> Yep. The problem is that there are more people living in those countries
> than on rich countries. Not everyone lives in USA. :-)
> And the culture cannot be changed by a few software developers that try to
> earn for living.
>

Agreed. I think in there lies the biggest limitation. My point was, as you
say later, you can do both.

>
> > I believe however that as professor and in an area that would never have
> been where is at without free software I can help by letting people k ow
> > that for every commericial bioinformatics tool out there, there is a
> better open source.
>
> This is not true. Open Office and Libre Office are not better than MS
> Office.
> The best OCR programs are commercial.
> The best programs which are used to improve the accessibility for the
> blind are also commercial. From the accessibility point of view, which is
> the most important point for that category of people, MS Windows is the
> best OS because it has the best accessibility.
> And there may be many other examples...
>

Neither GIMP is better than photoshop. I would disagree with regards to
word and specially to Excel. To me anything is better than those
monstrosities. The only reason I still use them is portability to other
people, and in science, the vast majority uses office. I process all my
data in MySQL and perl and than same it as tab delimted file, so the excel
folks can read it. But there isn't an easy way to go from latex to word
that I know. I you can't easily put comments on latex formatted files. But
as far as bioinformatics go, I challenge any one to show me a proprietary
solution that is better than the perl, python and R modules available.

>
> > As for the challenge of making a living out of it and saying that there
> is no other choice, I feel bad if that is true
>
> Yes there is another choice. To do something else than programming.
> In some countries the programmers create open source programs and sell
> books, training or other additional services.
> In other countries the books are scanned and OCRed and read for free, or
> downloaded from torrents, and very few people pay for training, so these
> are not a choice.
>

But isn't it social inequity that drive those behaviours for the most part.
I grew up in Brasil and for the longest time and never bought a book or a
cd or anything. Why, because the cost makes it not-accessible, and the
reason why it is so in the third world is incompetent tax policy making and
sheer greed. Again, I think there are middle-points, that are not the 100%
encrypted commericial model that can suit these situations. I think that
the acedemic licensing model is a great example of middle ground.

>
>
> > Maybe the only solution is in educating the next generations.
>
> Yes. That is the solution. But it is also a solution for the next
> generations of programmers, not for the current one.
> But from what I see, the world actually goes in the opposite direction.
>
> However, I think ignoring the fact that things like perl and Linux are
> what they are because of community not individual and therefore should be
> treated as so, a product of the community, is wrong.
>
> I agree. This is why I said that the recommendation is to also create open
> source, as a contribution to the community.
> But this doesn't mean that the users of an open source language should
> never write proprietary applications.
>

Agreed. My point was trying to say, just because it is hard, does mean you
have to go to exclusive commercial route and that maybe compromise between
open source and propriety source code that may further the democratization
of technology.

>
> Octavian
>
>
T.


--
"Education is not to be used to promote obscurantism." - Theodonius
Dobzhansky.

"Gracias a la vida que me ha dado tanto
Me ha dado el sonido y el abecedario
Con él, las palabras que pienso y declaro
Madre, amigo, hermano
Y luz alumbrando la ruta del alma del que estoy amando

Gracias a la vida que me ha dado tanto
Me ha dado la marcha de mis pies cansados
Con ellos anduve ciudades y charcos
Playas y desiertos, montañas y llanos
Y la casa tuya, tu calle y tu patio"

Violeta Parra - Gracias a la Vida

Tiago S. F. Hori. PhD.
Ocean Science Center-Memorial University of Newfoundland

[Octavian Rasnita]

From: "Bob McConnell" <r...@CBORD.com>

> You cannot obfuscate the input to an interpreter. It has to be in a format
> that the interpreter will recognize, which necessarily means that people
> can
> also read it. If you really need to hide your source code, you have to
> switch to a compiled language with an actively optimizing compiler.

I don't think that a Perl programmer can't hide his source code well enough,
and if he wants to do that, he needs to switch to another language.

If he created a Windows executable nice packaged in a setup.exe installer
and wants to sell it for $10 - $20, then hiding the source code might help.
If he just says that the users should pay $10 for using that program
provided as source code, somebody who knows a little Perl could pay for it,
then change the name of the program, eventually do some cosmetic changes in
the source code, package it using ActiveState PDK and sell it as a new
program that competes with the original one.
Some may even like to do this to show that they are great programmers and
that they created an application.

If getting the source code is complicated enough, than those who may want to
duplicate the program may get bored and abandon the idea.

Apple, Microsoft, Oracle, IBM, SAP use to sell proprietary applications and
their financial situation is not too bad. :-)
I think that if providing everything as open source would have been such a
good idea from the financial point of view, they would have provided all
their applications as open source for a long time.

Octavian

[Octavian Rasnita]

From: "John SJ Anderson" <gene...@genehack.org>

> On Tue, Feb 12, 2013 at 10:39 AM, jbiskofski <jbisk...@gmail.com> wrote:
>> I understand that obfuscating code is not a real detriment to a seriously
>> motivated knowledgeable hacker. Yet I still think some security is
>> preferable to no security at all. Also I wish this problem could be
>> attacked somehow other than suggesting to switch to a different language.
>
> Obfuscation is not security. Other people have explained why
> obfuscation doesn't make any technical sense.

Yes, it doesn't make any technical sense. It should be used only for making
the others not like the idea of stealing your source code. So it has a kind
of social sense. :-)

> Let me venture a little bit off topic and explain why it doesn't make any
> business sense
> either.
>
> With your LMS, you're in, fundamentally, a service-oriented business.

I don't know what's LMS. I found with Google Learning Management System, or
LAN management system, but it is still not clear.

> The source code that implements your LMS is a tool that helps you
> deliver that service -- but it's not really the most important part of
> that service, not by a long shot. (It's about as important as the
> office copy machine, in fact.)
>
> Do you really think that you if you gave that code to somebody outside
> your line of business they would overnight turn into a competitor for
> you? No, they wouldn't, because they won't have the assets that you
> have that are _really_ important for your business -- like those 18
> people that work for you, that have an intimate knowledge of the
> problem domain, and of the needs of your customers, and the history of
> your service. They also won't have another critical asset you have:
> those 300K users, which simultaneously give you a selling point for
> future customers and an available pool of people that I bet are happy
> to suggest new features and test them out and provide you in-depth
> feedback.

OK, but what if I don't have a team of 18 people, but I am the single team
player? And what if I don't have thousands of clients, but I have zero
clients and I try to create and sell a program?
And what if that competitor that might steal the source code is working for
a company, where he has many colleagues that may improve that program even
faster than I can?

The programmers that use other languages say that Perl is bad because its
flexibility and TIMTOWTDI, because it allows much easier to make the code
unmaintainable, and we say that well, this is what we like, that Perl
doesn't forces us to do only some things allowed by somebody else, that if
we want to shoot on our foot we can do it because it is our own business.
Well, maybe some of the Perl programmers would like to do that stupid thing
which is much easier to do in other languages... hide the source code.
Why don't we say anymore that Perl is flexible enough and that it can also
do that even easier than in other languages?
Just because it is not possible to do it in Perl as easy as in other
languages?

There are languages which are more popular than Perl now, and their
popularity increases, and they allow hiding/obfuscating the source code
easy. All of them are wrong, or the programmers that use those languages
don't know that their code is not 100% secured? I'd say that they also know,
but they don't even want 100% security, but to make their source as hard to
find as possible.

If somebody asks "please tell me how to do that in Perl", is not even polite
to say "oh, you can do it in PHP this way...".
If somebody asked if Perl can do something, if the answer is "no, Perl can't
do it" than this should be the correct answer, not that that person should
not do it just because Perl can't do it.

For example, it is not possible to do in Perl what you can do on Python on
Android. It is not possible to create in Perl an SSH client that
authenticate with a password if you want that program portable on Windows.
It is not possible to create in Perl a COM server unless you use a
proprietary application like ActiveState PDK... and so on.

Perl is good for some things. For other things, it is worse.
I don't think that the answers that "move from Windows to Linux" or "don't
do that because it is not a good idea" are helpful answers.

Octavian

[Octavian Rasnita]

From: "Rob Coops" <rco...@gmail.com>

> Hi Bob,
>
> The problem with obfuscation is that if does not work. No mater how far
> you
> go (all database tables are called T<number> with every column being
> C<number>) all variables being single letter things like $a and @a and %b
> one that wants to will always be able to read it. The only thing that you
> are going to achieve is that the people that are unfortunate enough to
> have
> to maintain you product will cures you, reverse engineer the code and
> write
> a maintainable version to replace your code.

Don't confuse the obfuscated code with the code that should be maintained.

The code that should be maintained is the common Perl code we write
everyday, with no obfuscation at all.

The obfuscated code would be that one that would be created by running a
program:

obfuscate myscript.pl myscript_obfuscated.pl

...that would generate an obfuscated code that you can send to your clients.
But your company will continue to maintain the clean code, not the
obfuscated one.
You will generate another obfuscated version only when you will launch a new
version for the public.

Octavian

[Bob McConnell]

People have been selling both Open Source and Free Software for years. Both IBM and RedHat are doing very well at it. But they don't always require cash or monetary profit as their selling price. You might also want to consider this article about the open source economic model.

<http://lxer.com/module/newswire/ext_link.php?rid=180777>

bm

> -----Original Message-----
> From: Octavian Rasnita [mailto:oras...@gmail.com]
> Sent: Wednesday, February 13, 2013 12:53 PM
> To: Bob McConnell; Perl Beginners
> Subject: Re: obfuscating code
>

[Rob Coops]

Are we really spiraling into a discussion on the merits of open versus
closed source?

Perl is a scripting language, it was create by a linguist which it is why
it allows for so many different ways to get the code to do the same thing.
It is like a language very flexible in many ways. Obfuscating code is not a
good idea for the nice market that Perl inhabits it is as simple as that.
If you want to do something like lets say quantum super positioning then
sure that could be done in Perl. But even the author of that module stated
that it was a pretty silly thing to do in Perl as it was simply not meant
to do such things.

Other scripting languages try (wrong or right that's up to you) to be
everything to all people and for large part are beginning to loose sight of
the scripting language that they are at their core. More and more these
languages are attempting to compete with the Java's of this world who in
its own right is trying to take the place of C/C++. Personally I am of the
opinion that most programming languages have a good reason for existing,
there is a problem domain in which they are simply the best tool in the
box. But the idea that a lot of modern languages seem to try is to be the
only tool in the box which in my opinion is totally wrong.

The reason why most Perl people will tell you obfuscation in Perl is simply
not right and should not be done is because the problem domain that Perl
covers is not on in which obfuscation is the way you should go.

If you are inventing something so extraordinary or exceptional that you
absolutely need to protect your code from prying eyes then you should
wonder if you should be using Perl for this. I know learning another
language is not the most fun or exciting bit of writing code but sometimes
that other language is simply much better suited to deal with the problem
you are trying to tackle.

Regardless of where you stand in the open source vs. closed source
discussion, I think we can all agree that code obfuscation is simply not
something that Perl the Perl authors or a rather substantial portion of the
Perl community support. Therefore you might want to try and build some tool
that does obfuscate your code for you if you really need it and cannot
change the language you are working in for what ever reason. But I
seriously doubt you will see a large portion of the Perl community
supporting your efforts. Not unlike the tools that turn Perl scripts into
binary files ready to be executed on a platform of your choice (during
compile time of course) an obfuscation tool will be used for sure, but
there is not a wide spread believe within the Perl community that this is
the right thing to do with Perl. The main argument being there are better
languages to do that in.

[David Crouse]

Yeah I was amused... sorry you weren't.
Perhaps you don't have a sense of humor idk.

No...perl isn't like every other program language ever...if so, why
are you using it and not something else. Because you like the way it
works, it's syntax, whatever...you like it or you probably wouldn't be
so defensive. I like it too, but the comment "It's Perl. The
obfuscation is built in" was funny... the perl journal use to have
"obfuscated code contests" if i remember correctly.

The one line I like the best that I find humor and truth in:

Always code as if the guy who ends up maintaining your code
will be a violent psychopath who knows where you live.
~ PERL BEST PRACTICES

[Rob Dixon]

On 12/02/2013 22:50, David Crouse wrote:
>
> Seriously, I took it as just funny... get off your soapbox.
> I'm fairly sure that the comment was just in good fun.
>
> As a systems admin, i've had to "decipher" my share of perl,
> and while it "can" be written great, it "can" also be written poorly.

David, as a Perl programmer I am sure you come across the prejudice that
we all do - that Perl is inherently incomprehensible. The crown once
belonged to APL, but despite our efforts at evangelism Perl now gets a
kicking that it doesn't deserve.

Tribal behaviour is inevitable, but when global ideas are berated a lot
of damage can be done.

I'm sure you will agree that Perl is a current, useful and vibrant
language. Yet there is also a problem with its perception - it is
believed to be difficult to read and write, and far from the
cutting-edge of technology.

This perception is far from the truth. Perl can be written very well and
very neatly, and often betters similar languages. In comparison C is far
too easily abused, and platform compatibility is a struggle.

If you're after "fun", try visiting your neighbour reeking of last
night. There are some things that stick, and we would rather you didn't
spread them about.

Perl is a tidy and expressive language.

Rob

[Paul Johnson]

Whilst that's true to a first, second and maybe even a third
approximation, it's perhaps not absolutely correct:

$ echo 'sub X { print 42 } 1' > X.pm
$ perl5.8.9 -MX -eX
42
$ perl5.8.9 -MO=Bytecode,-H -MX -e1 > XX.pmc
-e syntax OK
$ perl5.8.9 -MXX -eX
42
$ od -x XX.pmc
0000000 2123 2f20 7375 2f72 6f6c 6163 2f6c 6b70
0000020 2f67 6570 6c72 642f 6665 7561 746c 702f
0000040 7265 2d6c 2e35 2e38 2f39 6962 2f6e 6570
0000060 6c72 2e35 2e38 0a39 7375 2065 7942 6574
0000100 6f4c 6461 7265 3020 302e 3b36 500a 424c
0000120 7843 3638 365f 2d34 696c 756e 0078 2e30
0000140 3630 0800 0000 0800 0000 0c00 5938 0161
0000160 0000 0000 0000 6400 650d 0c40 5760 6d50
...
0001440 0000 0939 0000 3b00 0010 7e3a 0003 8900
0001460 000e 0000 0000
0001465


But, be that as it may, even this won't stop someone who knows what they
are doing being able to recover your source code, after a fashion.

In practice, it's all about degree. Given that someone can run your
code locally, and that if they have sufficient time and skill they will
be able to reverse engineer your code to a greater or lesser extent
(which is true for all programs in all languages), often you just want to
hide your code from a curious observer, or to make it not worth
someone's while to put in that effort.

Modules such as Acme::Bleach have already been mentioned. One approach
I have taken in the past is to embed perl inside a C program. I have
encrypted the Perl source and added that as data in the C program. The
C program decrypts the source and calls the embedded perl to execute it.
You also need to do something clever so that "use" and friends look at
the text in the C program first. Then you distribute the executable.
That's probably more than sufficient for most purposes.

It's probably also more than sufficient for this list.

--
Paul Johnson - pa...@pjcj.net
http://www.pjcj.net

[Andy Bach]

On Wed, Feb 13, 2013 at 5:50 PM, Paul Johnson <pa...@pjcj.net> wrote:

> > Does Perl have the equivalent of Python bytecode files,

What about, say, Acme::Bleach
http://search.cpan.org/~dconway/Acme-Bleach-1.150/lib/Acme/Bleach.pm

"The first time you run a program under use Acme::Bleach, the module
removes all the unsightly printable characters from your source file. The
code continues to work exactly as it did before, but now it looks like this:

"

[yes all whitespace]

--

a

Andy Bach,
afb...@gmail.com
608 658-1890 cell
608 261-5738 wk

[Octavian Rasnita]

From: "Bob McConnell" <r...@CBORD.com>

People have been selling both Open Source and Free Software for years. Both IBM and RedHat are doing very well at it. But they don't always require cash or monetary profit as their selling price. You might also want to consider this article about the open source economic model.

<http://lxer.com/module/newswire/ext_link.php?rid=180777>

I read it, but it is limited to only a kind of software business. Those who create text editors like UltraEdit, TextPad or others and sell their product are in another type of software business because they offer a 1-time deal and get some money. That's all.
And there are many other business of the same type.
Not everyone sells to permanent customers or B2B. Some create simple programs for the public.

Octavian

[Brandon McCaig]

On Thu, Feb 14, 2013 at 09:11:39AM +0200, Octavian Rasnita wrote:
> I read it, but it is limited to only a kind of software
> business. Those who create text editors like UltraEdit, TextPad
> or others and sell their product are in another type of
> software business because they offer a 1-time deal and get some
> money. That's all. And there are many other business of the
> same type. Not everyone sells to permanent customers or B2B.
> Some create simple programs for the public.

The public generally cannot afford to spend $50 - 200 - 2000 on
every piece of software that they could benefit from. They have
other expenses, like rent! The value they get from the software
is usually superficial. Entertainment, maybe, or convenience. It
probably won't earn or save much money for most people, and what
it does is usually not visible to them. Hence, the average
consumer is heavy into "piracy". They don't even question the
morals of it. Not because they're immoral people, but because
they just can't afford the ridiculous licensing fees for
everything (and practically speaking not every illegitimate copy
is a lost sale). It makes much better sense to charge licensing
fees to organizations that will be making (or saving) money with
your software, and give the software away to personal users for
free. Mostly though, it makes better sense to charge for the
development and support of the software instead of licensing it.

The reality is that investing in closed source software is a bad
investment. You don't have any control over it, you can't know if
it leaves you vulnerable to attacks, and you can't make it
better. It makes good sense for everyone to invest in open source
development instead. Espeically organizations that have money to
spend on software anyway. It makes sense that they get their
money's worth. The thing is that an organization that needs
software to do their business doesn't need to sell that software.
The software serves a purpose and that is where the value comes
from. It does no harm to them to share it with others (arguably
it might harm them by putting competitors on equal ground, but in
most sectors I doubt software plays a major role in competition
anyway). In fact, it's better for them because others will invest
in it also, making it ultimately better for everyone.

Proprietary software is a very expensive business model (for
everyone). It discourages innovation and encourages vendor
lock-in. Everybody has to reinvent the square wheel because the
existing square wheels are protected by law. What makes companies
like Microsoft rich isn't developing good products. It is
cornering the market and caging it with vendor lock-in. Their
business practices have been called into question on several
occasions, and laws have been passed to try to force them to play
fair. You need an operating system to transform a computer from
an overpriced paperweight into a useful machine. They secured a
monopoly on IBM PC hardware early and do everything in their
power to keep it. It is slipping now thanks to free[1] software.
Good for Microsoft is bad for everyone else.

In general developing software with the hopes to sell it later is
a poor business model, I think. The users didn't have any say in
how it was designed so it will probably not fit their needs
well[2]. It's also a gamble for the developers because they don't
know if the software will really be sufficiently useful to
anyone[2]. It makes better sense to secure a contract beforehand
and design the software according to the needs of those funding
it. They will get exactly what they need, your developers and
business will get paid for certain, and nobody is getting shafted
by the deal (hopefully). Most software that is written isn't
ground-breaking. It's just reinventing the square wheel over and
over again. If those square wheels are free[1] software then you
can take the already square wheel and smooth it instead.

[1] As in freedom.

[2] *cough* Windows 8.

[Rajeev Prasad]

From: Paul Johnson <pa...@pjcj.net>

To: John SJ Anderson <gene...@genehack.org>
Cc: begi...@perl.org
Sent: Wednesday, February 13, 2013 5:50 PM
Subject: Re: obfuscating code

------------------------------------------------

thx. an obfuscation level 5 on a scale of 1 to 10 will be ok.