5 ms·

AFAIK the combination of NSSelectorFromString and NSClassFromString would allow you to build and make calls from obfuscated strings during runtime. Since Object

by K0nserv 11y ago

AFAIK the combination of NSSelectorFromString and NSClassFromString would allow you to build and make calls from obfuscated strings during runtime. Since Objective-C uses message passing this is non trivial to catch. Compared to C were you must explicitly reference symbols that are easy to automatically check for detecting the use of third party APIs is more difficult. I am not sure if you have to explicitly link against certain frameworks/dylibs though, someone with more knowledge feel free to correct me

uxp 11y ago
The article touches on how to dynamically link into a framework/dylib at runtime with dlopen(3) and dlsym(3) to resolve it's symbols address space. I've always wondered why Apple doesn't run all apps against a "debug" build of iOS that asserts that the caller of private APIs is itself internal/private to Apple, but instead relies on something akin to grepping the output of strings(1)
- K0nserv 11y ago
  This seems like a good approach, but you can still get around it by detecting apple reviews and not doing anything with private APIs during them
  - kenrikm 11y ago
    It's quite trivial to setup a method that implements "NSSelectorFromString" [1] etc.. and have it read from a Json payload send from a server. It's very hard for Apple to check for that unless they have active monitoring on apps after the review process. [1] https://developer.apple.com/library/ios/documentation/General/Conceptual/DevPedia-CocoaCore/Selector.html https://developer.apple.com/library/ios/documentation/Genera...
    - NateLawson 11y ago
      Right. Any runtime behavior can be altered by observed state from outside the phone. There's even a paper on intentionally inserting security flaws into your code and then exploiting them from your own server to change execution patterns: https://www.usenix.org/conference/usenixsecurity13/technical-sessions/presentation/wang_tielei https://www.usenix.org/conference/usenixsecurity13/technical... Ultimately, you need to enforce access control instead of just trying to detect problems a priori. Apple's sandbox is a great start to that, and I expect they'll keep improving it to block apps like these.
      - jandrese 11y ago
        The state doesn't even have to be from outside the phone. You could have an internal timer that kicks off 2 weeks after you've submitted to the App Store (to allow for unexpected delays) and switches on the evil behavior.

by K0nserv 11y ago

uxp 11y ago

The article touches on how to dynamically link into a framework/dylib at runtime with dlopen(3) and dlsym(3) to resolve it's symbols address space. I've always wondered why Apple doesn't run all apps against a "debug" build of iOS that asserts that the caller of private APIs is itself internal/private to Apple, but instead relies on something akin to grepping the output of strings(1)

K0nserv 11y ago
This seems like a good approach, but you can still get around it by detecting apple reviews and not doing anything with private APIs during them
- kenrikm 11y ago
  It's quite trivial to setup a method that implements "NSSelectorFromString" [1] etc.. and have it read from a Json payload send from a server. It's very hard for Apple to check for that unless they have active monitoring on apps after the review process. [1] https://developer.apple.com/library/ios/documentation/General/Conceptual/DevPedia-CocoaCore/Selector.html https://developer.apple.com/library/ios/documentation/Genera...
  - NateLawson 11y ago
    Right. Any runtime behavior can be altered by observed state from outside the phone. There's even a paper on intentionally inserting security flaws into your code and then exploiting them from your own server to change execution patterns: https://www.usenix.org/conference/usenixsecurity13/technical-sessions/presentation/wang_tielei https://www.usenix.org/conference/usenixsecurity13/technical... Ultimately, you need to enforce access control instead of just trying to detect problems a priori. Apple's sandbox is a great start to that, and I expect they'll keep improving it to block apps like these.
    - jandrese 11y ago
      The state doesn't even have to be from outside the phone. You could have an internal timer that kicks off 2 weeks after you've submitted to the App Store (to allow for unexpected delays) and switches on the evil behavior.