Seeing the source

ruby-talk
21

You should use C for Ruby extensions.
Ruby is implemented in C.
JRuby might allow Java extensions...?
If you know C++ you can probably handle the C stuff.

Oh, one other idea for obfuscation, you could always also use Ruby Inline for some things. (like a routine you run first to decrypt your Ruby files or whatever.) Depending on the size of your app, you could pretty easily make it at least confusing to look at with a simple Rot13, or just replacing all newline characters in the Ruby files with some unique identifier string. (other than the first one called, which would include Inline C or whatever to decrypt)

You could make it even simpler. Consider Ruby's predefined variables (they're globals that start with $) and command line flags and arguments.
  there might some simple to implement but not so obvious tricks you could do there.

···

On Sep 1, 2007, at 11:25 AM, Michel Cabili wrote:

Phlip wrote:

Responding to the thread in general - just put your family jewels into
C++
behind a Ruby layer, and ship Ruby for the easy stuff that your clients
don't need to steal...

That seems a fair solution. Although I'm not that deep into Ruby yet, I
saw some links concerning creating extensions for Ruby... but in C.
There must be something equivalent for C++...

That means that when I create for instance my extension (let's say
"funky_extension"), the file concerning the extension will be compiled
therefore obfuscated? Is that what you're talking about?
--
Posted via http://www.ruby-forum.com/\.

22

Yes. But...

In general, asking how to obfuscate code so others can't steal it is "solution probleming". It's just appeasing clue-impaired investors who think their investment will return nothing if someone "steals" the code, re-skins it, and publishes it as an alternate solution.

This is self-aggrandizing. The problem of people going crazy trying to steal your software is a problem most ISVs would dearly love to have. And studies have shown that competitors generally don't _want_ to use your code, when they can see it. The code is only useful to you.

An investor's money goes to building a team and a system to create, test, deploy, and market that code. This _system_ is what a competitor needs, and it's very hard to steal it.

So, write lots of unit tests, and don't publish them. The code's source will be useless!

···

----- Original Message ----- From: "Michel Cabili" <michel.cabili@gmail.com>

That seems a fair solution. Although I'm not that deep into Ruby yet, I
saw some links concerning creating extensions for Ruby... but in C.
There must be something equivalent for C++...

That means that when I create for instance my extension (let's say
"funky_extension"), the file concerning the extension will be compiled
therefore obfuscated? Is that what you're talking about?

--
  Phlip
  Test Driven Ajax (on Rails) [Book]
  "Test Driven Ajax (on Rails)"
  assert_xpath, assert_javascript, & assert_ajax

23

Intellectual property theft is a social problem, not a technical one.

Agreed.

Social problems should have social solutions, and not technical solutions.

I

agree with a former poster: I believe your answer consists of contracts,
licenses and lawyers. It's quite usually immensely cost and time intensive

to

build a technical solution that makes intellectual property theft

unattractive

for a large percentage of your target audience, there are very, very few
cases where it has arguably been made entirely unfeasible - and that took

a

whole lot of engineering.

Disagree. There is, obviously, a *market* for code obfuscation with
*affordable* tools. The challenges are higher for a highly dynamic Language
like Ruby, but less so for languages like Java or C#, which have the
additional benefit of creating bytecode/IL, which can be obfuscated easier.

Code obfuscation is one step of many to "keep honest people honest".
Fighting a war with crackers will not end well, since there are more
crackers out there than people writing an application.

And in regard to social solutions, so far the DMCA hasn't stopped copyright
infringement nor IP "theft".

Besides, agreements can only help as long as both parties see themselves
bound by them. And if an agreement is sloppily worded, or seen through a
rose-colored lens (SCOX, anybody?), you end up with the same problem you had
in the beginning...

···

--
Phillip Gawlowski

24

Michel Cabili wrote:

Phlip wrote:

Responding to the thread in general - just put your family jewels into
C++
behind a Ruby layer, and ship Ruby for the easy stuff that your clients
don't need to steal...

That seems a fair solution. Although I'm not that deep into Ruby yet, I
saw some links concerning creating extensions for Ruby... but in C.
There must be something equivalent for C++...

That means that when I create for instance my extension (let's say
"funky_extension"), the file concerning the extension will be compiled
therefore obfuscated? Is that what you're talking about?
--
Posted via http://www.ruby-forum.com/\.

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/100255

Are links that might be of interest if you want to work with C++ and Ruby.

Generally speaking there is no such thing as a way to prevent people from
finding stuff out about your software -- You can make it harder but you can't
stop it completly.

I remember I once had to run a Program in order to get a link as part of a
game I was playing with a friend (the link was hard coded in the exe). When
you don't use WINE, it's a little hard to run Windows software under Unix even
for a game. =/

So I took a dump of the .exe using some of the posix programs on the unix box
and found the URL easy as pie, along with information about the VS project
files and that it was done in classic Visual BASIC. I've never had to use such
software before but I'd reckon it probably would return a fair bit of stuff if
some one wanted to look deep enough into some ones programs. A determined
enough individual will find it, the lazy won't.

I doubt you have much to worry about though, unless you plan on making
millions with one program :wink: -> Lawyers and your countries laws are better
protection !!!

···

--
    
Email and shopping with the feelgood factor!
55% of income to good causes. http://www.ippimail.com

25

John Joyce wrote:

You should use C for Ruby extensions.

The best thing about these extensions is wrapping rVALUE (IIRC) in a C++ class that presents all its native methods as C++ methods. From there the rest is easy!

···

--
  Phlip
  http://www.oreilly.com/catalog/9780596510657/
  "Test Driven Ajax (on Rails)"
  assert_xpath, assert_javascript, & assert_ajax

26

Phil wrote:

Disagree. There is, obviously, a *market* for code obfuscation with
*affordable* tools. The challenges are higher for a highly dynamic Language
like Ruby, but less so for languages like Java or C#, which have the
additional benefit of creating bytecode/IL, which can be obfuscated easier.

There's a market for _lots_ of "bossware" - thinks like MS Project, that nobody really needs...

Code obfuscation is one step of many to "keep honest people honest".
Fighting a war with crackers will not end well, since there are more
crackers out there than people writing an application.

Right idea but wrong formula. For every week spent securing code, a cracker can spend an hour cracking it. That's just entropy - it's easier to destroy than create.

And in regard to social solutions, so far the DMCA hasn't stopped copyright
infringement nor IP "theft".

09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0, holmes. See you in GITMO!

···

--
  Phlip
  http://www.oreilly.com/catalog/9780596510657/
  "Test Driven Ajax (on Rails)"
  assert_xpath, assert_javascript, & assert_ajax

27

This story is old as the universe.
Sombody like to make a something once and live happily ever after and
someone else has a different idea about it.

The amount of money that companies spend on securing their software is
in direct correlation with number of keygens and patches available on
the net.

You should think what is that you are selling.
I know it's not a code. Perhaps its solution, service, idea, time,
creativity but is definitely not a code.

If you build something that gain some successes do not think that you
can live from the past glory. The current success is a history. You
should move to new challenges. Ones that try to mimic your solution
will always be one step behind.

The only solution is open source.
The clever people will help you make a bright idea of yours great.

28

> Disagree. There is, obviously, a *market* for code obfuscation with
> *affordable* tools. The challenges are higher for a highly dynamic
> Language
> like Ruby, but less so for languages like Java or C#, which have the
> additional benefit of creating bytecode/IL, which can be obfuscated
> easier.

There's a market for _lots_ of "bossware" - thinks like MS Project,
that nobody really needs...

Gantt charts are not just unnecessary. They, and their brethren, are risk
management. Risk management is vital, even, nay especially, in software
development (You do want to keep your job, don't you? That can mean that a
pet project is axed by the Powers That Be to keep the company in
business..).

Agile is nothing more but risk management taken to the development team.
From YAGNI, via DRY, to TTD, it'S risk management.

Sure, a programmer won't need skills in risk management, business logic,
marketing, sales, or other social skills. A developer, though, does.

> Code obfuscation is one step of many to "keep honest people honest".
> Fighting a war with crackers will not end well, since there are more
> crackers out there than people writing an application.

Right idea but wrong formula. For every week spent securing code, a
cracker can spend an hour cracking it. That's just entropy - it's easier

to

destroy than create.

Add a blank line, introduce a new feature, run the obfuscator after your
build before shipping. Crack won't work anymore. :wink: Code obfuscation doesn't
(and shouldn't!) mean "I better rename my PatentedBusinessLogic class
Xxfghdofhdzsdfgdsb", but "Run a tool as part of my build7deplyoment process
to make the resulting built harder to read". Of course, less dynamic
languages like Ruby are better suited to this. And I don't think it is a
dealbreaker for using Ruby, either. :wink:

Of course, if you spend months on that Really Clever Method To End Software
Cracking, you are betting on the wrong horse.

And as I said: it is *one* step of keeping honest people honest. You won't
be able to best the crackers. Never will be. But you can raise the bar one
bit more to sell probably a lot more units. microISVs are specialists in
doing that. :wink:

Patrick McKenzie said it better than me, where this all fits into the bigger
picture:

about-registration-systems/

09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0, holmes. See you in
GITMO!

Exactly. The DMCA is something that happens to "other people, never me!", or
can backfire nastily (the Science Fiction and Fantasy Writer Association is
currently (ab)using the DMCA to hilarious effect), but it didn't really stop
file sharing, or copyright infringement, either.

It is a social problem. It is a) largely perceived as a victimless crime,
and b) the MPAA/RIAA and equivalents aren't really making it easy to take
them serious in their efforts. (See McKenzie's blog post for reasons :wink:

All in all, that doesn't mean you shouldn't protect your own IP, especially
if it is what guarantees your livelihood. This is less, much less, acute for
a bank's REST-API developer for intranet communication, than for somebody
who lives from the sales of his/her software.

···

--
Phillip Gawlowski

29

dima wrote:

The only solution is open source.

One word: Microsoft.
Another word: Oracle.

Open source is a nice thing, but by no means an "only solution". If it were,
the commercial software market as we know it would've been blown away by
now.

For one, simple reasons: Customers don't care about how you distribute your
software. They care about whether or not it works for them, and fits within
their budget.

The clever people will help you make a bright idea of yours great.

Ah, yes, much like GNU Hurd. :wink:
Every highly visible Open Source project is either backed by commercial
interests or was created by a company that couldn't stand up against the
completion anymore (Linux, Mozilla (formerly Netscape), or OpenOffice
(formerly, StarOffice)).

Open Source can work, but it is no silver bullet. Especially not, if your
business model isn't centered on services or consulting.

···

--
Phillip Gawlowski

30

You should think what is that you are selling.
I know it's not a code. Perhaps its solution, service, idea, time,
creativity but is definitely not a code.

Nah. Having the idea and the creativity is the easy
part.

The code and data is where all the hard work is.

If you build something that gain some successes do not think that you
can live from the past glory.

Huh? In what way is this relevant? Please consider how
id Software releases games.

Let's start with Quake (1996). id Software immediately
releases the GAME LOGIC and TOOLS as open source. But the
game ENGINE remains closed source.

Next, id Software release Quake II (end of 1997). Again,
the GAME LOGIC and TOOLS are released open source. But the
Quake II engine remains closed source.

BUT, now id Softare FULLY releases all of the original Quake
code open source. Now all of Quake I is open source.

Next, id Software releases Quake III (end of 1999.) Again,
the GAME LOGIC and TOOLS are released open source. But the
Quake III engine remains closed source.

BUT, now id Softare FULLY releases all of the Quake II
code open source. Now all of Quake II is open source.

Next, id Software release DOOM III (2005). Again, the GAME LOGIC and TOOLS are released open source. But the
DOOM III engine remains closed source.

BUT, now id Software FULLY releases all of the Quake III
code open source. Now all of Quake III is open source.

And last month in Dallas at QuakeCon 2007, id Software confirmed that eventually the DOOM III engine will be fully
released open source.

And they confirmed that even their newest technology,
id Tech 5, will eventually be released open source, too.

The current success is a history. You
should move to new challenges. Ones that try to mimic your solution
will always be one step behind.

This has NOTHING to do with open vs. closed source,
that I can see.

The only solution is open source.
The clever people will help you make a bright idea of yours great.

Open source is great. But it doesn't sound like you have
much experience developing and trying to make a living off
of shrink-wrap game or application software?

There's a _reason_ id Software waits a few years before releasing the engine open source.

Learning from their example, I plan to release my own
applications the same way. Initially, partly open source,
partly closed source. Then when I come out with V2.0,
I will open source ALL of V1.0. Etc.

To me, this is an excellent compromise, considering the
realities of software piracy.

Anyway, what do you think about the way id Software release
their games?

Regards,

Bill

···

From: "dima" <dejan.dimic@gmail.com>

31

Anyway, what do you think about the way id Software release
their games?

Regards,

Bill

Pretty fra off topic, but I admire the way Id tries to release most of their stuff as Mac/PC hybrid CD/DVD.
Smart.

As for the release and source release pattern... in the cutthroat world of computer gaming, it makes perfect sense!
Attract the modders and gamers with the tools to mod the game, eventually give it all away after the market is past that cutting edge of technical sophistication.

They probably even have the sense to check out what the OSS community's changes/additions to the code

32

I have impression that the subject is about source hiding and
preserving it from the others eyes. Hold it as a kind of advantage
over competition.

I spend last 14 years developing various solutions almost exclusively
in financial domain, stock exchanges, inter-bank trading and financial
institutions integrations, market data visualizations, data feed for
various data vendors, order entry and order rooting, building trading
systems and market data analysis.
I start as a developer and now I am a head of development. Clients of
mine are mostly banks, national banks, ministry of finance, ministry
of treasure and other government institutions, stock exchanges and
brokerage houses and such.

I think that I have a good sense about issue addressed here. My
clients are as paranoid about security as military or even more.

Nevertheless, the most precious thing you can posses are idea,
creativity, customer trust and people. Source code is not in this area
and it's changing all the times.

Creative developer that produces a solution is priceless in
correlation with code that he/she produce. If you loose the developer
you lose in a sense the code too.
I can elaborate on the subject but it's pointless.
And for the end just one thought: There was a time where people think
that earth was a round plate carried by the giant turtles - some still
do.

33

There is great truth in this. Code can be very much like poetry. Not everyone will like it or have a real handle on somebody else's style.

···

On Sep 2, 2007, at 1:35 PM, dima wrote:

Nevertheless, the most precious thing you can posses are idea,
creativity, customer trust and people. Source code is not in this area
and it's changing all the times.

Creative developer that produces a solution is priceless in
correlation with code that he/she produce. If you loose the developer
you lose in a sense the code too.

34

I have impression that the subject is about source hiding and
preserving it from the others eyes. Hold it as a kind of advantage
over competition.

Thanks for clarifying. I was engaging from a different angle,
as I am focusing on maximum number of users who register their
software.

Closed source sucks. Copy protection software measures suck
worse!

However these are used to varying degrees in the small utility
application and game market.

For example: The archive / unzip software with the splash dialog
that says, "You have been using this software for 987 days,
please consider registering."

Of course, one way to move the problem is to put key program
logic on a remote server; essentially, sell web-based app
services. But that option is out for both high performance
video games, and also for software that journalists carry
on their laptops where their internet connection is often
spotty, or nonexistent.

With the web-based software, one can provide enhanced
features only to registered users. With software like
high performance games or software which must be used
without a net connection, it is necessary to store the
full application logic on each client system.

Historically applications in this client side category
have met with difficulty distinguishing registered from
unregistered users.

Since I am used to thinking of this issue from a client
registration standpoint I actually assumed this was why
the OP was asking... Sorry if I was off-topic.

And for the end just one thought: There was a time where people think
that earth was a round plate carried by the giant turtles - some still
do.

"You're very clever, young man, very clever," said the old lady. "But
it's turtles all the way down!"

:slight_smile:

Regards,

Bill

···

From: "dima" <dejan.dimic@gmail.com>

35

Thanks for so many thoughts.

I'm guessing my next step in Ruby will be to try that RubyGems and see
how it works.

I like the idea where an application implements its most valuable part
(security) as closed source and the rest is left open. If the
application gets expected users then hopefully their contribution will
help developping more solutions for the clients or just increase the
application consistency.

Thanks again

···

--
Posted via http://www.ruby-forum.com/.

36

I like the idea where an application implements its most valuable part
(security) as closed source and the rest is left open.

Closed source security is a really, really bad idea. Security should
*never* be closed source. Two terms;
  peer review
  security by obscurity?

http://www.schneier.com/crypto-gram-0205.html#1

I haven't even read this article, but I'm trusting it to be agreeable,
since it's coming from Schneier. Please take a close look at it.
Security is important stuff.

Cheers,
  Arlen.

37

Arlen Christian Mart Cuss wrote:

I like the idea where an application implements its most valuable part
(security) as closed source and the rest is left open.

Closed source security is a really, really bad idea. Security should
*never* be closed source.

Alice and Bob are talking past each other here. (-;

The mechanisms to secure wires must be open source, at the forefront of computer science research. And don't forget those compromising radiations! When I was a kid the popularizations of science used to discuss masers frequently, but for some reason we don't hear very much about them any more...

The actual keys and codes, and the locations where a given program bypasses them, might be closed source.

···

--
  Phlip
  Test Driven Ajax (on Rails) [Book]
  "Test Driven Ajax (on Rails)"
  assert_xpath, assert_javascript, & assert_ajax

38

Alice and Bob are talking past each other here. (-;

Seems that way. :slight_smile: Watch out for Eve/your-variant-here!

The mechanisms to secure wires must be open source, at the forefront of
computer science research. And don't forget those compromising radiations!
When I was a kid the popularizations of science used to discuss masers
frequently, but for some reason we don't hear very much about them any
more...

I have no idea about masers? :slight_smile: But I still am a kid, so...

The actual keys and codes, and the locations where a given program bypasses
them, might be closed source.

I agree completely - but then I tend to lump the keys/code as
implementation/site-specific details, rather than as a part of the code
itself.

Even when developing an application for a single site, I tend to view
the project very strongly in terms of separating the base software and
implementation aspects, as strongly as your RoR programmer will try to
keep MVC separated. It's easier to maintain, and helps semantics like
this remain clear.

I think I digressed. My $0.02. :slight_smile:

- Arlen.

39

Arlen Christian Mart Cuss wrote:

I have no idea about masers? :slight_smile: But I still am a kid, so...

The data bus on your 'puter generally works in cleartext. Its clock turns it into a tiny little oscillating antenna, with a faint signature. A maser is a focused radar that can read this signature. So a file going over a DMA channel can leak a complete copy. Your monitor can leak its images, and your keyboard leaks all your gestures.

Much of the fun and games we hear about in the news derive from spooks playing mind games with each other, exploiting these toys.

···

--
  Phlip
  Test Driven Ajax (on Rails) [Book]
  "Test Driven Ajax (on Rails)"
  assert_xpath, assert_javascript, & assert_ajax

40

Phlip wrote:

Arlen Christian Mart Cuss wrote:

I have no idea about masers? :slight_smile: But I still am a kid, so...

The data bus on your 'puter generally works in cleartext. Its clock turns it into a tiny little oscillating antenna, with a faint signature. A maser is a focused radar that can read this signature.

Erm... no. A maser is a low-frequency laser; see http://en.wikipedia.org/wiki/Maser\. You're thinking of TEMPEST. Again, refer to the Tempest - Wikipedia for details. You don't need much focussing to do it - certainly not radar-level synthetic aperture, although I'm sure you'd want to do it that way if bulk data capture (or particularly long-range operation) was the goal...

···

--
Alex