<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: 3 Easy Tips to Prevent a Binary Crack</title>
	<atom:link href="http://www.seoxys.com/3-easy-tips-to-prevent-a-binary-crack/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.seoxys.com/3-easy-tips-to-prevent-a-binary-crack/</link>
	<description></description>
	<pubDate>Fri,  5 Dec 2008 16:13:17 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: Mecki</title>
		<link>http://www.seoxys.com/3-easy-tips-to-prevent-a-binary-crack/#comment-3741</link>
		<dc:creator>Mecki</dc:creator>
		<pubDate>Thu, 17 Jul 2008 12:06:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.seoxys.com/?p=88#comment-3741</guid>
		<description>Codesigning buys you nothing! If the binary is modified, the signature becomes invalid... that's it. That's all that happens. It won't have any effect other than that. Who cares for an invalid signature? Apps with invalid sig will run just fine!!! And almost nobody understood the KILL flag. An app with invalid sig will run just fine, even with KILL flag. The KILL flag only means it will be killed if the running app in memory somehow loses its identity (e.g. it would be killed if a process was modifying the app in memory), but it will still start when modifying it on disk (try it, if you don't believe me).

Apple has no plans to change that either! They say "Why would we want to do this? A hacker could just patch your app and then resign it with his own signature and it will have a valid sig again. Okay, you could write code that checks if the signature is valid *AND* if the signature is signed by your cert, but the hacker could just replace this piece of code, too"</description>
		<content:encoded><![CDATA[<p>Codesigning buys you nothing! If the binary is modified, the signature becomes invalid&#8230; that&#8217;s it. That&#8217;s all that happens. It won&#8217;t have any effect other than that. Who cares for an invalid signature? Apps with invalid sig will run just fine!!! And almost nobody understood the KILL flag. An app with invalid sig will run just fine, even with KILL flag. The KILL flag only means it will be killed if the running app in memory somehow loses its identity (e.g. it would be killed if a process was modifying the app in memory), but it will still start when modifying it on disk (try it, if you don&#8217;t believe me).</p>
<p>Apple has no plans to change that either! They say &#8220;Why would we want to do this? A hacker could just patch your app and then resign it with his own signature and it will have a valid sig again. Okay, you could write code that checks if the signature is valid *AND* if the signature is signed by your cert, but the hacker could just replace this piece of code, too&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ctwise</title>
		<link>http://www.seoxys.com/3-easy-tips-to-prevent-a-binary-crack/#comment-3725</link>
		<dc:creator>ctwise</dc:creator>
		<pubDate>Mon, 30 Jun 2008 12:55:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.seoxys.com/?p=88#comment-3725</guid>
		<description>PT_DENY_ATTACH doesn't work to stop hackers.  The people who want to hack your code will have the knowledge and know-how to load the kext.  The only people who will be affected by the PT_DENY_ATTACH will be the people who have a legitimate desire to understand their systems and incorrect behaviors that they are trying to track down.  Those people will be forced to either uninstall your application, live with the problems or install a kext they don't actually want or need in order to solve their issues.  In other words, PT_DENY_ATTACH doesn't stop hackers and pisses off some of your customers.

Sign your code instead.  Use techniques and tools that obfuscate and encrypt your code.  Just don't make the system opaque to understanding.  That path takes us back to Windows.</description>
		<content:encoded><![CDATA[<p>PT_DENY_ATTACH doesn&#8217;t work to stop hackers.  The people who want to hack your code will have the knowledge and know-how to load the kext.  The only people who will be affected by the PT_DENY_ATTACH will be the people who have a legitimate desire to understand their systems and incorrect behaviors that they are trying to track down.  Those people will be forced to either uninstall your application, live with the problems or install a kext they don&#8217;t actually want or need in order to solve their issues.  In other words, PT_DENY_ATTACH doesn&#8217;t stop hackers and pisses off some of your customers.</p>
<p>Sign your code instead.  Use techniques and tools that obfuscate and encrypt your code.  Just don&#8217;t make the system opaque to understanding.  That path takes us back to Windows.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jerry Krinock</title>
		<link>http://www.seoxys.com/3-easy-tips-to-prevent-a-binary-crack/#comment-3722</link>
		<dc:creator>Jerry Krinock</dc:creator>
		<pubDate>Sun, 29 Jun 2008 12:41:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.seoxys.com/?p=88#comment-3722</guid>
		<description>Ah, Kevin, you are correct.  Being an Xcode GUI user, I missed the tiny letter 'r' in your article.  Also, I was fooled by the fact that when I run gdb it does that "Reading symbols for shared libraries ++++++" twice, both before and after I 'run'.  Oh, well.

So, I re-ran the test, typed 'r' and got an 055 exit.  Then I unzipped an old version of my app which was not compiled with the call to ptrace PT_DENY_ATTACH, attached to it, typed 'r', and gdb continued to work.  So, I take back what I said yesterday.

Thanks, Kenneth.

Also, regarding the original comment by ctwise, I don't believe that the "makes...impossible" applies to your machine.  #ifdef DEBUG, everything is back to normal.  Regarding the workaround, of course, if one hacks the system, anything is possible.  PT_DENY_ATTACH just sets up another hurdle for some hacker who may be seriously thinking of not drinking another Coke and going to bed instead.</description>
		<content:encoded><![CDATA[<p>Ah, Kevin, you are correct.  Being an Xcode GUI user, I missed the tiny letter &#8216;r&#8217; in your article.  Also, I was fooled by the fact that when I run gdb it does that &#8220;Reading symbols for shared libraries ++++++&#8221; twice, both before and after I &#8216;run&#8217;.  Oh, well.</p>
<p>So, I re-ran the test, typed &#8216;r&#8217; and got an 055 exit.  Then I unzipped an old version of my app which was not compiled with the call to ptrace PT_DENY_ATTACH, attached to it, typed &#8216;r&#8217;, and gdb continued to work.  So, I take back what I said yesterday.</p>
<p>Thanks, Kenneth.</p>
<p>Also, regarding the original comment by ctwise, I don&#8217;t believe that the &#8220;makes&#8230;impossible&#8221; applies to your machine.  #ifdef DEBUG, everything is back to normal.  Regarding the workaround, of course, if one hacks the system, anything is possible.  PT_DENY_ATTACH just sets up another hurdle for some hacker who may be seriously thinking of not drinking another Coke and going to bed instead.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kenneth</title>
		<link>http://www.seoxys.com/3-easy-tips-to-prevent-a-binary-crack/#comment-3721</link>
		<dc:creator>kenneth</dc:creator>
		<pubDate>Sun, 29 Jun 2008 08:37:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.seoxys.com/?p=88#comment-3721</guid>
		<description>Jerry, I just emailed you the .app.

Note that gdb still loads, but won't let you run. So if you load gdb with the executable, it will work, read symbols and everything. However, it's when you "run" that the app exits with code 055 every time.</description>
		<content:encoded><![CDATA[<p>Jerry, I just emailed you the .app.</p>
<p>Note that gdb still loads, but won&#8217;t let you run. So if you load gdb with the executable, it will work, read symbols and everything. However, it&#8217;s when you &#8220;run&#8221; that the app exits with code 055 every time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jerry Krinock</title>
		<link>http://www.seoxys.com/3-easy-tips-to-prevent-a-binary-crack/#comment-3720</link>
		<dc:creator>Jerry Krinock</dc:creator>
		<pubDate>Sun, 29 Jun 2008 05:59:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.seoxys.com/?p=88#comment-3720</guid>
		<description>I tried this but gdb still attached.  Maybe it's because I'm using Xcode 3.0, with an earlier version of gdb than you have?

GNU gdb 6.3.50-20050815 (Apple version gdb-768) (Tue Oct  2 04:07:49 UTC 2007)

I'm pretty sure I did it correctly.  To make sure that the #ifdef was working (actually I used #ifndef), I logged a compiler #warning just above the call to ptrace(), and it did log.   If you send me, or post, your ProtectionSample, I'll see if my gdb can attach to it.</description>
		<content:encoded><![CDATA[<p>I tried this but gdb still attached.  Maybe it&#8217;s because I&#8217;m using Xcode 3.0, with an earlier version of gdb than you have?</p>
<p>GNU gdb 6.3.50-20050815 (Apple version gdb-768) (Tue Oct  2 04:07:49 UTC 2007)</p>
<p>I&#8217;m pretty sure I did it correctly.  To make sure that the #ifdef was working (actually I used #ifndef), I logged a compiler #warning just above the call to ptrace(), and it did log.   If you send me, or post, your ProtectionSample, I&#8217;ll see if my gdb can attach to it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: scrod</title>
		<link>http://www.seoxys.com/3-easy-tips-to-prevent-a-binary-crack/#comment-3713</link>
		<dc:creator>scrod</dc:creator>
		<pubDate>Fri, 27 Jun 2008 21:44:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.seoxys.com/?p=88#comment-3713</guid>
		<description>When running on leopard you can use code signing and force a static validation of your app at launch time or set the KILL flag and wait for it to become dynamically invalid as resources and pieces of the executable are paged-in. This will be less work and significantly more thorough than implementing your own system from the ground up.</description>
		<content:encoded><![CDATA[<p>When running on leopard you can use code signing and force a static validation of your app at launch time or set the KILL flag and wait for it to become dynamically invalid as resources and pieces of the executable are paged-in. This will be less work and significantly more thorough than implementing your own system from the ground up.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ctwise</title>
		<link>http://www.seoxys.com/3-easy-tips-to-prevent-a-binary-crack/#comment-3712</link>
		<dc:creator>ctwise</dc:creator>
		<pubDate>Fri, 27 Jun 2008 11:24:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.seoxys.com/?p=88#comment-3712</guid>
		<description>Please avoid PT_DENY_ATTACH.  Not only is it easily circumventable (http://landonf.bikemonkey.org/code/macosx/Leopard_PT_DENY_ATTACH.20080122.html) but it makes monitoring and understanding YOUR OWN MACHINE impossible.</description>
		<content:encoded><![CDATA[<p>Please avoid PT_DENY_ATTACH.  Not only is it easily circumventable (http://landonf.bikemonkey.org/code/macosx/Leopard_PT_DENY_ATTACH.20080122.html) but it makes monitoring and understanding YOUR OWN MACHINE impossible.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
