I'm still not convinced. Even something like early VMware that scanned for the gnarly pieces that break Popek&Goldberg but just passes through most instructions should be better. In this case probably just syscall, some crazy system register reads that might return different things (but there aren't many of those in AArch64 EL0), and enough thunks that code can pretend it's executing at it's original location. Hell, equally sized RISC instructions should mean you can more quickly scan code than VMWare had to put up with doing crazy CISC decode just find out if they need to translate an instruction or not.

You can't do the thing you are suggesting because that would require being able to take those instructions that are being "passed through" and run them, which would require marking them executable. What you would effectively end up having to do is write an emulator for ARM, at which point you haven't gained anything. Choosing x86 was a really sane choice given how many existing tools and packages are available for x86 (though ARM is, of course, becoming more popular and accessible).

>because that would require being able to take those instructions that are being "passed through" and run them

Isn't this just a matter of writing it to some page and then setting the RX bit?

The ability to mark a page executable would defeat Apple's codesign feature, so a normal developer definitely can't do that.

It's basically the easiest way of treating data as instructions, sort of like executing a compiled program as you would with an interpreted language?

> Isn't this just a matter of writing it to some page and then setting the RX bit?

Yes, but this is not easy to do on iOS: you need certain entitlements to perform this operation.

Likewise.

Obviously it's not as simple as in Android where you're already inside a Linux shell under the covers, but there's no technical requirement I've read here that should mandate emulation.

Aside from the above, the syscall layer alone would be much more useful than bundling emulation into the picture that we know is going to perform poorly.

An aarch64 Linux rootfs on the A12x would have me throwing my money at one right now.

> there's no technical requirement I've read here that should mandate emulation

I mean, what's wrong with the requirements that I mentioned? It's fundamentally impossible to run these binaries unaltered and still hook syscalls, which means that emulation is required.

You're confidence about this makes me not doubt that you're correct, but the linked thread doesn't really discuss this in enough detail that it's clear that running a native sandbox is not possible.

I'm not really experienced with iOS' underlying architecture, so I'll happily take your word for it - it's just that the linked thread mentions that virtualization is possible but not but sort of.

The fundamental argument is that you will need emulation at some point because every syscall needs to be hooked, so you need to be able to stop before a system call is executed and respond appropriately. If you are running native code, you'd need to change the binary at runtime to do something else instead of the syscall, which means you're essentially writing to executable memory.

The reason you need emulation is not to hook the syscall instructions, even if that is sort of in the same general area as true: it is because the code for these binaries is not shipped with the app and signed. If you were going to limit this app to the code that was shipped with the app you could also just replace the syscall instructions as part of the same pass that signed the binaries. Even if you didn't need to hook the syscall instructions, it is the lack of code signature on these files that is requiring the emulator.

You are coming to mostly correct conclusions here, but frankly all of your explanations for this are confusing and most of them are incorrect :(.

I maintain that I mostly understand what is going on here, but I'll concede the point that my explanations are confusing and/or not directly to-the-point. You're much better at explaining things than I am ;)

> if you didn't need to hook the syscall instructions, it is the lack of code signature on these files that is requiring the emulator

I had considered a very sketchy solution for this for a personal project (from the App Store's perspective) of what would be the equivalent of hacking the package manager to only install my packages which I sign beforehand with my certificate, which kinda allows installing arbitrary things to the extent of "what I have decided to compile and sign".

> The reason you need emulation is not to hook the syscall instructions, even if that is sort of in the same general area as true: it is because the code for these binaries is not shipped with the app and signed.

There are two "signing" issues here which really are the same but I've separated out because I felt it to be appropriate, though in reality the second shouldn't occur: one is loading unsigned, arbitrary code from say a package you just downloaded, and one is modifying the execution of the program to emulate syscalls. If you somehow got iOS to load and execute your unmodified unsigned ELF executable, then you'd have to emulate system calls in some way, which I suggested you could do by performing the modifications you'd normally perform before even signing the binary at runtime by manually patching syscalls in executable memory (which requires JIT).

So it's mainly an iOS limitation? I don't understand why it shouldn't be possible to take the same route software like WINE or WSL have taken before on a less constrained OS like macOS.

Yes, this is mostly an iOS limitation rather than a hardware one. There are many ways to make something like this work if iOS allowed things like forking processes or JIT (for App Store apps)–actually if this was possible, the project at that point would probably just be "spawn a shell" instead of "emulate x86 and bootstrap a whole Alpine Linux install", since this is what most terminal emulators on Android do.

> the project at that point would probably just be "spawn a shell" instead of "emulate x86 and bootstrap a whole Alpine Linux install", since this is what most terminal emulators on Android do.

Or jailbroken iOS for that matter (at least when I last did a jailbreak which was quite some years ago, I honestly don't know about the current situation)

I kind of miss being able to SSH into my iPhone and run scripts, or just poke around the filesystem. It was fun to have a terminal app and editor where I could edit some code, and then deploy changes to a server. That was about 8 years ago.

I might do that again sometime. It's not urgent though, and I wouldn't switch to Android just for that. But I keep an eye on the jailbreak community.

I also really like the idea of having a portable keyboard and screen to turn my phone into a little development machine. I think the CPU is actually more powerful than my old 2012 MacBook, although it doesn't have as much RAM.

> It was fun to have a terminal app and editor where I could edit some code, and then deploy changes to a server.

There’s a number of apps on the App Store already that allow exactly this. Two of my personal favorites are Blink and Termius (use them both, but for different reasons).

Oh yeah, thanks, I was looking at Blink earlier. Haha actually I don't really need it, so I didn't install it. It was more about the feeling of "hacking" my device and doing something that it wasn't supposed to do. And having a real shell with access to the iOS file system, where I could script the phone to do all kinds of things, and write little programs that could run on a cron schedule. Stuff like that. For example, I wrote a little script that would change my iOS wallpaper once every hour, and it would take the images from a Dropbox folder.