morluto/rea

Fork 0

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

[GH-ISSUE #5185] Feature Request: Support Analysis of MQL5 `.ex5` Expert Advisors Loaded by `terminal64.exe` #3178

New issue

Open

opened 2026-10-31 00:37:33 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-31 00:37:33 +00:00

Owner

Originally created by @hadiabounader on GitHub (Oct 19, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5185

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

Provider or capability discovery

Current limitation

I would like to propose adding support for analyzing compiled MetaTrader 5 Expert Advisors (.ex5 files), particularly when they are loaded and executed by terminal64.exe on Windows.

Background and Use Case

REA's approach to evidence-based reverse engineering would be valuable for investigating compiled MQL5 applications when the original source code is unavailable.

In MetaTrader 5, Expert Advisors are compiled into .ex5 files and loaded by the terminal process. This creates a potential opportunity to combine static binary inspection with controlled runtime observation to better understand program behavior.

My use case is a local research and testing environment for Expert Advisors that I own or am explicitly authorized to analyze. The objective is to understand their behavior, investigate execution paths, document strategy logic where technically observable, and compare observed behavior against backtesting results.

Proposed Functionality

It would be useful if REA could support a workflow that:

Identifies loaded modules: Detects relevant .ex5 Expert Advisors associated with a running terminal64.exe process.
Analyzes available binary artifacts: Inspects an .ex5 file offline and determines which static analysis techniques are applicable to its format.
Supports runtime observation: Where feasible, captures observable behavior during controlled execution, including relevant function activity, execution events, and interactions with the MetaTrader environment.
Correlates static and dynamic evidence: Connects findings from binary inspection with runtime observations and Strategy Tester behavior.
Produces structured findings: Returns evidence-backed results, clearly distinguishing confirmed findings from inferences and technical limitations.

Technical Considerations

I understand that .ex5 is a compiled, platform-specific format and that ordinary native executable analysis may not directly recover its original MQL5 source code or high-level program structure.

The request is therefore not necessarily for full decompilation. Even partial support—such as format identification, strings and metadata extraction where available, module discovery, or documented runtime observation—would be a useful starting point.

A configurable Windows workflow for analyzing an explicitly selected MetaTrader 5 terminal process would be particularly helpful.

Scope and Authorization

The intended use is authorized software analysis, interoperability research, debugging, and behavioral documentation in an isolated local environment.

The proposed functionality does not require bypassing licensing mechanisms, defeating access controls, or circumventing protections. Any runtime instrumentation would be limited to techniques supported by the applicable analysis tools and the user's authorization.

Expected Benefit

This capability could extend REA's existing binary-analysis and runtime-investigation workflows to compiled trading applications, where source code is often unavailable but repeatable testing and observable execution behavior can provide useful evidence.

I would appreciate your thoughts on whether this is technically feasible within REA's current architecture, and whether a limited initial implementation would be a reasonable addition to the roadmap.

Thank you for maintaining REA and considering the request.

Use cases

No response

Desired outcome and success criteria

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

No response

Verification available so far

Idea only; I need help defining checks

Verification details (optional)

No response

Alternatives considered

No response

Possible direction

No response

References

No response

Originally created by @hadiabounader on GitHub (Oct 19, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5185 ### 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 Provider or capability discovery ### Current limitation I would like to propose adding support for analyzing compiled MetaTrader 5 Expert Advisors (`.ex5` files), particularly when they are loaded and executed by `terminal64.exe` on Windows. Background and Use Case REA's approach to evidence-based reverse engineering would be valuable for investigating compiled MQL5 applications when the original source code is unavailable. In MetaTrader 5, Expert Advisors are compiled into `.ex5` files and loaded by the terminal process. This creates a potential opportunity to combine static binary inspection with controlled runtime observation to better understand program behavior. My use case is a local research and testing environment for Expert Advisors that I own or am explicitly authorized to analyze. The objective is to understand their behavior, investigate execution paths, document strategy logic where technically observable, and compare observed behavior against backtesting results. Proposed Functionality It would be useful if REA could support a workflow that: - **Identifies loaded modules:** Detects relevant `.ex5` Expert Advisors associated with a running `terminal64.exe` process. - **Analyzes available binary artifacts:** Inspects an `.ex5` file offline and determines which static analysis techniques are applicable to its format. - **Supports runtime observation:** Where feasible, captures observable behavior during controlled execution, including relevant function activity, execution events, and interactions with the MetaTrader environment. - **Correlates static and dynamic evidence:** Connects findings from binary inspection with runtime observations and Strategy Tester behavior. - **Produces structured findings:** Returns evidence-backed results, clearly distinguishing confirmed findings from inferences and technical limitations. Technical Considerations I understand that `.ex5` is a compiled, platform-specific format and that ordinary native executable analysis may not directly recover its original MQL5 source code or high-level program structure. The request is therefore not necessarily for full decompilation. Even partial support—such as format identification, strings and metadata extraction where available, module discovery, or documented runtime observation—would be a useful starting point. A configurable Windows workflow for analyzing an explicitly selected MetaTrader 5 terminal process would be particularly helpful. Scope and Authorization The intended use is authorized software analysis, interoperability research, debugging, and behavioral documentation in an isolated local environment. The proposed functionality does not require bypassing licensing mechanisms, defeating access controls, or circumventing protections. Any runtime instrumentation would be limited to techniques supported by the applicable analysis tools and the user's authorization. Expected Benefit This capability could extend REA's existing binary-analysis and runtime-investigation workflows to compiled trading applications, where source code is often unavailable but repeatable testing and observable execution behavior can provide useful evidence. I would appreciate your thoughts on whether this is technically feasible within REA's current architecture, and whether a limited initial implementation would be a reasonable addition to the roadmap. Thank you for maintaining REA and considering the request. ### Use cases _No response_ ### Desired outcome and success criteria NA ### Expected interaction with targets Read existing files or captured data ### Target and scope details (optional) _No response_ ### Verification available so far Idea only; I need help defining checks ### Verification details (optional) _No response_ ### Alternatives considered _No response_ ### Possible direction _No response_ ### References _No response_

bsakaguchi added the

triage

enhancement

labels

2026-10-31 00:37:33 +00:00

bsakaguchi commented

2026-10-31 00:37:34 +00:00

Author

Owner

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

Reasonable scope — asking for partial support (format identification, strings/metadata, module discovery) before full decompilation is a pragmatic first step, since .ex5 is a compiled, platform-specific format where recovering original MQL5 structure is genuinely hard. REA's existing binary-analysis providers could likely absorb an .ex5 recognizer plus a metadata/strings pass fairly quickly; the runtime-observation half is where the interesting design work is — correlating observable terminal behavior with static artifacts while staying within authorized instrumentation. +1 to scoping this as a phased roadmap item, with static-first as the MVP.

@XinwangTao commented on GitHub (Oct 19, 2026): Reasonable scope — asking for partial support (format identification, strings/metadata, module discovery) before full decompilation is a pragmatic first step, since .ex5 is a compiled, platform-specific format where recovering original MQL5 structure is genuinely hard. REA's existing binary-analysis providers could likely absorb an .ex5 recognizer plus a metadata/strings pass fairly quickly; the runtime-observation half is where the interesting design work is — correlating observable terminal behavior with static artifacts while staying within authorized instrumentation. +1 to scoping this as a phased roadmap item, with static-first as the MVP.

bsakaguchi commented

2026-10-31 00:37:34 +00:00

Author

Owner

@matbrgz commented on GitHub (Oct 19, 2026):

Cross-referencing with the earlier canonical proposal #3569 (Feature Request: Support for MQL5 (.ex5) bytecode static analysis or provider integration), opened on October 14, 2026. This issue enriches the original proposal with runtime observation boundaries under terminal64.exe.

Indexed under Section 1 (Direct Duplicates / Parent Features) in consolidation tracker #4330.

@matbrgz commented on GitHub (Oct 19, 2026): Cross-referencing with the earlier canonical proposal #3569 (`Feature Request: Support for MQL5 (.ex5) bytecode static analysis or provider integration`), opened on October 14, 2026. This issue enriches the original proposal with runtime observation boundaries under `terminal64.exe`. Indexed under Section 1 (Direct Duplicates / Parent Features) in consolidation tracker #4330.

bsakaguchi commented

2026-10-31 00:37:34 +00:00

Author

Owner

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

Agree — #3569 is the canonical parent proposal, and this issue's real addition is the runtime-observation boundary under terminal64.exe, so indexing it under Section 1 of #4330 is right. When consolidating, I'd keep the runtime notes (module discovery tied to the running terminal process, static/dynamic correlation) attached to #3569 so the phased roadmap doesn't lose the dynamic half of the scope — static-first MVP shouldn't silently drop it.

@XinwangTao commented on GitHub (Oct 20, 2026): Agree — #3569 is the canonical parent proposal, and this issue's real addition is the runtime-observation boundary under terminal64.exe, so indexing it under Section 1 of #4330 is right. When consolidating, I'd keep the runtime notes (module discovery tied to the running terminal process, static/dynamic correlation) attached to #3569 so the phased roadmap doesn't lose the dynamic half of the scope — static-first MVP shouldn't silently drop it.

bsakaguchi referenced this issue

2026-10-31 00:42:58 +00:00

[GH-ISSUE #6031] [Bug] Ghidra override-policy conflicts blame the target instead of the configured setting #3676

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#3178

No description provided.

Rows
Columns

[GH-ISSUE #5185] Feature Request: Support Analysis of MQL5 .ex5 Expert Advisors Loaded by terminal64.exe #3178

Before submitting

Area

Current limitation

Use cases

Desired outcome and success criteria

Expected interaction with targets

Target and scope details (optional)

Verification available so far

Verification details (optional)

Alternatives considered

Possible direction

References

[GH-ISSUE #5185] Feature Request: Support Analysis of MQL5 `.ex5` Expert Advisors Loaded by `terminal64.exe` #3178