Resolve side-channel detection from com.reveny.nativecheck#655
Merged
JingMatrix merged 3 commits intomasterfrom Apr 12, 2026
Merged
Resolve side-channel detection from com.reveny.nativecheck#655JingMatrix merged 3 commits intomasterfrom
com.reveny.nativecheck#655JingMatrix merged 3 commits intomasterfrom
Conversation
1 task
This side-channel attack is obvious from the repeating logs: An isolated service (`com.reveny.nativecheck.app.isolated.IsolatedService`) intentionally spams Binder transactions to trigger our IPC hook.
In the previous implementation, if a transaction failed, the caller's ID was stored in `g_last_failed_id`. However, the state was immediately cleared on the caller's next transaction. This created a predictable, alternating loop (Intercept -> Fail -> Bypass/Clear -> Intercept) that allowed the isolated process to detect the presence of the hook via timing/behavioral observation.
We fix the flaw by keeping the failing caller in a persistent bypassed state. `g_last_failed_id` is now only reset when a different caller attempts a transaction. This effectively breaks the loop and silences the side-channel leak against continuous transaction spam.
Additionally, this commit includes minor fixes discovered during debugging:
- module.cpp: Fix invalid fmt placeholder (`%d` -> `{}`) in isolated process log.
- ManagerService.kt: Fix logical order to save verbose logging preference before applying the LogcatMonitor state.
com.reveny.nativecheckcom.reveny.nativecheck
This was referenced Apr 12, 2026
We only explicitly reset it to ~0 when the brigde approves the last connection.
larsmartens
pushed a commit
to larsmartens/Vector
that referenced
this pull request
Apr 12, 2026
…gMatrix#655) This side-channel attack is obvious from the repeating logs: An isolated service (`com.reveny.nativecheck.app.isolated.IsolatedService`) of `Android-Native-Root-Detector` v7.7.0 intentionally spams Binder transactions to trigger our IPC hook. In the previous implementation, if a transaction failed, the caller's ID was stored in `g_last_failed_id`. However, the state was immediately cleared on the caller's next transaction. This created a predictable, alternating loop (Intercept -> Fail -> Bypass/Clear -> Intercept) that allowed the isolated process to detect the presence of the hook via timing/behavioral observation. We fix the flaw by keeping the failing caller in a persistent bypassed state. `g_last_failed_id` is now only reset when when the brigde approves the last connection. This effectively breaks the loop and silences the side-channel leak against continuous transaction spam. Additionally, this commit includes minor fixes discovered during debugging: - module.cpp: Fix invalid fmt placeholder (`%d` -> `{}`) in isolated process log. - ManagerService.kt: Fix logical order to save verbose logging preference before applying the LogcatMonitor state. (cherry picked from commit ddcfa3d)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This side-channel attack is obvious from the repeating logs:
We will address this soon in
ipc_bridge.cpp.