FROM : Buddy Kurz
DATE : Thu Jan 16 19:22:37 2003
Isn't it a huge security problem if someone can override methods in any
application?
What if I override the method in Keychain which returns passwords and
send them to my server? What prevents someone from patching Safari or
Explorer to pop-up advertising or forward activity logs to someone?
I'm not usually paranoid (no matter what they say) but I would prefer
that my trusted applications remain trustworthy!
Any thoughts or reassurances on this?
On Thursday, January 16, 2003, at 09:10 AM, Sven A. Schmidt wrote:
> Adam,
>
> thanks a lot for you reply.
>
> On Donnerstag, Januar 16, 2003, at 05:20 Uhr, Adam Atlas wrote:
>
>> Hi Sven,
>>
>> libPatch is deprecated and unsupported. Its author, Ed Wynne, was
>> ordered to stop maintaining and distributing it by Apple (who he
>> works for). Not only that, but it is basically nonfunctional on Mac
>> OS X. A runtime-level modification you may want to look at is Method
>> Swizzling, posted on CocoaDev:
>> http://cocoadev.com/index.pl?MethodSwizzling
>
> I don't see how MethodSwizzling could replace the functionality I get
> from libPatch. libPatch allows me to load my bundle into the target
> application. Inside my bundle I use a category and MethodSwizzling to
> override the target object's original method.
>
> Are you saying that I can replace method implementations across
> application boundries, i.e. without having to load a bundle into an
> application? (Even with the current setup it probably wouldn't be hard
> to patch an installer with a text field category that pipes keystrokes
> to a file. I haven't tried libPatch on a root process yet, though.)
>
> As you can see from my follow up on my own mail, I got the whole thing
> working now, but I'm still very interested in any alternatives,
> especially since you indicate that there might be problems with
> libPatch.
>
> Thanks again,
> Sven
>
>> If that also doesn't work for you, you could license APE from
>> Unsanity. Licenses are free, if the product it is used in is
>> freeware. If you're only doing this within your own app (you don't
>> need your code to run in other programs), contact them about Ape
>> Lite, a shared-library version which is more lightweight and better
>> for that purpose. (Ape Lite is not listed on their site; you need to
>> contact them about it.) Before that, I do suggest you try Method
>> Swizzling.
>>
>> Since these things are more hacky than general discussion on this
>> list, I recommend the extendamac-macosx list for questions like this.
>> See http://lists.sourceforge.net/lists/listinfo/extendamac-macosx
> _______________________________________________
> cocoa-dev mailing list | <email_removed>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
DATE : Thu Jan 16 19:22:37 2003
Isn't it a huge security problem if someone can override methods in any
application?
What if I override the method in Keychain which returns passwords and
send them to my server? What prevents someone from patching Safari or
Explorer to pop-up advertising or forward activity logs to someone?
I'm not usually paranoid (no matter what they say) but I would prefer
that my trusted applications remain trustworthy!
Any thoughts or reassurances on this?
On Thursday, January 16, 2003, at 09:10 AM, Sven A. Schmidt wrote:
> Adam,
>
> thanks a lot for you reply.
>
> On Donnerstag, Januar 16, 2003, at 05:20 Uhr, Adam Atlas wrote:
>
>> Hi Sven,
>>
>> libPatch is deprecated and unsupported. Its author, Ed Wynne, was
>> ordered to stop maintaining and distributing it by Apple (who he
>> works for). Not only that, but it is basically nonfunctional on Mac
>> OS X. A runtime-level modification you may want to look at is Method
>> Swizzling, posted on CocoaDev:
>> http://cocoadev.com/index.pl?MethodSwizzling
>
> I don't see how MethodSwizzling could replace the functionality I get
> from libPatch. libPatch allows me to load my bundle into the target
> application. Inside my bundle I use a category and MethodSwizzling to
> override the target object's original method.
>
> Are you saying that I can replace method implementations across
> application boundries, i.e. without having to load a bundle into an
> application? (Even with the current setup it probably wouldn't be hard
> to patch an installer with a text field category that pipes keystrokes
> to a file. I haven't tried libPatch on a root process yet, though.)
>
> As you can see from my follow up on my own mail, I got the whole thing
> working now, but I'm still very interested in any alternatives,
> especially since you indicate that there might be problems with
> libPatch.
>
> Thanks again,
> Sven
>
>> If that also doesn't work for you, you could license APE from
>> Unsanity. Licenses are free, if the product it is used in is
>> freeware. If you're only doing this within your own app (you don't
>> need your code to run in other programs), contact them about Ape
>> Lite, a shared-library version which is more lightweight and better
>> for that purpose. (Ape Lite is not listed on their site; you need to
>> contact them about it.) Before that, I do suggest you try Method
>> Swizzling.
>>
>> Since these things are more hacky than general discussion on this
>> list, I recommend the extendamac-macosx list for questions like this.
>> See http://lists.sourceforge.net/lists/listinfo/extendamac-macosx
> _______________________________________________
> cocoa-dev mailing list | <email_removed>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
| Related mails | Author | Date |
|---|---|---|
| Sven A. Schmidt | Jan 16, 13:09 | |
| Adam Atlas | Jan 16, 17:20 | |
| Sven A. Schmidt | Jan 16, 18:10 | |
| Buddy Kurz | Jan 16, 19:22 | |
| Nicholas Riley | Jan 16, 20:29 | |
| Chris Hanson | Jan 16, 21:52 | |
| Sven A. Schmidt | Jan 17, 00:48 | |
| Jeff Disher | Jan 17, 01:48 | |
| Sven A. Schmidt | Jan 17, 11:43 | |
| Ralph Poellath | Jan 21, 22:21 | |
| Mike Ferris | Jan 28, 18:04 |






Cocoa mail archive

