Generate Frida hook scripts using modern Frida API. Activate when the user wants to write Frida scripts, hook functions at runtime, trace calls or arguments or return values, intercept native or ObjC or Java methods, dump memory or exports, or handle native module load timing for Android and other targets.
SKILL.md
rev-frida - Frida Script Generator
Generate Frida instrumentation scripts for dynamic analysis, hooking, and runtime inspection.
Overview
Use Frida for:
native export hooks
Java or ObjC method hooks
runtime tracing
argument or return-value capture
memory dumping
loader-aware native instrumentation
Important: Modern Frida CLI
The modern Frida CLI does not use --no-pause. A spawned process resumes after the script is loaded.
# Spawn and hook
frida -U -f com.example.app -l hook.js
# Attach to running process
frida -U com.example.app -l hook.js
# Attach by PID
frida -U -p 1234 -l hook.js
If the target may already be loaded, combine an immediate check with the load hook:
function hookNowOrOnLoad(moduleName, callback) {
const mod = Process.findModuleByName(moduleName);
if (mod) {
callback(mod);
return;
}
hookModuleLoad(moduleName, callback);
}
Use polling only as a fallback:
function hookWhenReady(moduleName, exportName, callbacks) {
const mod = Process.findModuleByName(moduleName);
if (mod) {
Interceptor.attach(mod.getExportByName(exportName), callbacks);
return;
}
const timer = setInterval(function () {
const loaded = Process.findModuleByName(moduleName);
if (!loaded) {
return;
}
clearInterval(timer);
Interceptor.attach(loaded.getExportByName(exportName), callbacks);
}, 100);
}
Notes:
On Android, prefer android_dlopen_ext before dlopen.
Deduplicate by module base, not only by path.
onLeave of dlopen/android_dlopen_ext is usually the right time to install hooks after constructors have run.
If Java drives native loading, also consider System.loadLibrary, Runtime.loadLibrary0, dlsym, or RegisterNatives.
Do Not Blindly Hook init Series Functions
Do not tell the user to hook .init, .init_array, constructors, or JNI_OnLoad blindly.
These are fragile points:
many libraries perform one-time setup there
bad hooks can crash the process before the real target logic runs
early hooks can change timing and hide the behavior the user wants to study
constructor code often fans out into many unrelated helpers
Before suggesting an init-stage hook:
identify why early hooking is required
identify the exact module and exact initialization routine
confirm whether the target symbol or behavior only exists before normal exports are reachable
prefer a later stable hook if it gives the same visibility
Prefer this order:
hook a stable exported function after module load
hook RegisterNatives, dlsym, or the first real business function
hook JNI_OnLoad only if native registration or anti-debug setup happens there
hook constructors or .init_array only if there is strong evidence that the critical logic is there
If proposing an early init hook, state:
why the normal export hook is insufficient
what exact function or address should be hooked
what failure mode to expect
how to verify the hook did not break initialization
Bad advice:
// do not suggest this without a reason
Interceptor.attach(Module.findBaseAddress("libtarget.so").add(0x1234), ...);
Better advice:
wait for module load
confirm the constructor target by symbols, xrefs, strings, or trace evidence
attach only after identifying the exact initialization function
explain the risk to the user before using an init-stage hook
Prefer Constructor Dispatchers Over Blind init Hooks
If anti-debug logic is suspected inside the constructor chain, prefer observing or hooking the dispatcher first instead of attaching blindly to raw .init_array entries.
Useful higher-level targets include:
call_constructors
call_array
linker-side constructor walkers
app-side wrapper functions that iterate constructor tables
Why this is safer:
one hook can reveal the full constructor sequence
you can see which constructor runs immediately before termination or anti-debug setup
it reduces blind patching of unrelated initialization code
it lets you log constructor targets first and patch only the offending one later
Recommended workflow:
hook module load
identify whether the process terminates during constructor execution
if yes, hook call_constructors or call_array when available
log each constructor target as it is dispatched
identify the exact constructor that performs anti-debug checks
patch or hook that constructor, or patch the specific anti-debug branch inside it
Only suggest call_constructors or call_array when:
the target platform or linker build exposes those functions
symbols, traces, or disassembly indicate they are actually used
the user needs visibility into constructor-time anti-debug behavior
Warn about these constraints:
these functions are loader or linker internals and names may vary by Android version, vendor build, or platform
they may not be exported and may require symbol recovery or offset-based attachment
hooking them too early can affect every library load, so scope logging carefully
use them for discovery first, not as a default permanent bypass
Good guidance:
“The process dies during native library initialization. First hook the constructor dispatcher such as call_constructors or call_array if present, log the constructor targets, then move to the exact offending constructor.”
Bad guidance:
“Hook every .init_array entry and patch until it stops crashing.”
