3 ms·

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

by 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 uxp 11y ago

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.