[ChrisMarshallNY]

> Mintegral SDK uses a technique called method swizzling to replace implementations of the UIApplication openURL and SKStoreProductViewController loadProductWithParameters methods at runtime, as well it registers a custom NSURLProtocol class.

That's really clever. It looks like it uses ObjC dynamic linking to swap out calls[0].

When I read stuff like this, I'm glad that I'm a "dependency curmudgeon."

I'm not sure I would have figured this out, if I had vetted the dependency (Actually, I'm pretty sure I would have missed it).

I'm wondering if Apple would be able to detect this behavior, in their review process. There are certainly legitimate uses for it, but I like to avoid these types of hacks, in my shipping apps.

[0] https://nshipster.com/method-swizzling/

[woadwarrior01]

Method swizzling has been well known and used for as long as Objective C has been around. It's essentially Objective C's flavor of what other dynamic languages call monkey patching. I'm surprised that the App store review process didn't catch this, especially if the SDK was used by 1200 apps on the app store.

It reminds of something I'd done to get past the App store review a long time ago. This was when the iPad had just come out and UISplitViewController was super buggy. I found that the only way to get the universal app I was building to work satisfactorily on both the iPad and the iPhone was to use one of their undocumented methods. We submitted the app for review and as I'd half expected, it was rejected for using an undocumented API. The work around was to rot-13 the selector for the undocumented method and to decode it at runtime, dynamically call the method with performSelector. That made it pass the review. And that's when I learnt that the reviewers were probably just running strings (the unix program) and grep to find apps using undocumented APIs. That was a long time ago, I hope things have gotten better by now. :)

[xoa]

>That was a long time ago, I hope things have gotten better by now. :)

Reviewer techniques of course improve somewhat and evolve over time, but in terms of basic heavy reliance on automation and the like it's doubtful much has changed. But that's ok, because the battle is about economics and layers not perfection. The final layer is what HN has been so up in arms about: eventual detection after the fact, at which point Apple bans the devs and in extreme instances can revoke certs/delete the malware in question (all while its harm is limited by sandboxing/trust chains/etc). The $100/yr wall layer stops some automated attacking and makes anonymity more difficult, the signing requirements make it harder to avoid specific attribution, the restrictive permissions model and such stop some attacks, the review process maybe catches a few more and certain softer attacks, all of which combined hopefully reduces the final volume of what gets through and the value of what can be achieved with it vs consequences to a level where post-hoc response (the most expensive kind) can keep up. And the single market means the process is hard to avoid entirely, and the interests of users can collectively push back on the power of developers.

So no silver bullets, each layer has a part to play. That's kind of expected though isn't it? It's the typical trade off scalability vs specificity.

[toyg]

1200 "compromised" apps in appstore for more than 6 months (I can't find when 5.5.1 of the sdk was released, it was before 3 March), and you really want to spin this as a "success" of the enlightened-dictator model...?

[xoa]

It's astonishing in this day and age to see people like you who still think it statistically appropriate to toss out absolute numbers for comparative systems. As I wrote the expectation is not perfection but improving the economic balance, since all general security is an economic game. That 1200 number is utterly meaningless by itself, the comparison is what the numbers would be, what the compromise can accomplish on the system, and for how long, without any of these measures in place. A major goal of iOS is to allow the general population to go browse around and install absolutely anything they like the look of with minimal concern for what it might do. And it's a good goal, sacrilegious as it's proved to be amongst techies, even if unfortunately (though unsurprisingly) Apple has brought along unnecessary baggage with it. We should and could have done better first and preempted it, but collectively could not be bothered (or even outright mocked victims).

I'm not going to bother with rhetorical questions about the state of such things on Windows, macOS, Linux or whatever because we all damn well know the answer.

[toyg]

Ah yes, "think of the children", that marvel of rhetorical tools. You deny others their freedom, but it's "for the greater good". That always ends up so well.

The "state of such things" on other platforms, as dangerous as it might look to your paternalistic worldview, is what enabled the PC revolution in the first place. Had Microsoft or IBM enacted policies as draconian and illiberal as Apple is doing now, we likely wouldn't be talking on a free tcp connection using free browsers, right now. It's not by denying people their freedom that you reach progress and stability, but by educating them to make better choices for themselves.

But sure, spin it round and round. You and Apple are doing your best to keep back progress, but it's not going to last.

[alyssam_infosec]

It is a bit surprising but at the same time Mintegral did go through a number of steps to obfuscate the code to make it harder to see that it was impacting standard iOS SDK methods.

[wilsonrocks]

I didn't know about strings and I've been using Linux for years now. I like that there's lots still to learn.

I mean, there's a lot I don't understand about macOS but that's somehow less fun

[yonixw]

Google Firebase SDK swizzle too, so swizzle is allowed, from here it's a cat and mouse game.