CTFE and DI: The Crossroads of D

H. S. Teoh hsteoh at quickfur.ath.cx
Wed May 9 21:21:01 PDT 2012


On Wed, May 09, 2012 at 10:24:48PM -0400, Nick Sabalausky wrote:
> "H. S. Teoh" <hsteoh at quickfur.ath.cx> wrote in message 
> news:mailman.510.1336610145.24740.digitalmars-d at puremagic.com...
[...]
> > You don't necessarily have to throw away the DI system; some people
> > may sleep better at night if their proprietary algorithms are in
> > binary executable form only (though personally I think that's just
> > self delusion, but who am I to judge?).
> 
> An ambassador of sanity, that's who ;)
> 
> It's not just your personal opinion, it's hard fact: From a
> reverse-engineering standpoint, executable binary form *is* nothing
> more than obfuscation (except perhaps if it's an *encrypted* binary
> form, but I've never heard of a lib that did that, heck it would
> require special toolchain support anyway).

Encrypted binaries are still reverse-engineerable. Yes it may be very
hard, if you use the right encryption algorithms, but the hard and cold
fact is, if your CPU can run it, then it's reverse-engineerable. The
only thing that can't be reverse-engineered is something that can't run
on your CPU.


> Believing binary libs are more secure than that is just simply
> incorrect, period, opinion doesn't enter into it. 2+2 *is* 4 whether
> you believe it or not. Life isn't looney tunes, you don't walk on air
> just because nobody taught you gravity. Etc.

Well, it's not *that* black and white. Technically speaking, door locks
are useless because somebody determined enough to break into your house
will find a way (smash the lock or find a different entrance), no matter
what you do. That doesn't imply that you should just forget about door
locks (or doors, for that matter). A door lock isn't secure, technically
speaking, but it still keeps out the petty thieves. Doesn't stop the
professionals, but then 90% of thieves aren't professional. Ineffective
as it is, door locks do still keep out 90% of would-be breakers into
your house. So I'd say there's some value to be had there.

Binary libs *aren't* secure, if you're talking about ultimate security.
(If you want ultimate security, don't distribute your program. Period.
Then nobody will be able to reverse engineer it. Problem solved.) But it
does stop "petty thieves" from having their fun with it. And I daresay
90% of would-be code thieves aren't competent enough to know how to
reverse engineer a binary anyway (since otherwise they'd just write
their own code instead of stealing others' code). So it still does give
some amount of protection there.

Of course, there are a whole lot of other issues with binary-only
distributions (read Richard Stallman's biography for poignant examples
of that, etc.) -- which is why I don't believe in binary-only
distributions. But that doesn't mean some people don't find value in it.


[...]
> So source vs binary doesn't make a damn bit of difference, period - if
> all you have is the binary, well, to use it you just *run* it! You
> don't need *any* sources to use it. You just use it. The only thing
> that can even make any difference is encryption (which still isn't
> truly "secure").

Encryption only slows them down. It doesn't stop them if they are
determined enough.

And sometimes you don't *need* to break the encryption.  The fact that
the CPU eventually sees the decrypted code is good enough.  I've
personally traced encrypted bootloaders myself -- by running pieces of
them in what's effectively a crude sandbox of sorts, allowing them to
decrypt themselves/the subsequent stage and passing control back to me
each time, thus alleviating any need of breaking the encryption in the
first place.  Remember, as long as it can run on your CPU, it can be
reverse-engineered. You're just keeping out the petty thieves;
determined professionals will break in no matter what you do.


> And for that matter, nobody's algorithms are proprietary. Code is
> proprietary. 99.9999999...9999999% of algorithms are not. For example,
> wrapping some action in a foreach to make a batch processor and adding
> an option box to enable it is not a fucking proprietary algorithm no
> matter what the suits and the subhuman USPTO fuckwads think.
> Real-world example: There isn't a fucking thing proprietary in
> Marmalade's MKB build system (it's a stinking *build system* for fucks
> sake!).

Well, that's a different kettle o' fish. There are a lot of idiotic
patents out there (blame the PTO, blame the system, blame incompetent
employees, blame whatever). Personally, I hate the system, but there are
companies whose livelihood depends on keeping their l'il precious algos
safe under the covers. (Even if it's something known for 20 years in the
industry save to the one programmer of questionable repute who
re-invented it (poorly) under the auspices of said company.) I don't
believe in that kind of business model, but unfortunately many people
do.  It's a sad fact that in this day and age, patent-squatting is a
widespread practice in the IT sector. I've even heard that some
investors consider patent portfolio to be an important factor in a
company's value -- i.e., the more patents you hold, the more valuable
you are.

Yeah, life sucks. Deal with it.


> [...] *Only* thing it does is make it impractical for me to work
> around any problems I encounter.
[...]

Yeah, it doesn't solve the theft problem and screws over your customers.
What else is new in the corporate world?


T

-- 
To provoke is to call someone stupid; to argue is to call each other stupid.


More information about the Digitalmars-d mailing list