Hacker News Reader

Comment by lilyball | Hacker News Reader

I'm kind of surprised Apple's App Store checks don't reject any app that makes direct syscalls. Syscalls on Apple platforms are not a stable ABI, so all syscalls must go through libSystem, which means any app that makes a syscall directly instead of going through libSystem is doing something that it shouldn't.

Similarly I'm wondering why the author here searched through the code for `mov w16, #26` instead of searching for `svc 0x80`.

View on HN

`svc 0x80` is the command to execute any syscall, which syscall exactly is executed is based on the register x16, presumably the app make a very large amount of unrelated syscalls, so it wouldn't be useful to break on that, that's what he said in the video at least.

The whole point is the app is supposed to make zero syscalls directly, any syscalls that it makes are done by libSystem instead, and therefore the svc instruction should never occur in the app binary itself.

Compiler can sometimes inline syscall wrappers, so not that easy to check statically. For the same reason searching for SVC instructions would yield tons of results. If you search for the exact syscall ID moved into X16 you’d find it immediately.

But how can you safely inline a non-stable ABI?

The stable interface to syscalls on Apple platforms is libSystem, which is a dynamic library. Compilers cannot inline syscalls on Apple platforms as that would defeat the whole point of making libSystem the stable ABI. In fact, compilers don't even see libSystem itself when linking, they just see a .tbd file that lists all of libSystem's symbols.

Reply on news.ycombinator.com