Feature Request: Add library/module whitelist for hook detection to reduce false positives

[alexanderkind]

Description

We are using legitimate third-party libraries that technically perform "hooking" (e.g., libGlossHook.so, libshadowhook.so, audio libraries like BASS with bassinithook). These libraries are essential for our app's functionality (advertising SDKs, audio processing, etc.).

flutter_rasp detects them as a HOOK threat and, depending on the configured ThreatPolicy, terminates the application. This results in false positives on clean, non-jailbroken/non-rooted devices.

Logs

shadowhook version 2.0.0: shadowhook init(default_mode: UNIQUE, debuggable: false), return: 0, real-init: yes
GlossHook is exist at: /data/app/.../base.apk!/lib/arm64-v8a/[libGlossHook.so](https://libglosshook.so/)
[sv:dbg:playback:bassinithook] : module loading...

All of these are legitimate and required for our app to function correctly.

Proposed Solution

We propose adding a whitelist mechanism for libraries or modules that should be ignored during HOOK detection.

Implementation idea:

• Add a new parameter to AndroidRaspConfig and IosRaspConfig, e.g.:

  AndroidRaspConfig(
    // ... existing params
    ignoredLibraries: ['libGlossHook.so', 'libshadowhook.so'],
  )
  

When HOOK detection runs, RASP would skip libraries that match the whitelist.
This would allow developers to exclude known, trusted, and legitimate hooks without disabling the entire HOOK detection mechanism.

Thank you for your excellent work on this package. We believe this feature would be a valuable addition and would greatly appreciate your consideration.

[juandpt03]

Hi @alexanderkind, thanks for the thoughtful write-up and the detailed context, it's really helpful.

One important clarification, hook detection isn't primarily based on library names, libraries like shadowhook, GlossHook, and bassinithook are detected because of their runtime hooking behavior, not because of their filename, so an ignoredLibraries allowlist wouldn't reliably solve these cases and could weaken the protection by allowing malicious hooks to disguise themselves as trusted libraries.

That said, I think it's worth exploring whether a safe exception mechanism is possible without compromising the behavioral detection layer, I'll spend some time evaluating the feasibility and security implications before deciding whether this is something that should be added.

Thanks again for raising this, it's a valuable discussion.