mikeash.com pyblog/friday-qa-2009-01-30-code-injection.html commentshttp://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsmikeash.com Recent CommentsFri, 29 Mar 2024 08:21:14 GMTPyRSS2Gen-1.0.0http://blogs.law.harvard.edu/tech/rssvikaspushkar - 2015-06-22 10:44:23http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsHow did you figured what are the function name inside the library which our custom functions would be replacing to?671fde3fa94d5b85b0c5b48f5d99c1a3Mon, 22 Jun 2015 10:44:23 GMTmikeash - 2009-03-19 11:28:59http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsThanks for the additional information. Too bad they have not seen fit to update the man page with this restriction sometime in the intervening eighteen months.b44831540ccfb990bee5a0545ce282acThu, 19 Mar 2009 11:28:59 GMTBill Johnson - 2009-03-19 11:26:55http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsFound a reference: <br /> <br /><a href="http://lists.apple.com/archives/apple-cdsa/2008/Feb/msg00014.html">http://lists.apple.com/archives/apple-cdsa/2008/Feb/msg00014.html</a>74a4c22639101e0d407c6473de479200Thu, 19 Mar 2009 11:26:55 GMTBill Johnson - 2009-03-19 10:58:47http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsJust checked this to make sure. You definitely still need to acquire the authorization right to use TFP, even if you're signed by a trusted cert.95d494bc7ebfc7a11ca59f15b5b11df4Thu, 19 Mar 2009 10:58:47 GMTBill Johnson - 2009-03-19 10:17:38http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#comments"Furthermore, on 10.5, it is no longer required to be root (or procmod) to access task_for_pid(). All you need to do is add SecTaskAccess to your Info.plist and fork over money for an official code signing certificate with which to sign your process. Somehow Apple thinks that if you have a "real" certificate you can't possibly use these facilities for evil." <br /> <br />Signed apps with trusted certs must acquire "system.privilege.taskport" authorization to use task_for_pid.61ac73ee5ae49fab4d27b643ac12178cThu, 19 Mar 2009 10:17:38 GMTJames Clough - 2009-03-18 18:21:01http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsThe "evil list" is just plain short, too: again I haven't tested these, but I'm fairly sure /bin/zsh and /usr/bin/tcl can be asked to listen to anything.8d2a46b5aff854e6b7affecccc13f42dWed, 18 Mar 2009 18:21:01 GMTmikeash - 2009-03-18 11:05:52http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsThird time's the charm, I hope.... <br /> <br />/usr/bin/nc has world read permissions set on it, which means it can be copied elsewhere. Doing so retains the code signature. However, since the firewall exclusion list is path-based, it won't catch the new copy of nc in its new location. So all a malicious app has to do is copy it somewhere else (like /tmp, or ~/Desktop) and execute it there, and it'll bypass the firewall. <br /> <br />You'd think that someone would have told Apple that maintaining an "evil list" was a bad idea.... <br /> <br />(Thanks to Jeff Johnson for figuring this one out.)dd4860e773cfc12113d0494d6e68d113Wed, 18 Mar 2009 11:05:52 GMTmikeash - 2009-03-18 10:37:00http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsTurns out that /usr/bin/nc is excepted from the free pass for signed applications. In /Library/Preferences/com.apple.alf.plist there's a key "explicitauths" which lists signed applications which should still prompt, and /usr/bin/nc is on it. And indeed, if you set the firewall to a restrictive mode and tell nc to listen on a port, you still get prompted. <br /> <br />This firewall is still foolishly holey, but it turns out that it's not <i>that</i> holey.dad3b0946e31228c072c78740a13ffdfWed, 18 Mar 2009 10:37:00 GMTmikeash - 2009-03-18 09:37:04http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsGood catch! I never thought it all the way through. End result: the Leopard firewall is 100% useless against all malicious code and any merely misguided code that is signed. The only protection it affords is against well-intentioned, unsigned apps. <br /> <br />Nice job, Apple!667c6610dc5f5d0a356348fda6a38783Wed, 18 Mar 2009 09:37:04 GMTJames Clough - 2009-03-18 06:34:08http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#comments<div class="blogcommentquote"><div class="blogcommentquoteinner">the firewall...always allows incoming connections to applications that have been signed</div></div> <br /> <br />And it's a little worse than that: /usr/bin/nc (among others) is signed and will listen on any port it's asked to836e0e669d615500a39ecb2a24443983Wed, 18 Mar 2009 06:34:08 GMTJean-Daniel Dupas - 2009-02-16 02:14:47http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#comments"Yeah, DYLD_FORCE_FLAT_NAMESPACE is not strictly required, just most interesting uses I've seen of DYLD_INSERT_LIBRARIES have been to overload symbols and so have indeed used a flat namespace [...] " <br /> <br />You don't have to do such thing to override a symbol. The dynamic linker also provide some facility to automatically override a symbol when the injected library is loaded. <br />This is called interposition. <br /> <br />Basically, to override NSApplicationMain, you can do something like this: <br /> <br />#define DYLD_INTERPOSE(_replacment,_replacee) \ <br />__attribute__((used)) static struct{ const void* replacment; const void* replacee; } _interpose_##_replacee \ <br />__attribute__ ((section ("__DATA,__interpose"))) = { (const void*)(unsigned long)&amp;_replacment, (const void*)(unsigned long)&amp;_replacee }; <br /> <br />DYLD_INTERPOSE(_SAApplicationMain, NSApplicationMain); <br /> <br />And then: <br /> <br />static <br />int _SAApplicationMain(int argc, const char **argv) { <br />// My interposed code. <br /> <br />// call original implementation <br />&nbsp;&nbsp;return NSApplicationMain(argc, argv); <br />} <br />3fb6e4b8cf65ec984e7836e2b86a2875Mon, 16 Feb 2009 02:14:47 GMTmikeash - 2009-02-05 00:34:52http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsI just remembered a much worse code-signing shenanigan on Leopard: the firewall, when placed in "Set access for specific services and applications" mode, always allows incoming connections to applications that have been signed with a certificate issued by a trusted authority, no matter what applications you actually have in the list*. <br /> <br />If you still think the people working on product security at Apple aren't complete idiots, then I would love to read your explanation for <i>that</i> policy. <br /> <br />* <a href="http://support.apple.com/kb/HT1810">http://support.apple.com/kb/HT1810</a>f35dbb366bf6d10c6facf6dabf81fae9Thu, 05 Feb 2009 00:34:52 GMTmikeash - 2009-02-04 23:57:27http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsAnti-virus companies are built around rapid reaction to threats. It is their core competence. Companies can move quickly, sometimes, if it is their core competence. Responding to malware is so far outside Apple's core competence you need a telescope to see it. And I don't know how rapidly CAs respond to revocation requests but I see no reason for that to be particularly fast either. <br /> <br />And then let's say, just for the sake of argument, that Apple identifies and reacts to the threat instantaneously, and that the CA responds to Apple's request instantaneously. What, exactly, is the mechanism for communicating the revocation to <i>my</i> computer? Is my machine phoning home to all of the CAs every day without my knowledge? <br /> <br />As for "You can preemptively not trust certificates from them and/or their issuing CAs." please don't be stupid. I appreciate intelligent discussion here, but I'm afraid this has lost it completely. I don't have a master list of "evil companies" to blacklist. What I would like is for my system not to trust software just because it has been signed. I personally do not take signing as any indication of trustworthiness. Apple apparently does, but the answer to this disagreement is <i>not</i> "oh, just blacklist the companies you don't like". What <i>would</i> be acceptable would be to <i>whitelist</i> the companies I <i>do</i> like. That's what the old Tiger mechanism provided, and making it to use signing information to prove exactly who is requesting privileges would be a reasonable enhancement. But making it use signing information to give carte blanche to anyone with a hundred bucks and a fake ID is <i>not</i> reasonable.5a9c590ef73a4a2ca9545c71ca223abbWed, 04 Feb 2009 23:57:27 GMTJeff Johnson - 2009-02-04 22:52:07http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#comments<div class="blogcommentquote"><div class="blogcommentquoteinner">You can preemptively not trust certificates from them and/or their issuing CAs.</div></div> <br />Damien, that's a great idea! Maybe we should delete every system root cert in our keychains! <br /> <br />65f23622a3ade6a3de791bf738b2d226Wed, 04 Feb 2009 22:52:07 GMTLord Anubis - 2009-02-04 18:44:48http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsThanks Mike, <br /> <br />Yes, I did give up then, but was and i'am still hoping for a trick. <br /> <br />LAb62a9bb418094b1daf26aca84e0b28d1Wed, 04 Feb 2009 18:44:48 GMTDamien Sorresso - 2009-02-04 14:46:50http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#comments<div class="blogcommentquote"><div class="blogcommentquoteinner">Revoking a certificate requires being damned sure that they're revoking something that needs it. It also requires becoming aware of the problem, getting that awareness to the right people, convincing them to put it at the top of their priority list, communicating with the CA, etc. Big organizations move slowly. And this all assumes that Apple has some person dedicated to dealing with revoking certificates of malicious programs, which I am virtually certain they do not. I find the idea that they could revoke a certificate and propagate said revocation out to the majority of Macs within 2-3 days of a worm showing up completely ridiculous. </div></div> <br /> <br />Why? Anti-virus companies have issued updated virus definitions within a day or two of an outbreak in the past. Big organizations can move quickly when needed. <br /> <br /><div class="blogcommentquote"><div class="blogcommentquoteinner">It's not like Adobe or Microsoft try to hide their products, I can just look for the "Adobe" or "Microsoft" in the name. And then of course there's the part where you've missed the whole point: it does me no good to be able to identify their products if the system leaves itself wide open for them.</div></div> <br /> <br />Not true. You can preemptively not trust certificates from them and/or their issuing CAs. <br /> <br /><div class="blogcommentquote"><div class="blogcommentquoteinner">But it's not a restriction. This API is less restricted on Leopard than it was on Tiger. That's not a restriction, that's a hole. </div></div> <br /> <br />It restricts who can use the API, so it's a restriction. There is a security <i>regression</i>, but that doesn't mean there is no restriction in place.e022fa93d74b071246982bd2be591cadWed, 04 Feb 2009 14:46:50 GMTmikeash - 2009-02-04 00:34:08http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#comments<b>Damien:</b> Revoking a certificate requires being damned sure that they're revoking something that needs it. It also requires becoming aware of the problem, getting that awareness to the right people, convincing them to put it at the top of their priority list, communicating with the CA, etc. Big organizations move slowly. And this all assumes that Apple has some person dedicated to dealing with revoking certificates of malicious programs, which I am virtually certain they do not. I find the idea that they could revoke a certificate <i>and</i> propagate said revocation out to the majority of Macs within 2-3 days of a worm showing up completely ridiculous. <br /> <br />"And a certificate lets you positively identify a piece of code as coming from Adobe or Microsoft." It's not like Adobe or Microsoft try to hide their products, I can just look for the "Adobe" or "Microsoft" in the name. And then of course there's the part where you've missed the whole point: it does me no good to be able to identify their products if the system leaves itself wide open for them. <br /> <br />"And this restriction allows them to leverage the ability to revoke certificates...." But it's <i>not</i> a restriction. This API is <i>less</i> restricted on Leopard than it was on Tiger. That's not a restriction, that's a hole. <br /> <br /><b>Lord Anubis:</b> Run your app as a user which is known to be clean of any such software, on a system with no input managers or any other such thing installed in /Library. UNIX's entire security model is based on preventing one user from messing with a different user. It has no real security against protecting one process of one user from meddling with another process of that same user. Things like the task_for_pid() restriction are really just small patches over this fact. <br /> <br />If you want to prevent code from being injected while running on a user's system you have no control over, give it up. Can't be done. Convince him to run it in a secure environment.33eb3bd157522dcdbb1ad7dc983462c1Wed, 04 Feb 2009 00:34:08 GMTLord Anubis - 2009-02-03 17:19:51http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsHi, <br />Nice article. Months ago I was looking for the opposite. <br /> <br />How can I avoid that some create code and injected it into my app with confidential information? How to avoid inputmanagers altering an app?bc92d90ec3e3cf6583474bfd1cb08338Tue, 03 Feb 2009 17:19:51 GMTDamien Sorresso - 2009-02-03 17:06:28http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#comments<div class="blogcommentquote"><div class="blogcommentquoteinner">- Even if Apple could convince a certificate authority to revoke a certificate on the basis of malware (which I'm dubious about), this will take a huge amount of time. I know of at least one extremely serious security hole in Leopard that Apple has known about, and has been sitting on, for several months. If it takes them this long to patch a flagship product, how fast are they going to move when a piece of malware hits a few users? </div></div> <br /> <br />Revoking a certificate doesn't require cross-functional engineering coordination or QA testing. Issuing an update takes more resources, so I don't really think the turnaround on one is a predictor for the turnaround on the other. <br /> <br />And why would they have trouble convincing a CA to revoke a certificate that signed malicious code? <br /> <br /><div class="blogcommentquote"><div class="blogcommentquoteinner">- Even if Apple moves fast, and the CA moves fast, we're still talking about days. By the time the certificate is revoked, the large part of the damage will have been done. </div></div> <br /> <br />Not at all. Worms spread at a geometric rate through the majority of their lifetimes and only slows toward the end. A lot of the more famous worms were running rampant for over a week. Revoking the certificate on Day 2 or Day 3 would make a huge difference. <br /> <br /><div class="blogcommentquote"><div class="blogcommentquoteinner">- An activity defined as Apple as "non-malicious" could be something I personally find "malicious". I certainly know that my decision to allow or deny code injection is completely unrelated to the author's ability to obtain a trusted code signing certificate. I'll happily trust code injection done by tiny indie companies, but I wouldn't touch such a thing coming from Microsoft or Adobe with a ten-foot pole. </div></div> <br /> <br />And a certificate lets you positively identify a piece of code as coming from Adobe or Microsoft. <br /> <br /><div class="blogcommentquote"><div class="blogcommentquoteinner">Requiring root for task_for_pid() on Tiger allowed the user to decide which programs could use it, which was a good thing. On Leopard they have now opened it up so that anyone with a bit of cash and an ID card can completely bypass my controls on it. They have, in essence, opened the hole back up that they had previously closed. This is bad. </div></div> <br /> <br />This is a more convincing argument. But my overall point is that the people working in security at Apple know what code signing is and what its uses are. And this restriction allows them to leverage the ability to revoke certificates, which is a change that propagates much faster than distributing a security patch.0326ac725fe2063424a1220e1193b8e0Tue, 03 Feb 2009 17:06:28 GMTmikeash - 2009-02-03 13:40:58http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsThat's a nice idea but I don't buy it at all: <br /> <br />- An organization creating malware will have little trouble getting an official certificate that doesn't lead back to them. Certificate authorities don't check credentials particularly thoroughly, and there's an unlimited supply of willing fronts to be found on the net. <br /> <br />- Even if Apple could convince a certificate authority to revoke a certificate on the basis of malware (which I'm dubious about), this will take a huge amount of time. I know of at least one extremely serious security hole in Leopard that Apple has known about, and has been sitting on, for several months. If it takes them this long to patch a flagship product, how fast are they going to move when a piece of malware hits a few users? <br /> <br />- Even if Apple moves fast, and the CA moves fast, we're still talking about days. By the time the certificate is revoked, the large part of the damage will have been done. <br /> <br />- An activity defined as Apple as "non-malicious" could be something I personally find "malicious". I certainly know that my decision to allow or deny code injection is completely unrelated to the author's ability to obtain a trusted code signing certificate. I'll happily trust code injection done by tiny indie companies, but I wouldn't touch such a thing coming from Microsoft or Adobe with a ten-foot pole. Requiring root for task_for_pid() on Tiger allowed the user to decide which programs could use it, which was a good thing. On Leopard they have now opened it up so that anyone with a bit of cash and an ID card can completely bypass my controls on it. They have, in essence, opened the hole back up that they had previously closed. This is bad. <br /> <br />In conclusion, requiring a trusted signing certificate adds zero security, and allowing code signed with such a certificate to use this API opens up a huge hole in the system. (One might wonder at the relevance of this hole, given the number of other injection mechanisms outlined above, but it's still big.) Somebody either wasn't thinking when they made this decision or, worse, they were thinking but they didn't have our best interests in mind.acef2671af88ba6203cfe556bc4c8ef9Tue, 03 Feb 2009 13:40:58 GMTDamien Sorresso - 2009-02-03 12:19:14http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#comments<div class="blogcommentquote"><div class="blogcommentquoteinner">Furthermore, on 10.5, it is no longer required to be root (or procmod) to access task_for_pid(). All you need to do is add SecTaskAccess to your Info.plist and fork over money for an official code signing certificate with which to sign your process. Somehow Apple thinks that if you have a "real" certificate you can't possibly use these facilities for evil.</div></div> <br /> <br />The folks working on product security at Apple aren't complete idiots. By forcing people to obtain a valid certificate from a CA trusted by Apple, they make use of task_for_pid() something that the developer is accountable for. If someone releases an app that abuses task_for_pid(), Apple can have the certificate revoked to limit the scope of its damage.fc7cfe5e83832ffd9b5e0525d1efe434Tue, 03 Feb 2009 12:19:14 GMTAnnard Brouwer - 2009-01-31 18:37:49http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsContextual menu plugins will load in any program that has a contextual menu and not only the Finder. I think Apple also indicated that these won't be supported in the near future.53cfd0b0061ae0c2d7a37aabf4a86a3fSat, 31 Jan 2009 18:37:49 GMTmikeash - 2009-01-31 10:18:45http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsYeah, method swizzling or class posing would be a way of avoiding flat namespaces, as would simply not overriding stuff (sometimes you just want to sit around and pop up windows, listen for notifications, or whatever). Mach_override would be a safe way to do it too, well, as safe as mach_override ever is. Safer than forcing your target into flat namespace, anyway.189af63c49728cdd4f7d840336d49befSat, 31 Jan 2009 10:18:45 GMTvasi - 2009-01-31 10:03:43http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsYeah, DYLD_FORCE_FLAT_NAMESPACE is not strictly required, just most interesting uses I've seen of DYLD_INSERT_LIBRARIES have been to overload symbols and so have indeed used a flat namespace. You can of course set globals or swizzle methods from a constructor function without needing DYLD_FORCE_FLAT_NAMESPACE. Maybe even use mach_override to safely overload symbols? <br /> <br />dd719f00d56e41e1ebcb9207e49b6161Sat, 31 Jan 2009 10:03:43 GMTmikeash - 2009-01-31 09:16:30http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsAre you sure about that? The man page states fairly explicitly that DYLD_INSERT_LIBRARIES won't allow overriding of existing symbols unless flat namespace is forced, but it doesn't say that DYLD_INSERT_LIBRARIES forces a flat namespace. Indeed it would make no sense to have such a warning if it did. <br /> <br />I believe that the interposing functionality that you can get in conjunction with DYLD_INSERT_LIBRARIES does force flat namespace, but it's not required to use that functionality when you use DYLD_INSERT_LIBRARIES.9e0ef8840bb3569227b7c76ed3ec2717Sat, 31 Jan 2009 09:16:30 GMTvasi - 2009-01-31 09:07:56http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsAnyone who uses DYLD_INSERT_LIBRARIES should be aware of one particular danger it holds, because it requires DYLD_FORCE_FLAT_NAMESPACE. <br /> <br />With a flat namespace, you can't have loaded multiple libraries that define the same symbol. This would mean a link failure at build time, and it used to mean a crash at runtime. Since 10.3, however, a runtime symbol conflict in a flat namespace will result in one definition silently overwriting the other. <br /> <br />So now you don't have to worry only about how your injected code affects the target app and its libraries. You're also causing each library in the process to potentially overwrite bits of other libraries. <br /> <br />Quite awhile ago I submitted a patch to dyld that would allow INSERT without FORCE_FLAT, but Apple never really did anything with it. (They basically recommended against using DYLD_INSERT_LIBRARIES, because it messes with the dyld cache.) I have no idea how well the patch applies to modern dyld, but if anybody's interested: <a href="http://vasi.dyndns.org:3128/trac/changeset/567/dyld">http://vasi.dyndns.org:3128/trac/changeset/567/dyld</a> <br /> <br />0015cc8412f1054f9ca7e2caebc2304dSat, 31 Jan 2009 09:07:56 GMTmikeash - 2009-01-31 07:45:53http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsIt's not true that all code injection functionality has been blocked to always require root. As two examples, scripting additions can be installed in ~ without root privileges, and DYLD_INSERT_LIBRARIES can be used without root as long as it's applied individually, not globally. <br /> <br />Furthermore, on 10.5, it is no longer required to be root (or procmod) to access task_for_pid(). All you need to do is add SecTaskAccess to your Info.plist and fork over money for an official code signing certificate with which to sign your process. Somehow Apple thinks that if you have a "real" certificate you can't possibly use these facilities for evil.28ebbc9011b5238734f47b0754601e83Sat, 31 Jan 2009 07:45:53 GMTmillenomi - 2009-01-31 06:08:59http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsNote: All code injection techniques have been blocked by 10.5 so that root privileges are required. The following is true: <br /> <br />&nbsp;- task_for_pid() requires a process running as the root user or the setgid group since 10.4 for Intel (not 10.4 for PPC). Additionally, code signed with a trusted certificate can also use task_for_pid() after the user enters an admin password at an elevation prompt. <br /> <br />&nbsp;- InputManagers in 10.5 are deprecated; they can still be used so long that they're placed in /Library/InputManagers and owned by root with 0644/0755 privileges. <br /> <br />&nbsp;- DYLD_INSERT_LIBRARIES in the ~/.MacOSX/Environment.plist file (that describes the environment variables for all apps launched through LaunchServices for a particular user) is silently filtered away. <br /> <br />Code injection is a security risk that can be used for a lot for interesting and evil things: see <a href="http://www.schneier.com/blog/archives/2009/01/interview_with_10.html">http://www.schneier.com/blog/archives/2009/01/interview_with_10.html</a> -- or just think of circumvention of Keychain ACLs. <br /> <br />I make a mach_inject high-level wrapper that runs on 10.5 and "adapts" SIMBL-style extenders while abstracting all the mach_injectness away. It's called PlugSuit: <a href="http://infinite-labs.net/plugsuit/">http://infinite-labs.net/plugsuit/</a>. <br /> <br /> <br />968ed96854785ab614ce3570bdb9ae6bSat, 31 Jan 2009 06:08:59 GMTDAS - 2009-01-31 05:28:52http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsone awk for the price of two greps an one awk: ;-) <br /> <br />`ps x | awk '/[S]afari/ {print $1}'` <br />b320d7d75b085cc9a54a01e2a765b5f7Sat, 31 Jan 2009 05:28:52 GMTmikeash - 2009-01-31 05:20:09http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsYeah, that's a good option that I just plain forgot about. It has the downside of requiring you to launch the target application directly (can't grab an app that's already running, or one that the user starts himself) but it has the great upside of being well supported.73f6b07fac27bdcdc9c2bcc31b8b3af4Sat, 31 Jan 2009 05:20:09 GMTChad Sellers - 2009-01-31 03:10:01http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-30-code-injection.html#commentsOne option you left out is letting dyld (the dynamic linker) insert your code in. Setting DYLD_INSERT_LIBRARIES can be useful in getting dyld to load your library. I've used this to override functions found in system libraries in certain apps.5fda9710771275160dc902dfa9629b72Sat, 31 Jan 2009 03:10:01 GMT