3 ms·
I find it pretty hard to believe the iOS review monkeys have the technical ability to reason about the disassembly of a binary (if sufficiently obfuscated there
by blibble 16y ago
I find it pretty hard to believe the iOS review monkeys have the technical ability to reason about the disassembly of a binary (if sufficiently obfuscated there are maybe 1000 people tops on Earth with the ability to do this).
As long as the operating system has a dynamic linker all bets are off wrt. static analysis, and the halting problem definitely applies to automated analysis.
If the OS allows writable pages to ever be executable then you can pretty easily hide your nasty code in the low order bits of an innocent looking data file (say an image), then pull them out and execute them at runtime.
- robterrell 16y agoiOS doesn't allow writable pages to be executed. As I recall that was one reason why Android 2.2's V8 javascript JIT was so much faster than iOS's. Also, use of dlopen() is not allowed. A long time ago I heard of two AR apps that used it (they dynamically linked against CoreSurface, to copy the bits from the camera preview into an opengl texture) but I haven't heard of anyone sneaking an app using dlopen() into the store in over a year.
- blibble 16y agohence "to ever be executable", they don't need to be writable and executable, as long as at one point they are writable (for you to dump your code in), then at some point they're executable (writable or otherwise). as for dlopen(), you could just compile that directly into your app rather than using it from libc/libdl, bypassing that limitation entirely.
- darren_ 16y agoOn non-jailbroken iOS you can't mark a section of memory as executable once it has been writable (and vice-versa, apparently). Executable pages are also checked against a signature by the kernel before they're used.
- blibble 16y agothat's pretty incredible, I'm genuinely surprised. I suppose it's possible when you start from scratch, there's no way they could do that on the Mac.