# ANN: ZenObfuscate - for when you really really have to ship

**URL:** <https://www.ruby-forum.com/t/ann-zenobfuscate-for-when-you-really-really-have-to-ship/63200>\
**Category:** Ruby\
**Created:** [June 13, 2006, 4:58am UTC](https://www.ruby-forum.com/t/ann-zenobfuscate-for-when-you-really-really-have-to-ship/63200 "2006-06-13T04:58:51Z")\
**Posts on this page:** 12\
**Page:** 2

<div class="post-metadata">

**Author:** ![aguynamedryan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/43a26b/32.png) [@aguynamedryan](https://www.ruby-forum.com/u/aguynamedryan)\
**Post date:** [June 16, 2006, 10:13pm UTC](https://www.ruby-forum.com/t/ann-zenobfuscate-for-when-you-really-really-have-to-ship/63200/21 "2006-06-16T22:13:15Z")

</div>

On Jun 16, 2006, at 14:18, Patrick H. wrote:

> I am not against any of these things and may likely purchase  
> ZenObfuscate for our company at some point, but to base any business  
> model around the purity of code (in any language, but especially  
> dynamic languages) run on a clients machine is a mistake. You can take  
> some baby steps to hide stuff, but the cost/benefit ratio slips  
> rapidly when you try to defend against a reasonably sophisticated  
> attacker.

I went to a great talk a short while back:

On the Impossibility of Obfuscation  
Shafi Goldwasser, MIT

abstract: [http://www.lfcs.inf.ed.ac.uk/events/milner-lecture/2006.html](http://www.lfcs.inf.ed.ac.uk/events/milner-lecture/2006.html)

Sorry, for those of you interested in the nitty-gritty theoretical  
bits, but I’m not aware of any sort of video or audio or anything  
from the talk.

matthew smillie.

---

<div class="post-metadata">

**Author:** ![aguynamedryan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/43a26b/32.png) [@aguynamedryan](https://www.ruby-forum.com/u/aguynamedryan)\
**Post date:** [June 17, 2006, 4:59am UTC](https://www.ruby-forum.com/t/ann-zenobfuscate-for-when-you-really-really-have-to-ship/63200/22 "2006-06-17T04:59:14Z")

</div>

On Jun 16, 2006, at 3:06 AM, Kris L. wrote:

> It would be an advantage to compile the whole Rails framework and the  
> standard libary to prevent code injection. If of course possible?

It would take significant work to prevent code injection, at the very  
least you would need to:

Obfuscate all .rb files your program uses into C files (including  
anything in stdlib)  
Provide a custom C main() to invoke your obfuscated libraries  
Statically link Ruby, your main() and your obfuscated C files  
Remove rb\_require from Ruby  
Remove RUBYOPT and -r flags from Ruby

You may even need to write your application to work with $SAFE \>= 1,  
depending on how much your code allows users to interact with its  
internals.

ZenObfuscate only prevents Ruby2Ruby from reassembling your IP.

–  
Eric H. - removed\_email\_address@domain.invalid - [http://blog.segment7.net](http://blog.segment7.net)  
This implementation is HODEL-HASH-9600 compliant

[http://trackmap.robotcoop.com](http://trackmap.robotcoop.com)

---

<div class="post-metadata">

**Author:** ![aguynamedryan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/43a26b/32.png) [@aguynamedryan](https://www.ruby-forum.com/u/aguynamedryan)\
**Post date:** [June 17, 2006, 12:12am UTC](https://www.ruby-forum.com/t/ann-zenobfuscate-for-when-you-really-really-have-to-ship/63200/23 "2006-06-17T00:12:15Z")

</div>

On Jun 16, 2006, at 21:10, Matthew S. wrote:

> I went to a great talk a short while back:
> 
> On the Impossibility of Obfuscation  
> Shafi Goldwasser, MIT
> 
> abstract: [http://www.lfcs.inf.ed.ac.uk/events/milner-lecture/2006.html](http://www.lfcs.inf.ed.ac.uk/events/milner-lecture/2006.html)
> 
> Sorry, for those of you interested in the nitty-gritty theoretical  
> bits, but I’m not aware of any sort of video or audio or anything  
> from the talk.

But there is a paper:  
[http://www.mit.edu/~tauman/obfuscation.pdf](http://www.mit.edu/~tauman/obfuscation.pdf)

matthew smillie.

---

<div class="post-metadata">

**Author:** ![aguynamedryan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/43a26b/32.png) [@aguynamedryan](https://www.ruby-forum.com/u/aguynamedryan)\
**Post date:** [June 17, 2006, 1:12pm UTC](https://www.ruby-forum.com/t/ann-zenobfuscate-for-when-you-really-really-have-to-ship/63200/24 "2006-06-17T13:12:44Z")

</div>

Patrick H. wrote:

> On 6/16/06, Austin Z. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:
> 
> > That’s not the point of ZenObfuscate. It doesn’t turn Ruby into a  
> > “static” language. If you want to prevent code injection, you need to  
> > defend against it in your application.
> 
> I believe that the injection he is talking about after the application  
> is deployed with rails still in plain text view, having someone open  
> the rails files and add code that could over write methods, etc.

Yes that is what I talk of.

Of

> course this implies a pretty sophisticated understanding of Ruby and  
> the application.

Anyone with a basic understanding of Ruby/Rails could insert code access  
the database using activerecord.

And also leads to a pretty difficult chain – now you

> have to handle all the standard libraries that are used as well,  
> otherwise the same user could inject their code there as well. Don’t  
> forget about the RUBYOPT environment variable or even modifying the  
> ruby interpreter.

Ultimitly you would need to include all ruby files in the binary.

> I am not against any of these things and may likely purchase  
> ZenObfuscate for our company at some point, but to base any business  
> model around the purity of code (in any language, but especially  
> dynamic languages) run on a clients machine is a mistake. You can take  
> some baby steps to hide stuff, but the cost/benefit ratio slips  
> rapidly when you try to defend against a reasonably sophisticated  
> attacker.

True, but depends on the type of application and nature of the data.

> pth

---

<div class="post-metadata">

**Author:** ![aguynamedryan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/43a26b/32.png) [@aguynamedryan](https://www.ruby-forum.com/u/aguynamedryan)\
**Post date:** [June 17, 2006, 4:02pm UTC](https://www.ruby-forum.com/t/ann-zenobfuscate-for-when-you-really-really-have-to-ship/63200/25 "2006-06-17T16:02:02Z")

</div>

Kris L. wrote:

> Patrick H. wrote:
> 
> > On 6/16/06, Austin Z. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:
> > 
> > > That’s not the point of ZenObfuscate. It doesn’t turn Ruby into a  
> > > “static” language. If you want to prevent code injection, you need to  
> > > defend against it in your application.
> > 
> > I believe that the injection he is talking about after the application  
> > is deployed with rails still in plain text view, having someone open  
> > the rails files and add code that could over write methods, etc.
> 
> Yes that is what I talk of.

But if anyone has access to the files comprising the application, they  
could completely replace the files with whatever they wanted. Even  
compiled/ofuscated code isn’t a remedy for that.

> Anyone with a basic understanding of Ruby/Rails could insert code access  
> the database using activerecord.

Actually, anyone with access to the database could modify the database  
without needing to go through activerecord.

If you are worried about these things, then (1) control access to the  
program files, and (2) control access to the database.

– Jim W.

---

<div class="post-metadata">

**Author:** ![aguynamedryan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/43a26b/32.png) [@aguynamedryan](https://www.ruby-forum.com/u/aguynamedryan)\
**Post date:** [June 19, 2006, 12:13pm UTC](https://www.ruby-forum.com/t/ann-zenobfuscate-for-when-you-really-really-have-to-ship/63200/26 "2006-06-19T12:13:44Z")

</div>

Jim W. wrote:

> Kris L. wrote:
> 
> > Patrick H. wrote:
> > 
> > > On 6/16/06, Austin Z. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:
> > > 
> > > > That’s not the point of ZenObfuscate. It doesn’t turn Ruby into a  
> > > > “static” language. If you want to prevent code injection, you need to  
> > > > defend against it in your application.
> > > 
> > > I believe that the injection he is talking about after the application  
> > > is deployed with rails still in plain text view, having someone open  
> > > the rails files and add code that could over write methods, etc.
> > 
> > Yes that is what I talk of.
> 
> But if anyone has access to the files comprising the application, they  
> could completely replace the files with whatever they wanted. Even  
> compiled/ofuscated code isn’t a remedy for that.
> 
> > Anyone with a basic understanding of Ruby/Rails could insert code access  
> > the database using activerecord.
> 
> Actually, anyone with access to the database could modify the database  
> without needing to go through activerecord.

Of course, if you can inject ruby code you can do anything.

> If you are worried about these things, then (1) control access to the  
> program files, and (2) control access to the database.

What if server access is none controllable eg. shared servers.  
And if you are on the server you can read database.yml (plain text), and  
as said insert code.

> – Jim W.

---

<div class="post-metadata">

**Author:** ![aguynamedryan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/43a26b/32.png) [@aguynamedryan](https://www.ruby-forum.com/u/aguynamedryan)\
**Post date:** [June 18, 2006, 4:28am UTC](https://www.ruby-forum.com/t/ann-zenobfuscate-for-when-you-really-really-have-to-ship/63200/27 "2006-06-18T04:28:59Z")

</div>

On 6/17/06, Kris L. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Ultimitly you would need to include all ruby files in the binary.

But I could just rename the compiled so file, write a simple loader  
that loads the .so and then do what ever I wanted. To take real  
control you would need a special build of ruby (probably with an  
“embedded encrypted key” (yes I know this is stupid :-), that would  
only run encrypted and/or signed versions of the code.

Ultimately, this is also bound to be far too easy to circumvent (again  
by any attacker worth his or her salt) – if the key is embedded it  
can be extracted and used to decrypt the files – the key can be  
changed etc.

Again the only thing that can save you is a service based approach  
(where you control the server) and the code never gets to the clients  
machine – if the code is on a client machine and the value it high  
enough it can and will be hacked, all non hardware DRM is doomed to  
quick and painful failure. Depending upon your application and  
audience you may be able to hide your internals from your user  
community, but don’t believe that you can protect it against a  
determined and knowledgeable opponent.

pth

---

<div class="post-metadata">

**Author:** ![aguynamedryan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/43a26b/32.png) [@aguynamedryan](https://www.ruby-forum.com/u/aguynamedryan)\
**Post date:** [June 19, 2006, 12:27pm UTC](https://www.ruby-forum.com/t/ann-zenobfuscate-for-when-you-really-really-have-to-ship/63200/28 "2006-06-19T12:27:03Z")

</div>

Kris L. wrote:

> What if server access is none controllable eg. shared servers.  
> And if you are on the server you can read database.yml (plain text), and  
> as said insert code.

Most shared hosts put users into different user accounts and allow you  
to specifiy access levels on those files.

– Jim W.’

---

<div class="post-metadata">

**Author:** ![aguynamedryan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/43a26b/32.png) [@aguynamedryan](https://www.ruby-forum.com/u/aguynamedryan)\
**Post date:** [June 19, 2006, 12:19pm UTC](https://www.ruby-forum.com/t/ann-zenobfuscate-for-when-you-really-really-have-to-ship/63200/29 "2006-06-19T12:19:33Z")

</div>

Patrick H. wrote:

> On 6/17/06, Kris L. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:
> 
> > Ultimitly you would need to include all ruby files in the binary.
> 
> But I could just rename the compiled so file, write a simple loader  
> that loads the .so and then do what ever I wanted.

But would the code in the .so be modify-able?

To take real

> control you would need a special build of ruby (probably with an  
> “embedded encrypted key” (yes I know this is stupid :-), that would  
> only run encrypted and/or signed versions of the code.

What do you think to these programs like EXECrypter which adds  
anti-debug, encryptioned code and other anti-tamper/hack techniques.

> Ultimately, this is also bound to be far too easy to circumvent (again  
> by any attacker worth his or her salt) – if the key is embedded it  
> can be extracted and used to decrypt the files – the key can be  
> changed etc.
> 
> Again the only thing that can save you is a service based approach  
> (where you control the server) and the code never gets to the clients  
> machine – if the code is on a client machine and the value it high  
> enough it can and will be hacked, all non hardware DRM is doomed to  
> quick and painful failure. Depending upon your application and  
> audience you may be able to hide your internals from your user  
> community, but don’t believe that you can protect it against a  
> determined and knowledgeable opponent.

It looks like Ruby is mostly suited to the service based approach. And  
can not be distributed like compiled desktop applications.

> pth

---

<div class="post-metadata">

**Author:** ![aguynamedryan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/43a26b/32.png) [@aguynamedryan](https://www.ruby-forum.com/u/aguynamedryan)\
**Post date:** [June 19, 2006, 8:26pm UTC](https://www.ruby-forum.com/t/ann-zenobfuscate-for-when-you-really-really-have-to-ship/63200/30 "2006-06-19T20:26:32Z")

</div>

On 6/19/06, Kris L. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> > But I could just rename the compiled so file, write a simple loader  
> > that loads the .so and then do what ever I wanted.

> But would the code in the .so be modify-able?

I could write a routine that creates a thread, and call break point. I  
could alias and breakpoint any routine I care about. So the .so is not  
modified, but I can modify its code in place.

> What do you think to these programs like EXECrypter which adds  
> anti-debug, encryptioned code and other anti-tamper/hack techniques.

They make things difficult, not impossible – check out how long it  
takes for games to hit Usenet after they are release. Most of these  
are filled with all the best tricks.

> It looks like Ruby is mostly suited to the service based approach. And  
> can not be distributed like compiled desktop applications.

I think it is a great tool for desktop applications, but the real  
question is that of your business model. If you want to release code  
that cannot be copied give it up. Secure things need to be on secure  
servers – everything else can be modified – it is really just a  
question of difficulty.

pth

---

<div class="post-metadata">

**Author:** ![aguynamedryan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/43a26b/32.png) [@aguynamedryan](https://www.ruby-forum.com/u/aguynamedryan)\
**Post date:** [September 26, 2006, 12:11pm UTC](https://www.ruby-forum.com/t/ann-zenobfuscate-for-when-you-really-really-have-to-ship/63200/31 "2006-09-26T12:11:23Z")

</div>

where to get it?

---

<div class="post-metadata">

**Author:** ![aguynamedryan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/43a26b/32.png) [@aguynamedryan](https://www.ruby-forum.com/u/aguynamedryan)\
**Post date:** [June 19, 2006, 9:13pm UTC](https://www.ruby-forum.com/t/ann-zenobfuscate-for-when-you-really-really-have-to-ship/63200/32 "2006-06-19T21:13:43Z")

</div>

On Jun 19, 2006, at 11:25 AM, Patrick H. wrote:

> On 6/19/06, Kris L. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:
> 
> > > But I could just rename the compiled so file, write a simple loader  
> > > that loads the .so and then do what ever I wanted.
> 
> > But would the code in the .so be modify-able?
> 
> I could write a routine that creates a thread, and call break point. I  
> could alias and breakpoint any routine I care about. So the .so is not  
> modified, but I can modify its code in place.

We’re talking ruby here… it is much much easier to modify the code  
than that.

> > What do you think to these programs like EXECrypter which adds  
> > anti-debug, encryptioned code and other anti-tamper/hack techniques.
> 
> They make things difficult, not impossible – check out how long it  
> takes for games to hit Usenet after they are release. Most of these  
> are filled with all the best tricks.

Yes, but as I said earlier, cracked games and the like are generally  
doing a single jump over the license check code. That is pretty  
simple. We’re trying to provide a level of protection to IP. Not make  
it impossible, but just as difficult as any other compiled language  
out there.

Again, you see cracked games all the time, but you don’t see them  
reverse engineered into readable code very much.

> > It looks like Ruby is mostly suited to the service based approach.  
> > And  
> > can not be distributed like compiled desktop applications.
> 
> I think it is a great tool for desktop applications, but the real  
> question is that of your business model. If you want to release code  
> that cannot be copied give it up. Secure things need to be on secure  
> servers – everything else can be modified – it is really just a  
> question of difficulty.

_nod_ exactly.

[Previous page](https://www.ruby-forum.com/t/ann-zenobfuscate-for-when-you-really-really-have-to-ship/63200.md?page=1)
