Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple starts rejecting apps with “hot code push” features

forums.developer.apple.com

Post reply on HN
Print view View original

241–250 of 498 posts

Re: Apple starts rejecting apps with “hot code push” features

#241

Post by bigiain »

orless wrote: post #228
teknologist wrote: post #205

Earlier quoted context omitted.

In an ideal world where apps check/pin certificates and don't disable cert checks to make self-signed certs work in test environments you'd be right. If only this were reality.

I'm just pointing out that "remote resource ... could easily be hijacked via a MiTM attack" is technically incorrect. The problem is not the remote resource per se, the problem is trusting developers to implement secure loading of resources. Which is a completely different argument.

Depends on who you're expecting the MiTM attack to be executed by.

Are _you_ secured against, say, an attacker who works at Verisign and can create a valid cert for api.yourdomain.com? Or an attacker who has a buddy who works at GoDaddy who can subvert your dns records so they can trick LetsEncrypt into issuing a valid cert for api.yourdomain.com? Or an elbonian teenage hacker who's just got your AshleyMaddison assword from pastebin and used it to log into your Gmail account and overtaken your dns registrar account to get themselves a valid ssl cert?

Re: Apple starts rejecting apps with “hot code push” features

#242

Post by bigiain »

teknologist wrote: post #205
orless wrote: post #191

Earlier quoted context omitted.

I'm not buying the MITM argument in general. If remote code is downloaded via HTTPS, it could not be hijacked, at least not easily.

In an ideal world where apps check/pin certificates and don't disable cert checks to make self-signed certs work in test environments you'd be right. If only this were reality.

I suspect I've left a lot of test devices behind me with Charlesproxy MiTM root certs installed (I wouldn't be _too_ surprised if one of the phonee in my pocket right now has that...)

Re: Apple starts rejecting apps with “hot code push” features

#243

Post by je42 »

teknologist wrote: post #161
jameside wrote: post #135

Earlier quoted context omitted.

The key part of JSPatch is that it exposes arbitrary, uncontrolled access to native APIs. You could use it to call private APIs even because Objective-C doesn't distinguish between public and private APIs at runtime, so Xcode's compiler checks and Apple's static analysis can't anticipate which APIs are possibly called. In contrast, React Native doesn't expose uncontrolled access to native APIs. You write regular Obje…

I'm not sure why people are concerned about React Native being targeted by this new enforcement of the rule. It is not the same thing at all.

it shares some components. like javascriptcore.

difference is the js - native bridge. for react native it is fixed bridge, that can only change with a change in the binary.

for rollout they can execute any native code with an update of the JS.

Re: Apple starts rejecting apps with “hot code push” features

#244

Post by masklinn »

Angostura wrote: post #159
justinhj wrote: post #83

Earlier quoted context omitted.

Most likely most games are updating only game related data and graphics files. Very few games actually use internal scripting that would be needed to do code updates

The only app I've got that appears to actually update itself without going through the AppStore is the HSBC mobile banking app. I'd be interested in hearing the discussions going on between Apple and HSBC at the moment.

Supercell's games and a bunch of F2P collect-ish games also do that, when you open the game they have an update process. I'm reasonably sure that only updates static assets though, stuff like description files and graphic assets. It's actually pretty useful as it lowers the payload of the core engine and lets them do much smaller updates compared to having to bundle it all, that's especially important with things like Unity Frameworks which are not delta-updatable in the store (hence Hearthstone's 2GB downloads every time they add a cardback or nerf a pair of cards)

Re: Apple starts rejecting apps with “hot code push” features

#245

Post by je42 »

Illniyar wrote: post #72
marpstar wrote: post #45

Earlier quoted context omitted.

To date, Apple's Developer Program Guidelines states (in Section 3.3.2): > Except as set forth in the next paragraph, an Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exceptions to the foregoing are scripts and code downloaded and run by Apple's built-in Web…

RN runs with JavaScriptCore.

rollout as well...

Re: Apple starts rejecting apps with “hot code push” features

#246

Post by bigiain »

jsjohnst wrote: post #130
JohnBooty wrote: post #120

Earlier quoted context omitted.

> I'm guessing there are two things Apple is worried about. I'm sure it worries about them but there's a much larger, riskier scenario. Once you start downloading and executing binary code from untrusted sources (i.e., not the App Store) anything can go wrong. 1. An iOS app doesn't care about security, and it hot-loads code from some non-https source and gets man-in-the-middle'd 2. An iOS app hot-loads code in a secu…

> Now, I'm not a fan of Apple's policies. I think there should be a "guys, I know what I'm doing" mode where I'm allowed to download code from untrusted sources. This exists today and has for a long time, it just costs you money for this "privilege".

You can drop a .ipa file into iTunes and load/run the app on a phone that's syncing to that copy of iTunes...

Re: Apple starts rejecting apps with “hot code push” features

#247

Post by burntrelish1273 »

mahyarm wrote: post #162
ma2rten wrote: post #111

Earlier quoted context omitted.

You were relying on a huge loophole. The code runs inside JavascriptCore but it injects native code into the app.

An objc swizzle is not native code injection, it's a function pointer swap. They swizzle the method to their general objc message handler which then executes a piece of javascript code. For swift they basically patch the app before it gets compiled so that every function, if it meets the conditional would execute their javascript code handler instead. No binary code being injected.

Swizzling is incredibly useful. AFNetworking, MagicalRecord and GPGMail use it, just to name a few.

Re: Apple starts rejecting apps with “hot code push” features

#248

Post by bigiain »

ChuckMcM wrote: post #116
adjunct wrote: post #98

I'm Erez Rusovsky, the CEO of Rollout.io Rollout's mission has always been, and will always be about helping developers create and deploy mobile apps quickly and safely. Our current product has been a life saver for hundreds of apps by allowing them to patch bugs in live apps. We were surprised by Apple's actions today. From what we've been able to gather, they seem to be rejecting any app which utilizes a mechanism…

My guess is that somewhere in the giant dump of CIA malware there is an exploit that uses this to hijack an iPhone. They are pretty explicit about what they don't like and how it would be exploited.

I suspect unless they got advance notice from Wikileaks this reaction is too soon.

I'm wondering which of the current top-downloaded FlappyCrush Of Titans clone got caught exfiltrating all their players contact lists or something...

Re: Apple starts rejecting apps with “hot code push” features

#249

Post by throwanem »

jacobolus wrote: post #236
pjc50 wrote: post #217

Earlier quoted context omitted.

> ruff shot "Rough shod", before we get another mondegreen propagating across the internet.

To be more precise, the idiom is typically “ride roughshod over” rather than “run ...”, and roughshod is typically written as one word. Roughshod means the horseshoes have their nails sticking out the bottom to help prevent slipping, so you can imagine trampling someone with those could be painful.

Horses are heavy. Being trampled by one is going to be injurious or lethal regardless of whether or how it is shod. (Most horses will go far out of their way to avoid trampling a human, though; cavalry horses had to be carefully trained into it. Treading deliberately on one's foot is another matter, but, like some humans, some horses are just assholes.)

The idiom refers more to what a roughshod horse will do to a road or trail surface; the nailheads dig in and scatter surface material every which way, leaving behind a hell of a mess that'll turn to deep slush or sticky mud, depending on the temperature, with the next precipitation.

Re: Apple starts rejecting apps with “hot code push” features

#250

Post by beobab »

averagewall wrote: post #211
DaiPlusPlus wrote: post #188

Earlier quoted context omitted.

Recently Apple added (and actively encourages) the ability for developers to upload bytecode to the App Store instead of ARM binaries so Apple can more easily dynamically recompile for new architectures and optimisations. Of course bytecode is considerably easier to revert back into readable source-code (especially as Swift/ObjectiveC retain (some) symbol names in compiled output) - so it's not outside the realm of p…

Can you identify a type of app for which reverse engineering it would be easier than writing their own? Software is usually easier to write than to read. If an app has such a magic secret sauce, and it's of value, then it should be protected by patent or copyright anyway. An example that comes to mind is a high speed image compression app for taking rapid sequences of photos. Apple bought the company or the rights so…

In my experience, it's always been easier for me to implement something once I've seen a working example of it. That's basically what examples are for: A "cheat sheet" for reverse engineers.

Software is only easier to write than read if you have an idea what it's supposed to do. If you've ever googled "how do I do X?", then you likely have reverse engineered the answer you found to fit your particular use case.

In addition, and in some countries, you can't patent software (thankfully), and so innovation comes through reverse engineering naturally.

Post reply on HN