<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 24, 2014 at 10:30 PM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 25/01/2014 02:54, Sean Silva wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<br>
<br>
On Fri, Jan 24, 2014 at 3:33 PM, Alp Toker <<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a> <mailto:<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>>> wrote:<br>
<br>
<br>
On 24/01/2014 20:20, Stephen Crane wrote:<br>
<br>
On Fri, Jan 24, 2014 at 10:58 AM, Daniel Berlin<br></div><div class="im">
<<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a> <mailto:<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>>> wrote:<br>
<br>
On Thu, Jan 23, 2014 at 7:07 PM, Alp Toker <<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a><br></div><div><div class="h5">
<mailto:<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>>> wrote:<br>
<br>
It's a killer feature for anyone who has to support<br>
copy protection<br>
mechanisms in commercial software.<br>
<br>
For exactly how many seconds will that last? :)<br>
<br>
Software "cracks" are smart enough to find and patch<br>
patterns even when<br>
binaries change between releases, but nops and<br>
register shuffling will block<br>
the kind of automated "farming" organised criminals use.<br>
<br>
A feature that's so easy to deploy (just switch<br>
compiler flag every point<br>
release) is a valuable tool in giving the edge back to<br>
individuals and<br>
companies who have to earn some or all of their living<br>
through commercial<br>
software.<br>
<br>
Honestly, I think you are seriously overselling it, but<br>
that's not the<br>
main point i want to address:<br>
<br>
<br>
Who is going to be deploying this? If nobody is<br>
deploying, then how do we<br>
know it will be maintained? It seems like the<br>
initial patch submitter has<br>
already jumped ship on this patch; doesn't exactly<br>
inspire confidence.<br>
<br>
<br>
Clearly the two use cases are copy protection and<br>
security through obscurity<br>
so genuine users aren't going to be at liberty to join<br>
an open debate here.<br>
<br>
This I seriously disagree with. Even on the GCC mailing<br>
lists, there<br>
were plenty of people who were copy protection folks who<br>
spoke up<br>
about features that were going to be deprecated or added.<br>
The idea<br>
that "there are plenty of users, but they can't speak<br>
here" seems a<br>
bit suspect to me. Saying "this feature would be useful<br>
to us" is not<br>
something that harms either of the sets of users you are<br>
talking<br>
about, since it's completely and totally obvious that they<br>
are doing<br>
it anyway. There is no obscurity at all<br>
<br>
I think copy protection is a bit off-topic, but an interesting<br>
idea. I<br>
would like to point out that we were originally not targeting<br>
this at<br>
copy protection, and I think defending against code-reuse<br>
attacks is a<br>
much stronger use case and a better fit. Creating differing<br>
binaries<br>
could have interesting uses for watermarking, but we really<br>
haven't<br>
thought about that much. However, by creating unpredictable<br>
binaries<br>
<br>
<br>
<br>
Hi Stephen,<br>
<br>
That's a good observation. Clearly there are multiple use cases<br>
for the feature which is a good indicator that it has a place in a<br>
general-purpose backend like LLVM.<br>
<br>
I don't want to trivialise your work and its significance in the<br>
security field, but if I can get a few nops out of it that's<br>
already something that makes my life easier so I'm willing to<br>
support the effort and put in resource from our end (both as a<br>
commercial entity, and personally as a developer on the project)<br>
if we decide to go with this.<br>
<br>
There's every indication that a little unpredictability will go a<br>
long way to preventing the simplistic binary patching used in<br>
production-line software piracy operations. If we save 100 units<br>
from now to 2015 that already justifies the time we'd put into<br>
helping maintain the code with you upstream.<br>
<br>
<br>
Hi Alp,<br>
<br>
There seems to be significant disagreement whether what you describe is actually a real threat at all.<br>
</div></div></blockquote>
<br>
Yours is the first disagreement I've seen.<br></blockquote><div><br></div><div>C'mon man. Nadav, DannyB, and Joe all pretty much said "this isn't going to work" for copy protection.</div><div><br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If the contents of two similar builds A and B are made to vary then the binary patch developed for A will fail to apply to B without some degree of effort or analysis.<br>
<br>
Similarly if I share a developer preview of A with a third party and it shows up online, this gives me a good shot at guessing who did it and not trusting them next time round.<br></blockquote><div><br></div><div>It seems that for the use case you describe, there are so many simple ways to accomplish what you want that it is almost meaningless to represent this use case as a compelling motivation for adding this feature. I'm sure we can e.g. have LLD add a build ID or even develop a simple purpose-built feature to steganographically encode certain information in the binary, or shuffle sections/functions (35 functions or sections can be ordered in 35! (> 2^128) ways). I mean even GNU LD embeds a .note.gnu.build-id in all the binaries it creates.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
These aren't about copy protection -- they're simple properties that appear to have real world uses that exceed the original intent. They apply equally to Open Source, mixed and proprietary builds.<br>
<br>
As I see it, the gold standard for a feature is one that has use cases exceeding the original specification and intent. It's an indication that the feature will serve as a building block for other facilities.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Could you maybe provide some references or rope in another interested party? At this point you seem to be the only person getting behind this patch as a "killer feature" for copy protection.<br>
</blockquote>
<br></div>
I think either the statements above are trivially valid and make sense, or we've missed something and the use case doesn't hold, in which case the patches are blocked again.<br>
<br>
I could rope in plenty of people but that doesn't seem like a good way to answer the question at hand. We have all the facts and we should be able to figure it out for ourselves.<br></blockquote><div><br></div><div>This is really not the case. I don't feel like I have enough information to make an informed opinion about whether the use case you describe even *exists*, let alone whether this is the best way to approach it. At this point you seem to be the only person participating in this discussion that sees a threat consisting of (from what I can gather):</div>
<div>- "farms", which</div><div>- just blindly apply binary patches</div><div>- the cracks that they apply are basically just naive "sed"-style replacements that are trivially fooled by almost any modification of the binary</div>
<div>- that are a major source of lost revenue</div><div><br></div><div>-- Sean Silva</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Alp.<br>
<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
-- Sean Silva<br>
<br>
<br>
The patches look tidy and I feel it'll be a pleasure to work on.<br>
<br>
Alp.<br>
<br>
<br>
<br>
<br>
,<br>
we can defend against code-reuse attacks since these attacks<br>
require<br>
detailed knowledge of the attacked binary. This is not security<br>
through obscurity, since the attacker cannot exploit our<br>
defenses even<br>
if he knows to expect it. Instead, it more resembles protection by<br>
blinding or encrypting secret values (in this case, the binary<br>
layout).<br>
<br>
As such, users who are interested in protecting against code-reuse<br>
attacks such as return-oriented programming should be free to<br>
discuss<br>
and promote diversity, since it is a legitimate defense.<br>
<br>
- stephen<br>
<br>
<br>
-- <a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
______________________________<u></u>_________________<br>
llvm-commits mailing list<br></div>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a> <mailto:<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.<u></u>edu</a>><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
<br>
<br>
</blockquote><div class="HOEnZb"><div class="h5">
<br>
-- <br>
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
</div></div></blockquote></div><br></div></div>