morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #968] [Feature] Modular native runtime instrumentation through a Frida adapter #367

New issue

Open

opened 2026-10-15 18:24:20 +00:00 by bsakaguchi · 6 comments

bsakaguchi commented

2026-10-15 18:24:20 +00:00

Owner

Originally created by @N0zoM1z0 on GitHub (Oct 7, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/968

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Process capture or runtime observation

Current limitation

REA can inspect native binaries through its static providers, capture process terminal behavior, and observe JavaScript/browser runtimes. Agents still lack a reusable native instrumentation provider for loaded modules, selected function entry/return values, and caller-authored runtime scripts.

The intended capability is general runtime reverse engineering: native applications, ABI reconstruction, dynamic loading, APK/JNI investigation, and firmware userspace programs can all consume it. Frida is the initial replaceable provider. CTF is one application domain/showcase of these general capabilities; public contracts should express reusable analyst questions.

Research baseline: REA main b5afa5f91eed9ae31d670aeab9bbf5112d790ec2, 2026-10-07. #71/#385 already track Objective-C observation; open PR #964 implements a narrower macOS LLDB entry-call proposal and explicitly excludes Frida and returns. #717 mentions future Android instrumentation. This issue records the shared Frida adapter and its independently useful native capabilities; coordinate with those workstreams. Parent: #32.

Use cases

Test a statically inferred ABI against raw argument/return observations from selected native calls.
Identify the actual loaded implementation of an indirect call using runtime address, module identity, base and offset.
Capture a selected buffer before/after a function call without losing NUL or non-UTF8 bytes.
Load an analyst-authored Frida script, receive its messages/errors, and call its exported RPC function with recorded script identity.
Reuse the same provider later for Java/JNI or Objective-C facets while retaining their exact platform coverage.

Process PTY capture does not provide these facts. Existing CDP/Inspector ports carry different producer semantics and should remain separate adapters.

Desired outcome and success criteria

Deliver small, independently reviewable capabilities:

Discover configured Frida/binding versions and supported host/target facets without attaching a target at MCP startup.
Select an exact local process or launch an explicit executable/argv. Preserve process identity, module identity, observed architecture and lifecycle; reject ambiguous selection and identity changes with a meaningful reason.
Observe selected native function entries and returns during a finite, armed collection window. Return hook installation/resolution outcomes, thread IDs, raw values, selected binary reads, addresses and available backtraces inline with Evidence.
Preserve raw pointer/ABI observations separately from caller-selected decoding. Unsupported argument kinds, unavailable returns, unmapped memory, late hooks and incomplete events remain explicit.
Support caller-authored script execution and RPC as a distinct operation, with original/executed script digests, arguments, JSON/binary replies, runtime errors and actual effects. Do not require a new orchestration language.
Preserve event order, clock provenance, collection boundaries, truncation/dropped-event information and cleanup outcomes. No observed calls is not proof that a selected path never executes.
Use shared application services for CLI/MCP, named contracts, valid advertised SDK-converted schemas, generated catalog and installed skill guidance.

First real acceptance: a source-built Linux x64 fixture with known native return values, concurrent calls, dynamic module loading/reload, NUL/non-UTF8 messages, unresolved hooks and target exit. Exercise real Frida through public CLI and MCP, including an isolated installed npm package. Verify cancellation, malformed scripts, output pressure, identity mismatch, cleanup after failed spawn/attach, and detach that preserves an externally launched fixture. Report unverified platforms separately.

Later facets can add selected memory writes, function replacement/calls, Stalker and Java/ObjC/Swift bridges. Each must have its own observed use case, effects and real verification; the provider remains useful without them.

Authority boundaries and non-goals

Selecting an operation expresses intent; use current OS permissions and canonical tool effects. No approval booleans or revived REA grant system. The historical approval wording in #71/#385 is superseded by the direction recorded in #32.
Frida attachment injects a runtime; hooks affect target memory/timing. Script/RPC and explicit writes may execute or change target behavior. Unload/detach cannot promise rollback of arbitrary script effects.
Distinguish cleanup of REA-owned launches from detach of an existing selected target. Preserve unrelated sessions/processes. Record suspended/resumed state and failures; never silently kill an attached external target or leave an owned spawn suspended after setup fails.
Keep private runtime storage and bounded CPU/memory/event/output behavior. Preserve meaningful provider, OS attach, target-identity and script errors.
Initial verification covers local Linux native processes. Android/device and other host claims require matching real lanes; integration must not silently install/start device daemons, repack APKs or change host security/configuration defaults.
Keep upstream Frida unchanged. Bring-your-own versioned bindings/toolchains and a small REA-owned bridge are preferred; copying or distributing components requires their actual license/provenance. GitHub NOASSERTION is not absence of licensing.

Alternatives considered

LLDB observation in #964 is complementary; share suitable call-evidence semantics while preserving provider coverage and authority differences.
frida-trace already supplies useful selectors/handlers. Reuse those ideas, but native API events provide a firmer boundary than parsing terminal trace text.
fuzzmind/frida-mcp has managed sessions/scripts, RPC and binary messages. Selected source review found tail-retained event queues and script preprocessing/bridge compilation; adapt provenance and loss reporting before reuse. Its broad catalog does not establish REA platform verification.
strace/bpftrace answer syscall/probe questions and can become separate providers later. Hooks on libc wrappers do not establish a complete syscall journal.

Possible direction

Keep pure runtime identities/call evidence in the domain, shared workflows behind application ports, and Frida APIs in a dedicated provider/bridge. Reuse existing process ownership, private runtime roots and Evidence infrastructure. Coordinate neutral call evidence with #964 rather than creating parallel domain models solely because the engines differ.

Start with official Python bindings behind an isolated, versioned bridge; compare the official Node binding only if a small real spike shows a packaging/lifecycle advantage. Optional providers should load lazily and independently. Persistent session infrastructure is justified only for script/debugger operations that actually span calls, with equivalent CLI/MCP lifecycle semantics.

Observed upstream release: Frida 17.22.2. This is a research snapshot, not a tested compatibility claim. Frida 17 API users supply Java/ObjC/Swift bridges separately; REPL/frida-trace availability must not be treated as API bridge availability. Pin the release/binding/bridge profile proven by implementation fixtures.

References

Frida modes and lifecycle
Frida native API, Interceptor, messages and RPC
Frida 17 bridge packaging
Official Python binding source
frida-trace, Stalker
Frida MCP selected source: session/script and event handling
Current process capture boundary
Related: #32, #71, #385, #717, #718, #964, #969 (independent binary diagnostics/debugger adapters).

Research reviewed official documentation, version/license metadata and selected source. No new provider runtime support is claimed by this issue. Follow up with focused implementation/proof issues rather than one monolithic PR.

Originally created by @N0zoM1z0 on GitHub (Oct 7, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/968 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Process capture or runtime observation ### Current limitation REA can inspect native binaries through its static providers, capture process terminal behavior, and observe JavaScript/browser runtimes. Agents still lack a reusable native instrumentation provider for loaded modules, selected function entry/return values, and caller-authored runtime scripts. The intended capability is **general runtime reverse engineering**: native applications, ABI reconstruction, dynamic loading, APK/JNI investigation, and firmware userspace programs can all consume it. Frida is the initial replaceable provider. CTF is one application domain/showcase of these general capabilities; public contracts should express reusable analyst questions. Research baseline: REA main `b5afa5f91eed9ae31d670aeab9bbf5112d790ec2`, 2026-10-07. #71/#385 already track Objective-C observation; open PR #964 implements a narrower macOS LLDB entry-call proposal and explicitly excludes Frida and returns. #717 mentions future Android instrumentation. This issue records the shared Frida adapter and its independently useful native capabilities; coordinate with those workstreams. Parent: #32. ### Use cases - Test a statically inferred ABI against raw argument/return observations from selected native calls. - Identify the actual loaded implementation of an indirect call using runtime address, module identity, base and offset. - Capture a selected buffer before/after a function call without losing NUL or non-UTF8 bytes. - Load an analyst-authored Frida script, receive its messages/errors, and call its exported RPC function with recorded script identity. - Reuse the same provider later for Java/JNI or Objective-C facets while retaining their exact platform coverage. Process PTY capture does not provide these facts. Existing CDP/Inspector ports carry different producer semantics and should remain separate adapters. ### Desired outcome and success criteria Deliver small, independently reviewable capabilities: - [ ] Discover configured Frida/binding versions and supported host/target facets without attaching a target at MCP startup. - [ ] Select an exact local process or launch an explicit executable/argv. Preserve process identity, module identity, observed architecture and lifecycle; reject ambiguous selection and identity changes with a meaningful reason. - [ ] Observe selected native function entries and returns during a finite, **armed** collection window. Return hook installation/resolution outcomes, thread IDs, raw values, selected binary reads, addresses and available backtraces inline with Evidence. - [ ] Preserve raw pointer/ABI observations separately from caller-selected decoding. Unsupported argument kinds, unavailable returns, unmapped memory, late hooks and incomplete events remain explicit. - [ ] Support caller-authored script execution and RPC as a distinct operation, with original/executed script digests, arguments, JSON/binary replies, runtime errors and actual effects. Do not require a new orchestration language. - [ ] Preserve event order, clock provenance, collection boundaries, truncation/dropped-event information and cleanup outcomes. No observed calls is not proof that a selected path never executes. - [ ] Use shared application services for CLI/MCP, named contracts, valid advertised SDK-converted schemas, generated catalog and installed skill guidance. First real acceptance: a source-built Linux x64 fixture with known native return values, concurrent calls, dynamic module loading/reload, NUL/non-UTF8 messages, unresolved hooks and target exit. Exercise real Frida through public CLI and MCP, including an isolated installed npm package. Verify cancellation, malformed scripts, output pressure, identity mismatch, cleanup after failed spawn/attach, and detach that preserves an externally launched fixture. Report unverified platforms separately. Later facets can add selected memory writes, function replacement/calls, Stalker and Java/ObjC/Swift bridges. Each must have its own observed use case, effects and real verification; the provider remains useful without them. ### Authority boundaries and non-goals - Selecting an operation expresses intent; use current OS permissions and canonical tool effects. No approval booleans or revived REA grant system. The historical approval wording in #71/#385 is superseded by the direction recorded in #32. - Frida attachment injects a runtime; hooks affect target memory/timing. Script/RPC and explicit writes may execute or change target behavior. Unload/detach cannot promise rollback of arbitrary script effects. - Distinguish cleanup of REA-owned launches from detach of an existing selected target. Preserve unrelated sessions/processes. Record suspended/resumed state and failures; never silently kill an attached external target or leave an owned spawn suspended after setup fails. - Keep private runtime storage and bounded CPU/memory/event/output behavior. Preserve meaningful provider, OS attach, target-identity and script errors. - Initial verification covers local Linux native processes. Android/device and other host claims require matching real lanes; integration must not silently install/start device daemons, repack APKs or change host security/configuration defaults. - Keep upstream Frida unchanged. Bring-your-own versioned bindings/toolchains and a small REA-owned bridge are preferred; copying or distributing components requires their actual license/provenance. GitHub `NOASSERTION` is not absence of licensing. ### Alternatives considered - LLDB observation in #964 is complementary; share suitable call-evidence semantics while preserving provider coverage and authority differences. - `frida-trace` already supplies useful selectors/handlers. Reuse those ideas, but native API events provide a firmer boundary than parsing terminal trace text. - `fuzzmind/frida-mcp` has managed sessions/scripts, RPC and binary messages. Selected source review found tail-retained event queues and script preprocessing/bridge compilation; adapt provenance and loss reporting before reuse. Its broad catalog does not establish REA platform verification. - strace/bpftrace answer syscall/probe questions and can become separate providers later. Hooks on libc wrappers do not establish a complete syscall journal. ### Possible direction Keep pure runtime identities/call evidence in the domain, shared workflows behind application ports, and Frida APIs in a dedicated provider/bridge. Reuse existing process ownership, private runtime roots and Evidence infrastructure. Coordinate neutral call evidence with #964 rather than creating parallel domain models solely because the engines differ. Start with official Python bindings behind an isolated, versioned bridge; compare the official Node binding only if a small real spike shows a packaging/lifecycle advantage. Optional providers should load lazily and independently. Persistent session infrastructure is justified only for script/debugger operations that actually span calls, with equivalent CLI/MCP lifecycle semantics. Observed upstream release: Frida 17.22.2. This is a research snapshot, **not a tested compatibility claim**. Frida 17 API users supply Java/ObjC/Swift bridges separately; REPL/frida-trace availability must not be treated as API bridge availability. Pin the release/binding/bridge profile proven by implementation fixtures. ### References - [Frida modes and lifecycle](https://frida.re/docs/modes/) - [Frida native API, Interceptor, messages and RPC](https://frida.re/docs/javascript-api/) - [Frida 17 bridge packaging](https://frida.re/docs/bridges/) - [Official Python binding source](https://github.com/frida/frida-python/tree/aacd1913e0d72fd424e998fc1f72bd2b6b0a2a49) - [frida-trace](https://frida.re/docs/frida-trace/), [Stalker](https://frida.re/docs/stalker/) - [Frida MCP selected source: session/script and event handling](https://github.com/fuzzmind/frida-mcp/blob/aa36b1742578879bfe9f4886509fb4c478f2114a/src/fuzzmind_frida_mcp/tools/_core.py) - [Current process capture boundary](https://github.com/morluto/rea/blob/b5afa5f91eed9ae31d670aeab9bbf5112d790ec2/docs/process-capture.md) - Related: #32, #71, #385, #717, #718, #964, #969 (independent binary diagnostics/debugger adapters). Research reviewed official documentation, version/license metadata and selected source. No new provider runtime support is claimed by this issue. Follow up with focused implementation/proof issues rather than one monolithic PR.

bsakaguchi added the

labels

2026-10-15 18:24:20 +00:00

bsakaguchi commented

2026-10-15 18:24:20 +00:00

Author

Owner

@morluto commented on GitHub (Oct 9, 2026):

Triage note (2026-10-09): keeping open. Related LLDB entry-call work landed via #964 (which explicitly excludes Frida and returns); the Frida adapter scope here remains unaddressed.

@morluto commented on GitHub (Oct 9, 2026): Triage note (2026-10-09): keeping open. Related LLDB entry-call work landed via #964 (which explicitly excludes Frida and returns); the Frida adapter scope here remains unaddressed.

bsakaguchi commented

2026-10-15 18:24:20 +00:00

Author

Owner

@JackLee992 commented on GitHub (Oct 9, 2026):

Thanks for the triage note and for keeping this open. I'd like to take the first independently-mergeable slice: discover configured Frida/binding versions and host/target facets without attaching or launching anything, as a separate Frida adapter (acknowledging #964 is LLDB-only and explicitly excludes Frida; I'd reuse the neutral nativeCallObservation domain where it fits, but keep a distinct Frida provider/bridge).

Scope for this slice:

bring-your-own: run only a bounded, cancellable version probe against an explicitly configured Frida CLI / versioned bridge; never auto-install a daemon or SDK and never change host configuration.
report provider/version (Frida core + binding kind/version + REA bridge version when present), host facet (os/arch/pointer size), and an explicit per-target support matrix where only genuinely verified targets are marked verified and everything else stays "unverified".
model it through the existing AnalysisProviderCandidate.inspectAvailability() / inspectTargetSupport() extension points and add one read-only CLI/MCP tool, registering capabilities/effects/catalog/skills the same way #964 did.
no session, spawn, attach, or script execution in this slice; process selection, armed native entry/return observation, and script/RPC would be separate follow-up PRs.

Local verification I've already done on Linux x64 (no device/root/frida-server): with real Frida 17.23.1 from the official prebuilt manylinux wheel, owned-spawn + attach into a source-built x64 fixture works. I captured a loaded .so export's entry args and return value against exact known inputs, an explicit unresolved-symbol miss, and clean teardown. Two Frida-17 specifics the bridge must pin: the static Module.getExportByName was removed (instance / Process.*Global* APIs only), and exports resolve from .dynsym (a PIE main executable's own symbols are not enumerable; observe a loaded .so, or use DebugSymbol).

A few questions before I write it:

Naming/placement: a new runtime/frida provider group, or fold into the existing native group alongside #964?
For discovery only, is probing an explicitly configured frida/bridge --version acceptable in this PR, with the isolated versioned Python bridge introduced alongside the observation PR — or do you want the Python bridge present from the start?
Preferred shape for the per-target support matrix so non-Linux-x64 targets are clearly reported as unverified rather than claimed?

I'll keep Linux x64 as the only verified target and list macOS/Windows/Android as unverified until matching real lanes exist. Happy to open this as a focused implementation issue if you'd prefer that to a long-lived thread here.

@JackLee992 commented on GitHub (Oct 9, 2026): Thanks for the triage note and for keeping this open. I'd like to take the first independently-mergeable slice: discover configured Frida/binding versions and host/target facets **without attaching or launching anything**, as a separate Frida adapter (acknowledging #964 is LLDB-only and explicitly excludes Frida; I'd reuse the neutral `nativeCallObservation` domain where it fits, but keep a distinct Frida provider/bridge). Scope for this slice: - bring-your-own: run only a bounded, cancellable version probe against an explicitly configured Frida CLI / versioned bridge; never auto-install a daemon or SDK and never change host configuration. - report provider/version (Frida core + binding kind/version + REA bridge version when present), host facet (os/arch/pointer size), and an explicit per-target support matrix where only genuinely verified targets are marked verified and everything else stays "unverified". - model it through the existing `AnalysisProviderCandidate.inspectAvailability()` / `inspectTargetSupport()` extension points and add one read-only CLI/MCP tool, registering capabilities/effects/catalog/skills the same way #964 did. - no session, spawn, attach, or script execution in this slice; process selection, armed native entry/return observation, and script/RPC would be separate follow-up PRs. Local verification I've already done on Linux x64 (no device/root/frida-server): with real Frida 17.23.1 from the official prebuilt manylinux wheel, owned-spawn + attach into a source-built x64 fixture works. I captured a loaded `.so` export's entry args and return value against exact known inputs, an explicit unresolved-symbol miss, and clean teardown. Two Frida-17 specifics the bridge must pin: the static `Module.getExportByName` was removed (instance / `Process.*Global*` APIs only), and exports resolve from `.dynsym` (a PIE main executable's own symbols are not enumerable; observe a loaded `.so`, or use DebugSymbol). A few questions before I write it: 1. Naming/placement: a new `runtime/frida` provider group, or fold into the existing `native` group alongside #964? 2. For discovery only, is probing an explicitly configured frida/bridge `--version` acceptable in this PR, with the isolated versioned Python bridge introduced alongside the observation PR — or do you want the Python bridge present from the start? 3. Preferred shape for the per-target support matrix so non-Linux-x64 targets are clearly reported as unverified rather than claimed? I'll keep Linux x64 as the only verified target and list macOS/Windows/Android as unverified until matching real lanes exist. Happy to open this as a focused implementation issue if you'd prefer that to a long-lived thread here.

bsakaguchi commented

2026-10-15 18:24:21 +00:00

Author

Owner

@LcokHcak commented on GitHub (Oct 13, 2026):

I tested REA's existing instrument-with-frida CLI against the public Appium ApiDemos v6.0.18 APK in a local Android 15 x86_64 emulator. A finite spawn run captured six Activity entry/exit events; an attach run captured eight events after one App-menu tap, with the UI change checked independently. In a later comparison, App and Animation both called Activity.startActivity(Intent) with the same .ApiDemos component; the selected io.appium.android.apis.Path extra distinguished them (App versus Animation). A bounded caller-authored agent emitted those selected values and a local parser retained them. These are Android fixture results only; they do not establish Linux-native or general Android compatibility.

I have a local, unintegrated prototype for an additive normalized trace projection of the existing caller-authored script operation. It preserves raw Frida messages, accepts only explicit versioned rea_trace envelopes, checks the claimed PID against the selected session, and reports retained-record indexes, field provenance, rejected/omitted events, retention truncation, and unknown producer loss. Selected decoded values are agent-supplied and bounded (16 keys; 64-character keys; 256-character string values). It distinguishes epoch milliseconds, monotonic nanoseconds, and QPC ticks without claiming a cross-provider total order. There is no public CLI/MCP integration or merged implementation yet.

A subsequent controlled App-menu tap, instrumenting four selected Activity overloads, produced four nested entries and four matching exits. An optional producer-assigned event.call (id, parent_id) preserved those observed pairs in the local projection: 8/8 candidate events accepted, zero rejected or omitted, and the UI transition checked independently. A null parent means no parent among the selected active hooks; this does not establish a complete call graph or cross-thread causality.

Would this projection fit #968 as a small follow-up to the current script operation, while the Frida provider discovery proposal above proceeds separately? I would keep Java/JNI hook presets, persistent streaming, and native argument/return decoding as later slices with their own real fixtures and cleanup/resource checks. The projection would add no script-execution authority and would not claim a complete call graph. Which output contract and real-provider verification would you want before integration?

Separate proposals: Linux eBPF userspace tracing #2688 and Windows ETW events #2689. Their attachment/permission effects and coverage differ from Frida's. No private APK, raw trace, credentials, or local paths are attached.

@LcokHcak commented on GitHub (Oct 13, 2026): I tested REA's existing `instrument-with-frida` CLI against the public Appium ApiDemos v6.0.18 APK in a local Android 15 x86_64 emulator. A finite `spawn` run captured six Activity entry/exit events; an `attach` run captured eight events after one App-menu tap, with the UI change checked independently. In a later comparison, App and Animation both called `Activity.startActivity(Intent)` with the same `.ApiDemos` component; the selected `io.appium.android.apis.Path` extra distinguished them (`App` versus `Animation`). A bounded caller-authored agent emitted those selected values and a local parser retained them. These are Android fixture results only; they do not establish Linux-native or general Android compatibility. I have a local, unintegrated prototype for an **additive normalized trace projection** of the existing caller-authored script operation. It preserves raw Frida messages, accepts only explicit versioned `rea_trace` envelopes, checks the claimed PID against the selected session, and reports retained-record indexes, field provenance, rejected/omitted events, retention truncation, and unknown producer loss. Selected decoded values are agent-supplied and bounded (16 keys; 64-character keys; 256-character string values). It distinguishes epoch milliseconds, monotonic nanoseconds, and QPC ticks without claiming a cross-provider total order. There is no public CLI/MCP integration or merged implementation yet. A subsequent controlled App-menu tap, instrumenting four selected `Activity` overloads, produced four nested entries and four matching exits. An optional producer-assigned `event.call` (`id`, `parent_id`) preserved those observed pairs in the local projection: 8/8 candidate events accepted, zero rejected or omitted, and the UI transition checked independently. A null parent means no parent among the selected active hooks; this does not establish a complete call graph or cross-thread causality. Would this projection fit #968 as a small follow-up to the current script operation, while the Frida provider discovery proposal above proceeds separately? I would keep Java/JNI hook presets, persistent streaming, and native argument/return decoding as later slices with their own real fixtures and cleanup/resource checks. The projection would add no script-execution authority and would not claim a complete call graph. Which output contract and real-provider verification would you want before integration? Separate proposals: Linux eBPF userspace tracing [#2688](https://github.com/morluto/rea/issues/2688) and Windows ETW events [#2689](https://github.com/morluto/rea/issues/2689). Their attachment/permission effects and coverage differ from Frida's. No private APK, raw trace, credentials, or local paths are attached.

bsakaguchi commented

2026-10-15 18:24:21 +00:00

Author

Owner

@LcokHcak commented on GitHub (Oct 14, 2026):

Controlled follow-up on the proposed read-only projection of the existing Frida script Evidence:

On an owned Windows x64 fixture, the REA manager build from my isolated PID-attach fix branch attached via Frida 17.23.2 and loaded two caller-authored scripts. Three native threads made overlapping calls with inputs 0,1,0; the fixture independently returned 42,17,42. A bounded local agent emitted 17 selected function/basic-block events. Per-invocation IDs and TIDs connected each entry, selected block path, and exit. One final agent status followed all 17 retained events. This is selected-path evidence, not whole-program coverage or a zero-loss claim.
In a separate owned run using a local prototype manager with a final cleanup snapshot, I requested unloadScript after observing all three entries while the fixture had not yet written its result. The target independently returned 42,17,42 and exited normally, but the main script's retained stream contained only the three entries, no exits, and no terminal status. The local projector kept those observations and reported producer omission/filter/loss as unknown. This is expected uncertainty for an interrupted script stream; unload success cannot stand in for trace completion.

Both results are from local experiments, with no public CLI/MCP change or packaged trace provider. I am proposing an initial slice that only projects explicit versioned rea_trace envelopes already present in the current instrument-with-frida raw Evidence, optionally scoped to one manager-assigned script ID. It would preserve raw record indexes and uncertainty, and add no new attach, spawn, script execution, or RPC authority. Cooperative finish RPC, bundled hook agents, persistent streaming, and automatic target instrumentation would remain separate proposals.

Would this read-only output slice fit #968 for a focused PR, or should it wait for the separate Frida adapter discovery work? I will keep it local until there is an explicit scope decision. I have not attached raw traces, local paths, or private targets.

@LcokHcak commented on GitHub (Oct 14, 2026): Controlled follow-up on the proposed **read-only projection of the existing Frida script Evidence**: - On an owned Windows x64 fixture, the REA manager build from my isolated PID-attach fix branch attached via Frida 17.23.2 and loaded two caller-authored scripts. Three native threads made overlapping calls with inputs `0,1,0`; the fixture independently returned `42,17,42`. A bounded local agent emitted 17 selected function/basic-block events. Per-invocation IDs and TIDs connected each entry, selected block path, and exit. One final agent status followed all 17 retained events. This is selected-path evidence, not whole-program coverage or a zero-loss claim. - In a separate owned run using a local prototype manager with a final cleanup snapshot, I requested `unloadScript` after observing all three entries while the fixture had not yet written its result. The target independently returned `42,17,42` and exited normally, but the main script's retained stream contained only the three entries, no exits, and no terminal status. The local projector kept those observations and reported producer omission/filter/loss as unknown. This is expected uncertainty for an interrupted script stream; unload success cannot stand in for trace completion. Both results are from local experiments, with no public CLI/MCP change or packaged trace provider. I am proposing an initial slice that only projects explicit versioned `rea_trace` envelopes already present in the current `instrument-with-frida` raw Evidence, optionally scoped to one manager-assigned script ID. It would preserve raw record indexes and uncertainty, and add **no** new attach, spawn, script execution, or RPC authority. Cooperative finish RPC, bundled hook agents, persistent streaming, and automatic target instrumentation would remain separate proposals. Would this read-only output slice fit #968 for a focused PR, or should it wait for the separate Frida adapter discovery work? I will keep it local until there is an explicit scope decision. I have not attached raw traces, local paths, or private targets.

bsakaguchi commented

2026-10-15 18:24:21 +00:00

Author

Owner

@LcokHcak commented on GitHub (Oct 14, 2026):

I prepared a focused, read-only Frida trace projection on this fork branch (compare with current main). It contains the v1 event/batch contract, pure parser for opt-in rea_trace envelopes already in manager Evidence, and tests. There is no CLI/MCP registration, new attach/spawn/script/RPC authority, bundled agent, or target mutation.

Verification on the exact branch: 23 focused tests, test discovery, typecheck, lint, module boundaries, and compile passed. Replaying saved manager messages from the owned Windows x64 Frida fixture produced 17 selected events from 25 raw messages and exactly matched the earlier retained projection. The fixture independently returned 42,17,42 for three overlapping calls. Producer loss remains unknown.

I intended to open this as a draft PR for the scope decision, but GitHub rejected CreatePullRequest for the currently authenticated account (and REST returned 404). The branch and diff are available for review. I will not integrate or publish a runtime tracing workflow without the explicit maintainer decision requested above.

@LcokHcak commented on GitHub (Oct 14, 2026): I prepared a focused, read-only Frida trace projection on [this fork branch](https://github.com/LcokHcak/rea/tree/codex/frida-trace-readonly-draft) ([compare with current main](https://github.com/morluto/rea/compare/main...LcokHcak:rea:codex/frida-trace-readonly-draft)). It contains the v1 event/batch contract, pure parser for opt-in `rea_trace` envelopes already in manager Evidence, and tests. There is no CLI/MCP registration, new attach/spawn/script/RPC authority, bundled agent, or target mutation. Verification on the exact branch: 23 focused tests, test discovery, typecheck, lint, module boundaries, and compile passed. Replaying saved manager messages from the owned Windows x64 Frida fixture produced 17 selected events from 25 raw messages and exactly matched the earlier retained projection. The fixture independently returned `42,17,42` for three overlapping calls. Producer loss remains unknown. I intended to open this as a draft PR for the scope decision, but GitHub rejected `CreatePullRequest` for the currently authenticated account (and REST returned 404). The branch and diff are available for review. I will not integrate or publish a runtime tracing workflow without the explicit maintainer decision requested above.

bsakaguchi commented

2026-10-15 18:24:22 +00:00

Author

Owner

@LcokHcak commented on GitHub (Oct 14, 2026):

Local exploratory update for the scope discussion: the trace batch contract is now v2 with required provider, session, target PID and selected stream; individual event records remain v1. This lets an empty selected-script result retain its identity and lets the validator reject mixed-session or mixed-target events.

In a fresh controlled Windows x64 run using the existing REA Frida manager and Frida 17.23.2, an owned three-thread fixture made three overlapping calls returning 42/17/42. REA retained 25 raw manager messages; the opt-in read-only projector selected 17 function/basic-block events from the main script. A companion script produced zero events but retained a distinct batch source. An earlier deliberate mid-call unload retained only three entries, no exits or final producer status; omission/filter/loss claims remain unknown. A saved real CLI capacity-pressure capture was also reprojected to v2: two selected events remain, records_truncated=true, and producer omission/loss stay unknown. Focused local tests passed 35/35, and raw-to-normalized independent replay plus hashes were checked.

An additional local pure projection now groups only producer-assigned call.id within each script stream, retaining batch event indexes and coverage. Saved-evidence replay yielded three distinct paired observations with 4/3/4 selected basic blocks for the overlapping run; three open calls for the deliberate unload; and one paired observation in the truncated capacity-pressure batch, still marked truncated with producer loss unknown. Contradictory thread/parent/name/action records are not silently paired. Focused tests for this projection passed 6/6; typecheck, compile, module boundaries, formatting and lint passed. ETW markers and current synthetic eBPF records without call IDs remain unattributed. This only reconstructs selected observations, not a complete execution path.

This is still an isolated prototype. It adds no public CLI/MCP operation, attachment or script authority, bundled agent, or whole-program-flow claim. Is an opt-in read-only projection of explicit versioned events already present in instrument-with-frida raw Evidence within REA scope? I will keep the integration pending until that boundary is decided.

@LcokHcak commented on GitHub (Oct 14, 2026): Local exploratory update for the scope discussion: the trace batch contract is now v2 with required provider, session, target PID and selected stream; individual event records remain v1. This lets an empty selected-script result retain its identity and lets the validator reject mixed-session or mixed-target events. In a fresh controlled Windows x64 run using the existing REA Frida manager and Frida 17.23.2, an owned three-thread fixture made three overlapping calls returning 42/17/42. REA retained 25 raw manager messages; the opt-in read-only projector selected 17 function/basic-block events from the main script. A companion script produced zero events but retained a distinct batch source. An earlier deliberate mid-call unload retained only three entries, no exits or final producer status; omission/filter/loss claims remain unknown. A saved real CLI capacity-pressure capture was also reprojected to v2: two selected events remain, `records_truncated=true`, and producer omission/loss stay unknown. Focused local tests passed 35/35, and raw-to-normalized independent replay plus hashes were checked. An additional local pure projection now groups only producer-assigned `call.id` within each script stream, retaining batch event indexes and coverage. Saved-evidence replay yielded three distinct paired observations with 4/3/4 selected basic blocks for the overlapping run; three open calls for the deliberate unload; and one paired observation in the truncated capacity-pressure batch, still marked truncated with producer loss unknown. Contradictory thread/parent/name/action records are not silently paired. Focused tests for this projection passed 6/6; typecheck, compile, module boundaries, formatting and lint passed. ETW markers and current synthetic eBPF records without call IDs remain unattributed. This only reconstructs selected observations, not a complete execution path. This is still an isolated prototype. It adds no public CLI/MCP operation, attachment or script authority, bundled agent, or whole-program-flow claim. Is an opt-in read-only projection of explicit versioned events already present in `instrument-with-frida` raw Evidence within REA scope? I will keep the integration pending until that boundary is decided.

bsakaguchi referenced this issue

2026-10-15 18:25:51 +00:00

[GH-ISSUE #1558] [Feature] Java Reverse Engineering #525

bsakaguchi referenced this issue

2026-10-15 18:25:52 +00:00

[GH-ISSUE #1558] [Feature] Java Reverse Engineering #525

bsakaguchi referenced this issue

2026-10-15 18:27:56 +00:00

[GH-ISSUE #2258] A recommended list of open-source decompilers #747

bsakaguchi referenced this issue

2026-10-15 18:28:03 +00:00

[GH-ISSUE #2296] [Feature] Decompile static Python bytecode (.pyc) files into labeled source inference #758