morluto/rea

Fork 0

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

[GH-ISSUE #5820] [Feature] Provider-neutral V-CPU interpreter structure analysis #3519

New issue

Open

opened 2026-10-31 00:41:24 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:41:24 +00:00

Owner

Originally created by @kxdkxd on GitHub (Oct 21, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5820

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This request does not include credentials, private samples, or sensitive target data.

Area

Native analysis or decompilation

Current limitation

When ordinary control-flow obfuscation has already been reduced (for example, after resolving function splitting or indirect branch stubs), a remaining custom bytecode interpreter can still make the active native program difficult to reason about. REA can inspect instructions, pseudocode, references, and jump tables through Hopper/Ghidra/IDA, but it does not provide a provider-neutral way to summarize an interpreter's structural components or preserve the uncertainty in that analysis.

This is not a request to integrate automatic commercial-protection bypass or automatic recovery of protected code. I would like a maintainer decision on whether a narrowly scoped, read-only structural analysis workflow fits REA.

Desired outcome and success criteria

A useful in-scope outcome could be a static "interpreter/V-CPU structure dossier" over an already active native target and caller-identified code/data regions. It would distinguish observed facts from inferences and report:

candidate fetch, decode, and dispatch loops, with the evidence for each classification;
direct and recovered indirect dispatch targets, including unresolved entries;
handler entry addresses and their backing data sources;
register, stack, and memory operands observed in the dispatch path;
references from handlers back to the active decompiler analysis, without assigning semantic meanings that the evidence does not support;
explicit unknowns for opaque predicates, dynamically computed targets, aliases, or handler regions not covered.

Success would be an analyst-facing report that makes it easier to continue investigation in the existing Ghidra/Hopper/IDA workflows. It would not claim to recover original source, decode custom bytecode semantics automatically, or undo a protection.

Expected interaction with targets

Read existing files or captured data

Target and scope details

Non-goals:

no target execution, attach, injection, memory/register mutation, or network access;
no anti-debugging or anti-instrumentation evasion;
no purpose-built workflow to defeat commercial packing/code-virtualization protections;
no automatic protected-code recovery;
no bundled decompiler plugin that claims generic devirtualization.

Scope decision requested:

Is a provider-neutral, read-only interpreter/V-CPU structure dossier within REA's existing "general static deobfuscation" scope?
If not, is there a smaller useful boundary, such as only exporting dispatch/handler/jump-table evidence as typed native-analysis relationships?
Should such a workflow be limited to caller-identified regions to avoid any protection detection or bypass implication?

Verification available so far

Idea only; I need help defining checks

Verification details

Verification could use a self-owned synthetic native fixture with an explicit dispatch table and handler set. Expected output would include the dispatch loop, table entries, handler addresses, and explicit unresolved/unknown fields. A second fixture with computed or partially opaque dispatch targets should remain partial rather than inventing semantics.

Alternatives considered

Current REA native tools provide instructions, pseudocode, references, jump-table evidence, and bounded value traces. These primitives are useful, but the relationships still have to be assembled manually for each interpreter. A generic automatic devirtualizer would be out of scope, while a structural dossier may provide reusable evidence without crossing that boundary.

Possible direction

Model this as a native-analysis projection over authenticated provider evidence rather than a new protection-specific provider. Reuse existing jump-table and indirect-reference observations, require caller-identified target regions, and return a typed graph with observed/derived/inferred labels and complete coverage/unknown fields. A later maintainer-approved design could discuss how users continue the analysis in Ghidra/IDA without REA bundling or automating a bypass.

References

Originally created by @kxdkxd on GitHub (Oct 21, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5820 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This request does not include credentials, private samples, or sensitive target data. ### Area Native analysis or decompilation ### Current limitation When ordinary control-flow obfuscation has already been reduced (for example, after resolving function splitting or indirect branch stubs), a remaining custom bytecode interpreter can still make the active native program difficult to reason about. REA can inspect instructions, pseudocode, references, and jump tables through Hopper/Ghidra/IDA, but it does not provide a provider-neutral way to summarize an interpreter's structural components or preserve the uncertainty in that analysis. This is not a request to integrate automatic commercial-protection bypass or automatic recovery of protected code. I would like a maintainer decision on whether a narrowly scoped, read-only structural analysis workflow fits REA. ### Desired outcome and success criteria A useful in-scope outcome could be a static "interpreter/V-CPU structure dossier" over an already active native target and caller-identified code/data regions. It would distinguish observed facts from inferences and report: - candidate fetch, decode, and dispatch loops, with the evidence for each classification; - direct and recovered indirect dispatch targets, including unresolved entries; - handler entry addresses and their backing data sources; - register, stack, and memory operands observed in the dispatch path; - references from handlers back to the active decompiler analysis, without assigning semantic meanings that the evidence does not support; - explicit unknowns for opaque predicates, dynamically computed targets, aliases, or handler regions not covered. Success would be an analyst-facing report that makes it easier to continue investigation in the existing Ghidra/Hopper/IDA workflows. It would not claim to recover original source, decode custom bytecode semantics automatically, or undo a protection. ### Expected interaction with targets - Read existing files or captured data ### Target and scope details Non-goals: - no target execution, attach, injection, memory/register mutation, or network access; - no anti-debugging or anti-instrumentation evasion; - no purpose-built workflow to defeat commercial packing/code-virtualization protections; - no automatic protected-code recovery; - no bundled decompiler plugin that claims generic devirtualization. Scope decision requested: 1. Is a provider-neutral, read-only interpreter/V-CPU structure dossier within REA's existing "general static deobfuscation" scope? 2. If not, is there a smaller useful boundary, such as only exporting dispatch/handler/jump-table evidence as typed native-analysis relationships? 3. Should such a workflow be limited to caller-identified regions to avoid any protection detection or bypass implication? ### Verification available so far Idea only; I need help defining checks ### Verification details Verification could use a self-owned synthetic native fixture with an explicit dispatch table and handler set. Expected output would include the dispatch loop, table entries, handler addresses, and explicit unresolved/unknown fields. A second fixture with computed or partially opaque dispatch targets should remain partial rather than inventing semantics. ### Alternatives considered Current REA native tools provide instructions, pseudocode, references, jump-table evidence, and bounded value traces. These primitives are useful, but the relationships still have to be assembled manually for each interpreter. A generic automatic devirtualizer would be out of scope, while a structural dossier may provide reusable evidence without crossing that boundary. ### Possible direction Model this as a native-analysis projection over authenticated provider evidence rather than a new protection-specific provider. Reuse existing jump-table and indirect-reference observations, require caller-identified target regions, and return a typed graph with observed/derived/inferred labels and complete coverage/unknown fields. A later maintainer-approved design could discuss how users continue the analysis in Ghidra/IDA without REA bundling or automating a bypass. ### References - [Contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) - [MCP tool design](https://github.com/morluto/rea/blob/main/docs/tool-design.md) - [Native investigation guide](https://github.com/morluto/rea/blob/main/docs/native-investigation.md)

bsakaguchi commented

2026-10-31 00:41:25 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 21, 2026):

Supportive of the scoped, read-only dossier idea. The key strength is that it separates observed facts from inference and explicitly surfaces unknowns (opaque predicates, dynamically computed targets), which fits REA's evidence-provenance conventions and keeps the tool useful without over-claiming. Two suggestions: (1) define the provider-neutral output schema around what each decompiler can actually attest — e.g. Ghidra/Hopper jump-table recovery vs IDA FLIRT-style signatures differ, so "recovered indirect dispatch targets" should carry a provenance tag per entry; (2) scope the dispatch-loop classification to the caller-identified regions and make unresolved entries first-class output rather than a fallback, so the dossier degrades gracefully on obfuscated handlers.

@XinwangTao commented on GitHub (Oct 21, 2026): Supportive of the scoped, read-only dossier idea. The key strength is that it separates observed facts from inference and explicitly surfaces unknowns (opaque predicates, dynamically computed targets), which fits REA's evidence-provenance conventions and keeps the tool useful without over-claiming. Two suggestions: (1) define the provider-neutral output schema around what each decompiler can actually attest — e.g. Ghidra/Hopper jump-table recovery vs IDA FLIRT-style signatures differ, so "recovered indirect dispatch targets" should carry a provenance tag per entry; (2) scope the dispatch-loop classification to the caller-identified regions and make unresolved entries first-class output rather than a fallback, so the dossier degrades gracefully on obfuscated handlers.

bsakaguchi referenced this issue

2026-10-31 01:09:31 +00:00

[PR #3519] [CLOSED] fix(test): isolate electron mock from ancestor node_modules #5797

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#3519

No description provided.

Rows
Columns