shadowninja108 / exlaunch Goto Github PK

View Code? Open in Web Editor NEW

98.0 13.0 39.0 148 KB

A framework for injecting C/C++ code into Nintendo Switch applications/applet/sysmodules.

License: GNU General Public License v2.0

Makefile 2.75% Shell 0.46% C++ 68.63% Assembly 4.64% C 22.84% Python 0.69%

exlaunch's Introduction

exlaunch

A framework for injecting C/C++ code into Nintendo Switch applications/applet/sysmodules.

Note

This project is a work in progress. If you have issues, reach out to Shadów#1337 on Discord.

Credit

Atmosphère: A great reference and guide.
oss-rtld: Included for (pending) interop with rtld in applications (License here).

exlaunch's People

Contributors

Stargazers

Watchers

exlaunch's Issues

Operator new overloading causes shitfuck failure

When you overload operator new (or delete, or sometimes malloc but not all the time because malloc is weird), the symbol will be force exported by whatever the shit ass linker being used is.

This causes any offsets to the function in the GOT/PLT to be overwritten with a pointer to a PLT wrapper that branches to the end of the .text section (text_end) before relocation, which should not matter usually but does here because JMPREL relocations are being used instead of RELA relocations which would overwrite the offset with a correct one built from the module base and offset in the RELA entry instead of the invalid offset that is now sitting in the PLT. (No clue why this happens or where it happens, but it can be observed when reading PLT values before runtime in GDB)
This causes the function to be viewed as an import by RTLD and will overwrite the PLT offsets with offsets to functions with the same symbol in other modules

This can be worked around by adding the affected symbols to a version script as "local" symbols, which prevents them from being exported. I don't expect you to fix this or know why it's happening, but just writing it down for the record

Add support for inline hooks (and extended inline hook contexts)

Inline hooks (probably exl::util::Hook::InlineHook)
Extended inline hook contexts
- The current 29 GP registers
- Stack pointer
- All 32 FP registers
Ability to hook with only the limited context (InlineCtx) or the extended context (ExInlineCtx) because the extended context is over 3x the stack usage

svcControlCodeMemory randomly fails

Happens because virtmemFindCodeMemory is returning nullptr

Provide ability to get ModuleInfo based on a pointer and also to get the name of the module

I'm proposing that there should either be an overload for exl::util::GetModuleInfo that takes a const void* argument or a differently named function that will do the following:

Check the provided pointer against the range of the already cached ModuleInfo structures of the static modules
If it does not fall within any of those, svcQueryMemory on to get the memory range it's in. From there, move forwards/backwards/both to try and get the rest of the ModuleInfo fields

On top of that, it would be nice to be able to fetch the name of the module either by index or by pointer.

Mods made with exlaunch are not compatible with each other.

2 mods are installed, one in subsdk8 and the other, subsdk9.

subsdk8 = Mod A
subsdk9 = Mod B

RTLD seems to load Mod B first (Print strings in Mod B are called)
Then, Mod B's exl::hook::Initialize(); is called, causing the game to crash.

Ryujinx gives this error (host memory):

00:00:29.937 |W| HLE.GuestThread.42 KernelSvc : MapProcessMemory() = InvalidSize
Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at ARMeilleure.Translation.Translator.Execute(ARMeilleure.State.ExecutionContext, UInt64)
   at Ryujinx.Cpu.Jit.JitCpuContext.Execute(Ryujinx.Cpu.IExecutionContext, UInt64)
   at Ryujinx.HLE.HOS.ArmProcessContext`1[[System.__Canon, System.Private.CoreLib, Version=7.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].Execute(Ryujinx.Cpu.IExecutionContext, UInt64)
   at Ryujinx.HLE.HOS.Kernel.Threading.KThread.ThreadStart()

Ryujinx log with software memory:

00:00:28.952 |W| HLE.GuestThread.42 KernelSvc : MapProcessMemory() = InvalidSize
00:00:28.990 |E| HLE.GuestThread.42 Application : Unhandled exception caught: Ryujinx.Memory.InvalidMemoryRegionException: va=0x6969696969696969, size=0x0000000000000008
   at Ryujinx.Cpu.Jit.MemoryManager.Write(UInt64 va, ReadOnlySpan`1 data) in D:\a\Ryujinx\Ryujinx\src\Ryujinx.Cpu\Jit\MemoryManager.cs:line 170
   at Ryujinx.Cpu.Jit.MemoryManager.Write[T](UInt64 va, T value) in D:\a\Ryujinx\Ryujinx\src\Ryujinx.Cpu\Jit\MemoryManager.cs:line 164
   at ARMeilleure.Instructions.NativeInterface.WriteUInt64(UInt64 address, UInt64 value) in D:\a\Ryujinx\Ryujinx\src\ARMeilleure\Instructions\NativeInterface.cs:line 136
   at ARMeilleure.Translation.Translator.Execute(ExecutionContext context, UInt64 address) in D:\a\Ryujinx\Ryujinx\src\ARMeilleure\Translation\Translator.cs:line 155
   at Ryujinx.Cpu.Jit.JitCpuContext.Execute(IExecutionContext context, UInt64 address) in D:\a\Ryujinx\Ryujinx\src\Ryujinx.Cpu\Jit\JitCpuContext.cs:line 32
   at Ryujinx.HLE.HOS.ArmProcessContext`1.Execute(IExecutionContext context, UInt64 codeAddress) in D:\a\Ryujinx\Ryujinx\src\Ryujinx.HLE\HOS\ArmProcessContext.cs:line 60
   at Ryujinx.HLE.HOS.Kernel.Threading.KThread.ThreadStart() in D:\a\Ryujinx\Ryujinx\src\Ryujinx.HLE\HOS\Kernel\Threading\KThread.cs:line 1264
Unhandled exception. Ryujinx.Memory.InvalidMemoryRegionException: va=0x6969696969696969, size=0x0000000000000008
   at Ryujinx.Cpu.Jit.MemoryManager.Write(UInt64 va, ReadOnlySpan`1 data) in D:\a\Ryujinx\Ryujinx\src\Ryujinx.Cpu\Jit\MemoryManager.cs:line 170
   at Ryujinx.Cpu.Jit.MemoryManager.Write[T](UInt64 va, T value) in D:\a\Ryujinx\Ryujinx\src\Ryujinx.Cpu\Jit\MemoryManager.cs:line 164
   at ARMeilleure.Instructions.NativeInterface.WriteUInt64(UInt64 address, UInt64 value) in D:\a\Ryujinx\Ryujinx\src\ARMeilleure\Instructions\NativeInterface.cs:line 136
   at ARMeilleure.Translation.Translator.Execute(ExecutionContext context, UInt64 address) in D:\a\Ryujinx\Ryujinx\src\ARMeilleure\Translation\Translator.cs:line 155
   at Ryujinx.Cpu.Jit.JitCpuContext.Execute(IExecutionContext context, UInt64 address) in D:\a\Ryujinx\Ryujinx\src\Ryujinx.Cpu\Jit\JitCpuContext.cs:line 32
   at Ryujinx.HLE.HOS.ArmProcessContext`1.Execute(IExecutionContext context, UInt64 codeAddress) in D:\a\Ryujinx\Ryujinx\src\Ryujinx.HLE\HOS\ArmProcessContext.cs:line 60
   at Ryujinx.HLE.HOS.Kernel.Threading.KThread.ThreadStart() in D:\a\Ryujinx\Ryujinx\src\Ryujinx.HLE\HOS\Kernel\Threading\KThread.cs:line 1264

To test, if Mod B's exl::hook::Initialize(); is commented out, both Mod B and A will load (Of course, Mod B's hooks will not work)

The same behavior is observed if we swap Mod B with Mod A's subsdks.

`std::aligned_storage` is deprecated, causes build failure

Building an unmodified exlaunch fails because -Werror is set and std::aligned_storage is deprecated in C++23.

main.cpp
In file included from /__w/MultiMoon/MultiMoon/source/lib/patch/patcher_impl.hpp:5,
                 from /__w/MultiMoon/MultiMoon/source/lib/patch/stream_patcher.hpp:3,
                 from /__w/MultiMoon/MultiMoon/source/lib/patch/code_patcher.hpp:4,
                 from /__w/MultiMoon/MultiMoon/source/lib.hpp:12,
                 from /__w/MultiMoon/MultiMoon/source/program/main.cpp:1:
/__w/MultiMoon/MultiMoon/source/lib/util/typed_storage.hpp:28:23: error: 'template<long unsigned int _Len, long unsigned int _Align> struct std::aligned_storage' is deprecated [-Werror=deprecated-declarations]
   28 |         typename std::aligned_storage<Size, Align>::type _storage;
      |                       ^~~~~~~~~~~~~~~
In file included from /opt/devkitpro/devkitA64/aarch64-none-elf/include/c++/13.1.0/concepts:44,
                 from /__w/MultiMoon/MultiMoon/source/lib/util/math/bitset.hpp:4,
                 from /__w/MultiMoon/MultiMoon/source/lib/armv8.hpp:4,
                 from /__w/MultiMoon/MultiMoon/source/lib.hpp:5:
/opt/devkitpro/devkitA64/aarch64-none-elf/include/c++/13.1.0/type_traits:2099:5: note: declared here
 2099 |     aligned_storage
      |     ^~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors

`deploy-ftp.py` requires Python 3.11 but this is not noted anywhere

deploy-ftp.py now requires Python 3.11 with the merging of #9. (config.mk states Python 3.4+ is required, but this wasn't updated.)

Current implementation of inline hook is garbaging X17 register

Just info for anybody trying to use inline hook with exlaunch since author is aware of issue.

If function where you put inline hook relies on X17 register, expect issues.