These items like most of the others stop the casual hacker and the opportunistic thief. And make the code author feel a little safer.

What I’ve done to delay the hack is to require a serial number with the users email. The serial number is NOT generated by a script. When we get the confirmation email we generate the serial number and sent it out.

When the correct information is entered the program is allowed to run. When the incorrect information is entered the program is allowed to run!

Yeah, that sounds weird but the twist is the program doesn’t report the error/problem until days, weeks or months later! The point being, you don’t have to stop and report the error the milli-second it happens, that only helps the hacker.

It won’t stop them but it makes it really hard to debug and patch.

Also, never rely on only one validation check and don’t always use the same call. Sometimes I check in the awakeFromNib other time I check in one or more views. I have one program that check when it’s closing and reports a corruption error that requires a re-install!

The point being, you have to work just as hard to hinder (notice I didn’t say stop) the hacker as he does cracking your program.

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”

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.

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.

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.

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.