Mod Loading through external .so/.dll

[spflaumer]

Should i reimplement modules as loadable shared libraries? the basic idea is stolen from here:

You can write a plugin to change the way YClass reads memory. To do that you will need a shared library(.dll or .so) that exports following functions

fn yc_attach(process_id: u32) -> u32 - Called when attaching to a process.

fn yc_read(address: usize, buffer: *mut u8, buffer_size: usize) -> u32 - Called when reading memory(very frequently).

fn yc_can_read(address: usize) -> bool - Called to check if address is "readable", i.e. a pointer.

fn yc_detach() - Called when detaching from a process.

After its done, put your library at ./plugin.ycpl or specify the path under plugin_path key in your config.```

[spflaumer]

there would be 2 ways of implementing that kind of behaviour:

• using the plugin package:
• or the net/rpc package. imo plugin is easier to setup overall while rpc might be more configurable

[kyoukaya]

there would be 2 ways of implementing that kind of behaviour:

* using the [`plugin`](https://pkg.go.dev/plugin) package:

* or the [`net/rpc`](https://pkg.go.dev/net/rpc) package.
  imo plugin is easier to setup overall while rpc might be more configurable

Plugin implementation was one of the things that stumped me back then and go hasn't really advanced in that regard over the past few years. The native plugin support being unavailable on Windows ruled it out for me, most people use a Windows PC to run emulators for mobile games.

I also considered IPC based implementations like hashicorp's go-plugin, but I don't think the added complication would have been a good experience for developers writing a plugin or users to use. Ultimately I just left it as a framework of sorts.

WASM has matured a lot more in general and on go, so I think it's possible to run WASM programs as limited plugins in a go program. But ultimately, go was, and still isn't a good language for plugin development compared to IL/interpreted languages like C#, python, js, which also have existing MITM libraries to take advantage of.

[spflaumer]

The native plugin support being unavailable on Windows ruled it out for me, most people use a Windows PC to run emulators for mobile games.

This is why i suggested net/rpc: you can run a separate program and handle all the plugin stuff via rpc. The only problem is how to generalize the Interfacing with the main program. The data sent back and forth could be encoded in JSON, for example.

[spflaumer]

i'm gonna spend some time tinkering with a concept and share a gist once i deem it useable

[spflaumer]

it seems like i have some sort of solution? although i have not tested this approach yet, it seems that it would be possible to:

• load a dll or so with syscall.LoadLibrary(name_from_toml)
• load all needed function through a for loop with syscall.GetProcAddress(lib, func_name_from_toml_array[i]) into a HashMap
• call the functions using reflect's function calling functionality
• optionally create a template init() function function-pointer that will be always run

i will test that and create a gist with working code or return with empty hands and declare temporary defeat