Frida 17 compatibility: migrate from removed Module.findExportByName

[ymuuuu]

Summary

Frida 17.0.0 (release notes, May 2025) removed the static Module.* helper family, including Module.findExportByName. The current extra branch calls it in two places, so any agent that imports frida-mono-api under Frida 17 crashes at module-load time with TypeError: not a function.

This PR migrates both call sites to the Frida-17-supported forms:

• src/mono-module.js — Module.findExportByName(null, 'mono_thread_attach') → Module.findGlobalExportByName('mono_thread_attach') (the dedicated replacement for the null-as-first-arg form, used here because the lookup is intentionally module-agnostic).
• src/mono-api.js — Module.findExportByName(monoModule.name, exportName) → monoModule.findExportByName(exportName). The Module object is already in hand as a local, so the instance method (which has existed since Frida 16) is the natural and most efficient replacement, and is forward+backward compatible across Frida 16 and 17.

The existing !addr check on the next line already handles both the Frida 16 NULL-NativePointer and the Frida 17 null returns, so no change to the not-found path was needed.

Why these specific replacements

• Instance method over Process.getModuleByName(name).findExportByName(...) — the module is already cached in monoModule; re-resolving it on every iteration would be wasteful, and Process.getModuleByName throws on miss whereas the existing logic relies on a non-throwing path.
• findGlobalExportByName over getGlobalExportByName — call sites already test the result (if (monoThreadAttach) ...), so the non-throwing find* form is the right one. get* would force adding a try/catch.
• No feature-detection shim — the static helpers are gone in 17 and the instance method has been around since 16, so the new code works on both. A shim would only complicate review.

Companion PR

The bundled script consumer needs a parallel rebuild — see GoSecure/frida-xamarin-unpin#19, which regenerates dist/xamarin-unpin.js against this branch. The two PRs should be considered together.

Test plan

• frida-xamarin-unpin rebuilt against this branch loads cleanly under Frida 17.9.1 against a real Xamarin Android target.
• Existing Mono export resolution (mono_thread_attach, mono_compile_method, mono_class_get_method_from_name, etc.) continues to work in attach mode.
• No remaining references to Module.findExportByName( in the diff.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR updates frida-mono-api to remain compatible with Frida 17 by replacing removed static Module.* export-lookup helpers with supported alternatives, preventing module-load crashes when running under Frida 17.x.

Changes:

• Replace Module.findExportByName(null, ...) with Module.findGlobalExportByName(...) for module-agnostic Mono runtime detection.
• Replace Module.findExportByName(monoModule.name, ...) with the instance method monoModule.findExportByName(...) when binding Mono exports.
• Add README context explaining the Frida 17 compatibility migration.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
src/mono-module.js	Updates Mono runtime detection to use Frida 17-supported global export lookup.
src/mono-api.js	Updates export binding to use the Module instance findExportByName method.
README.md	Documents the Frida 17 compatibility purpose and links to upstream release notes.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This new intro says the branch ports only "runtime detection", but this PR also changes export resolution/binding in src/mono-api.js (switching to monoModule.findExportByName). Update the wording to reflect the broader Frida 17 compatibility change so readers don’t miss the API-side migration.

Suggested change

	> **Frida 17 compatibility (community contribution)** — this `frida-17` branch ports the
	> `frida-mono-api` runtime detection to Frida 17.x's new `Module` API. The original code
	> calls `Module.findExportByName(...)`, which was removed in Frida 17.0.0 (May 2025).
	> Submitted as a small contribution to the GoSecure tooling that powers
	> [frida-xamarin-unpin](https://github.com/GoSecure/frida-xamarin-unpin). See the upstream
	> [Frida 17.0.0 release notes](https://frida.re/news/2025/05/17/frida-17-0-0-released/) for
	> the full migration guide.
	> **Frida 17 compatibility (community contribution)** — this `frida-17` branch updates
	> `frida-mono-api` for Frida 17.x's new `Module` API, including both runtime detection and
	> API-side export resolution/binding changes. In particular, the original code relied on
	> `Module.findExportByName(...)`, which was removed in Frida 17.0.0 (May 2025), so export
	> lookup now needs to be resolved through the loaded module (for example,
	> `monoModule.findExportByName(...)`). Submitted as a small contribution to the GoSecure
	> tooling that powers [frida-xamarin-unpin](https://github.com/GoSecure/frida-xamarin-unpin).
	> See the upstream [Frida 17.0.0 release notes](https://frida.re/news/2025/05/17/frida-17-0-0-released/)
	> for the full migration guide.

[Copilot]

The loop uses Object.keys(MonoApi).map(...) for side-effects (initializing MonoApi[exportName]), which allocates an unused array. Prefer forEach or a for...of loop over Object.keys(...) to avoid the extra allocation and make the intent explicit.

[Copilot]

The ternary assigns to MonoApi[exportName] twice in the : branch (MonoApi[exportName] = ... : MonoApi[exportName] = new ExNativeFunction(...)). This is redundant and makes the control flow harder to read; simplify to a single assignment (compute the value, then assign once).

Suggested change

	: MonoApi[exportName] = new ExNativeFunction(addr, ...MonoApi[exportName])
	: new ExNativeFunction(addr, ...MonoApi[exportName])