<div dir="ltr">hi nadav,<div><br></div><div>if i understand correctly, you are thinking of an offensive scenario where nops are used to camouflage malware. i agree that its easy to generate signatures by simply filtering nops out of the instruction stream. however this is not so in defensive scenarios where the goal is to detect piracy or thwart automated reversing/cracking. in particular, removing nops from a binary requires disassembly which to my knowledge creates a non-negligible overhead versus the performance of the original binary.</div>


<div><br></div><div>the security properties of nop insertion is well established in the security community. modern attacks rely on code reuse rather than code injection. code reuse attacks typically uses so called gadgets which are short instruction sequences ending in a return. the attacker must know the address of the gadgets for the attack to work. if we think about the first gadget in a binary you are right that nop insertion may just create a sled before it. however, subsequent gadget addresses are displaced by an amount equal to the sum of all preceding nops; in other words, the more nops inserted in front of a gadget, the greater the uncertainty in its location. secondly, some gadgets are composed of unintended instructions (i.e., jumping into the middle of an instruction generated by the compiler) and these gadgets are typically "broken/mutated" by nop insertion. our research group, and others, have performed detailed studies using a set of purpose built binary analyses to verify these effects. i recommend section 3 and 5.2 in [1] if you are interested in the gory details. </div>


<div><br></div><div>best,</div><div>per</div><div><br></div><div>[1] <a href="http://www.ics.uci.edu/~ahomescu/multicompiler_cgo13.pdf" target="_blank">http://www.ics.uci.edu/~ahomescu/multicompiler_cgo13.pdf</a></div><div class="gmail_extra">


<br><br><div class="gmail_quote">On Thu, Jan 23, 2014 at 10:19 PM, Nadav Rotem <span dir="ltr"><<a href="mailto:nrotem@apple.com" target="_blank">nrotem@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div style="word-wrap:break-word"><div><br><div><div>On Jan 23, 2014, at 9:57 PM, Alp Toker <<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>> wrote:</div><br><blockquote type="cite"><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">


<span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">The feature is sufficient to decisively thwart the recent trend of "farming" sites that crawl, scrape and reapply cracks within hours of each new point release. These automated attacks will never do decompilation or analysis -- they just search and replace byte patterns.</span></blockquote>


<blockquote type="cite"><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">


<span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Reverse engineers aren't cheap to hire and these sites are only profitable because they're automated.</span></blockquote>


<br></div></div><div>The original intent of the patch was to prevent Return-to-Program attacks, so this is slightly off-topic.  The security industry is a lot mode advanced than what you describe. It is really easy to remove NOPs in order to get signatures, and modern anti viruses do stuff like that. Actually, even if you completely change register allocation and scheduling other techniques would identify the code. For example tracking the order of system calls and/or library calls. Personally, I don’t think that adding NOPs to the instruction stream is as useful as changing scheduling or register allocation because removing NOPs is easy. Also, by introducing NOPs you are increasing the landing area for ROP attacks. You simply have more code to jump into.  </div>


</div></blockquote></div><br></div></div>