4 ms·

> probably the dynamic recompilation step that turns ARM code to x86 could be skipped I don't know if Switch could be emulated with Wine-like approach, if not,

• torginus 5y ago
  I'm not an expert on the ARM64 architecture, or the Switch OS, but from what I can tell, the interface between the OS and the app consists of function calls to the OS api, and syscall-s, that are triggered by the svc instruction. I'd guess the app is statically linked against the OS API, so for the OS calls, the addresses can be patched (or alternatively the emulated OS libs can be mmap-ed to the correct address), and the svc calls can be replaced with a jump to a thunk that emulates it's behavior. Both seem to be possible, since arm64 uses fixed instruction length. I don't think svc calls can be trapped in-process with user privileges, and it's even less likely it can be done in a portable way. So probably some level of source-patching needs to take place, but it requires just a high-level understanding of the code, not a full decompilation-recompilation.
  • londons_explore 5y ago
    Seems like a fragile approach when you can't even be sure about which bits are code and which are data... You might end up patching a svc syscall only to find out that it's actually some constant used in the logic of the game.
• my123 5y ago
  > I don't know if Switch could be emulated with Wine-like approach, if not, it would be tricky to intercept syscalls without an ARM-to-ARM DBT. Performance impact should be minimal though. You don't need a DBT, VMs on arm64 are very cheap. You can just use Hypervisor.framework really.