How to Decompile EX4 to MQ4 Using Reverse Engineering and Memory Dumping
If you have an old MetaTrader 4 EX4 file but no longer have the original MQ4 source code, you may come across techniques described online as EX4 decompilation, reverse engineering, or memory dumping.
These terms can sound like they describe a simple process:
EX4 → decompiler → MQ4
In reality, the situation is much more complicated.
An EX4 file is a compiled MQL4 program, while MQ4 is the source code used during development. Normal MQL4 development works in the opposite direction: source code is compiled into an executable program. (MQL5)
This article explains what reverse engineering and memory analysis mean in the context of EX4 files, why modern EX4 files are different from older versions, what source-code recovery can realistically involve, and why a recovered MQ4 file should not automatically be considered the original source.
Important: Any analysis or recovery should only be performed on software you own or are explicitly authorized to analyze. This article explains the concepts and recovery workflow without providing instructions for bypassing software protection, licensing, authentication, or other security controls.
EX4 vs MQ4: The Basic Difference
Before discussing reverse engineering, it is important to understand the two file types.
MQ4
MQ4 is the editable MQL4 source-code format.
Developers use it to create:
- Expert Advisors
- Custom indicators
- Scripts
- Libraries
- Trading tools
The source can be opened and modified using MetaEditor.
EX4
EX4 is the compiled program produced from MQL4 source.
The simplified development process is:
MQ4 source code → compiler → EX4 executable
The EX4 is intended to run inside MetaTrader 4 rather than provide the developer with the original editable project.
MetaQuotes’ documented MT4 file structure also distinguishes source files such as MQ4/MQH from compiled EX4 programs and libraries. (MQL5)
What Does “Decompile EX4 to MQ4” Actually Mean?
The phrase EX4 to MQ4 decompilation can be misleading.
A true compiler process does this:
MQ4 → EX4
A supposed decompiler attempts to go in the opposite direction:
EX4 → reconstructed source
But compiled code does not necessarily contain all of the information that existed in the original development project.
For example, the original project could have contained:
- Comments
- Meaningful variable names
- MQH include files
- Multiple source files
- External libraries
- DLL dependencies
- Development notes
- Original formatting
- Documentation
Those things should not automatically be expected to reappear in reconstructed source.
Therefore, source-code recovery is often a more accurate description than simply saying “convert EX4 to MQ4.”
What Is Reverse Engineering?
Reverse engineering is the process of analyzing an existing program to understand how it works.
With an EX4, a legitimate analysis might attempt to understand:
- Program structure
- Inputs
- Functions
- Control flow
- Trading operations
- Indicator calculations
- Risk-management behavior
- External dependencies
- File operations
- Program interactions
The objective can be to understand the application’s functionality rather than simply obtain a text representation of the executable.
This distinction is especially important for older MT4 applications where the original MQ4 project has been lost.
What Is Memory Dumping?
Memory dumping refers broadly to capturing information associated with a program while it is loaded or executing.
When software runs, portions of the executable and its working data may exist in the computer’s memory.
In general reverse-engineering research, memory analysis can therefore provide information that may not be obvious from inspecting a file on disk.
However, memory analysis is not equivalent to recovering the original MQ4 source code.
A memory image may contain:
- Runtime data
- Loaded program information
- Strings
- Temporary values
- Function-related information
- Data generated during execution
It does not automatically reconstruct the original developer’s complete source project.
Why Memory Dumping Does Not Mean “Instant MQ4”
One of the biggest misconceptions surrounding EX4 recovery is the idea that a memory dump can simply be converted into the original MQ4.
The actual process is considerably more complicated.
A conceptual workflow might look like:
EX4
↓
Program execution
↓
Runtime analysis
↓
Program behavior and structure
↓
Reverse-engineering analysis
↓
Source reconstruction
↓
MQ4 project
The final MQ4 is therefore potentially a reconstruction, not necessarily a copy of the original source.
Why Modern EX4 Files Matter
MT4 changed significantly with the introduction of Build 600 and later versions.
MetaQuotes documented major changes to the MQL4 language, compiler, MetaEditor and file structure during this transition. Existing EX4 files were not automatically recompiled simply because a terminal was upgraded. (MQL5)
This historical distinction matters when researching EX4 recovery.
Older EX4 files and modern EX4 files should not automatically be treated as technically equivalent.
Build 509 and Earlier
Older MQL4 programs were produced using the earlier MQL4 development environment.
Historical EX4 files from this period are frequently discussed in relation to decompilation because their underlying compiled representation differed from later versions.
Build 600+
Build 600 introduced major changes.
MetaQuotes described the newer EX4/EX5 format as having substantially revised protection, and MQL4 community discussions have repeatedly distinguished modern Build 600+ programs from older EX4 files. (MQL5)
MQL4 forum moderators have also repeatedly stated that there has been no publicly demonstrated general-purpose decompiler for modern EX4/EX5 files since Build 600. This is a community position rather than a guarantee concerning every individual file. (MQL5)
That is why claims such as:
“Every EX4 can now be converted into the original MQ4”
should be treated cautiously.
Disassembly vs Decompilation
These terms are often confused.
Decompilation
Decompilation attempts to produce a higher-level representation resembling source code.
Conceptually:
Executable → high-level source representation
Disassembly
Disassembly represents executable instructions in a lower-level form, such as assembly instructions.
Conceptually:
Executable → low-level instructions
These are very different results.
A program can potentially be analyzed at a lower level without producing the original MQL4 source.
MQL4 community discussions specifically distinguish between disassembly/reverse engineering and obtaining the original MQ4 source. (MQL5)
Why the Original Source Cannot Always Be Reconstructed
Compilation can remove or transform information that was useful to the developer.
For example, imagine the original source contained:
calculateRiskPercentage()
The compiled program does not necessarily preserve that exact human-readable function name in a form that can simply be restored.
The same applies to:
- Comments
- Formatting
- Source-file organization
- Development notes
- Variable names
- Macro definitions
- Original architecture
A reconstructed program may therefore use different names and organization while attempting to reproduce the same functionality.
EX4 Files With DLL Dependencies
DLLs make source recovery even more complicated.
An Expert Advisor can interact with external components rather than keeping every function inside the EX4.
A project might contain:
ExpertAdvisor.ex4
TradingLibrary.ex4
ExternalLibrary.dll
Configuration files
Preset files
The EX4 may call functionality supplied by another component.
Therefore:
Recovering the MQL4 portion ≠ recovering the DLL source code.
If the original DLL is unavailable, the resulting MQ4 project may need to reproduce only the MQL4-side behavior or replace the external functionality with an appropriate implementation.
Copy-Trading EX4 Programs
Copy-trading EAs can involve additional complexity.
A copy-trading application may include functionality for:
- Detecting trades
- Sending trade information
- Receiving trade information
- Symbol mapping
- Lot calculations
- Risk multipliers
- Magic numbers
- Trade filtering
- Account synchronization
- External communication
The EX4 may also depend on DLLs, libraries, files or external services.
Therefore, attempting to recover a copy-trading EA should involve understanding the complete architecture rather than treating the EX4 as an isolated file.
What Can Source-Code Recovery Potentially Produce?
Depending on the particular file, a legitimate recovery project may attempt to reconstruct:
- Trading logic
- Indicator calculations
- Entry conditions
- Exit conditions
- Risk management
- Position sizing
- Input parameters
- Order management
- Program structure
- External function calls
- Important dependencies
The resulting MQ4 may then be compiled and tested.
However, it should be clearly identified as reconstructed source unless there is independent evidence that the original project was recovered.
A Better Way to Think About EX4 Recovery
Instead of asking:
“Can this EX4 be magically converted into MQ4?”
a better technical question is:
“What information can be recovered from this particular EX4, and can the required functionality be reconstructed into maintainable MQL4 source?”
That question accounts for the differences between files, compiler generations, dependencies and protection.
A Professional EX4 Recovery Workflow
A responsible recovery project can follow several stages.
1. Identify the Files
Start by collecting all available project material:
- EX4
- MQ4
- MQH
- DLL
- EX4 libraries
- Presets
- Configuration files
- Documentation
- Backups
If an MQ4 backup exists, that is generally preferable to reconstructing source from an EX4.
2. Determine the Program Type
Identify whether the EX4 is:
- Expert Advisor
- Indicator
- Script
- Library
This helps determine what functionality needs to be examined.
3. Determine the Historical Build Context
Find out, where possible:
- Approximate creation date
- MT4 version
- MetaEditor/compiler generation
- Whether it is an old Build 509-era application
- Whether it is a newer Build 600+ application
The historical environment can materially affect the recovery assessment.
4. Identify Dependencies
Check whether the application relies on:
- EX4 libraries
- DLLs
- MQH files
- Other indicators
- Files
- Presets
- External services
MetaQuotes’ MT4 file structure explicitly provides separate locations for libraries, includes, files and presets, illustrating why an EX4 may be only one component of a larger application. (MQL5)
5. Analyze the Program
At this stage, authorized technical analysis can be used to understand the program’s architecture and behavior.
The objective is to establish what functionality can realistically be reconstructed.
6. Reconstruct the MQL4 Project
Where feasible, the required functionality can be recreated in MQ4.
This may involve writing new source code rather than literally restoring the original source.
7. Compile
The resulting MQ4 can be compiled using the appropriate MQL4 development environment.
8. Test
The recovered program should be compared against the original EX4 where possible.
Useful comparisons include:
- Inputs
- Signals
- Entries
- Exits
- Stop losses
- Take profits
- Lot sizes
- Risk calculations
- Indicator values
- Alerts
- Order management
Why Testing Is Essential
A source file that compiles successfully is not necessarily equivalent to the original program.
For example, a recovered EA might compile but contain a subtle difference in:
- Entry timing
- Spread handling
- Lot calculation
- Stop placement
- Indicator calculation
- Symbol mapping
- Risk management
That is why functional testing is as important as source reconstruction.
Backtesting
Use historical data to compare the original and reconstructed versions where practical.
Demo Testing
A demo account can be used to verify real-time behavior without immediately exposing live trading capital.
Side-by-Side Testing
If the original EX4 still operates, running the original and reconstructed versions under controlled conditions can help identify differences.
What About Protected EX4 Files?
Protection is an important consideration.
MetaQuotes introduced substantially revised protection with the newer MQL4 environment, and community documentation distinguishes modern EX4 programs from older files. (MQL5)
This means a service that claims it can recover every modern protected EX4 into the exact original MQ4 should be evaluated carefully.
A professional assessment should first determine:
- What type of EX4 is involved
- When it was produced
- What supporting files exist
- Whether dependencies are available
- What level of recovery is actually required
What Memory Analysis Cannot Guarantee
Memory analysis should not be presented as a guaranteed method for recovering:
- Original MQ4 comments
- Original source formatting
- Original variable names
- Original MQH files
- DLL source
- Server-side source
- Developer documentation
- Complete project history
Memory analysis is a technical analysis technique, not a magic source-code restoration mechanism.
EX4 Decompilation vs. Source Reconstruction
These terms are often used interchangeably in marketing, but they can describe different objectives.
|
Approach |
Main objective |
|
Decompilation |
Produce a higher-level representation from compiled code |
|
Disassembly |
Analyze lower-level executable instructions |
|
Memory analysis |
Examine runtime program information |
|
Source reconstruction |
Recreate maintainable source implementing required behavior |
|
Redevelopment |
Build a new implementation based on known functionality |
For many practical MT4 maintenance projects, source reconstruction or redevelopment may be a more realistic objective than claiming to have recovered the original source character-for-character.
Common EX4 Recovery Mistakes
Mistake 1: Renaming EX4 to MQ4
Changing:
EA.ex4
to:
EA.mq4
does not recreate source code.
Mistake 2: Assuming a Memory Dump Is the Original Source
Runtime data is not equivalent to the original developer project.
Mistake 3: Ignoring DLLs
External dependencies can contain functionality that is not inside the EX4.
Mistake 4: Ignoring MT4 Build History
An old EX4 and a modern EX4 should not automatically be treated the same way.
Mistake 5: Testing Only Compilation
Successful compilation does not prove functional equivalence.
Mistake 6: Believing Every Online Decompiler Claim
Modern EX4 protection has generated many competing claims online. MQL4 forum moderators have repeatedly questioned claims of general-purpose modern EX4 decompilation. (MQL5)
When Should You Recover EX4 Source?
Source recovery can make sense when:
- You own the EA
- You lost the MQ4 source
- The original developer is unavailable
- You need to maintain an old trading system
- You need to modify an existing application
- You need to migrate functionality
- You need to understand an inherited MT4 project
If you already have the original MQ4 source, working from that source is normally preferable.
What Should You Send for an EX4 Recovery Assessment?
If you are authorized to have the program analyzed, provide as much legitimate project information as possible:
- EX4 file
- Any MQ4 backup
- MQH files
- DLLs
- EX4 libraries
- Presets
- Configuration files
- Screenshots of inputs
- EA documentation
- Known MT4 build information
- Description of the changes you need
The more context available, the easier it is to determine whether the goal should be source recovery, reconstruction or redevelopment.
Frequently Asked Questions
Can I decompile an EX4 directly into MQ4?
There is no universal method that guarantees the original MQ4 source will be recreated. Modern EX4 protection and compiler changes make broad claims of guaranteed recovery especially questionable. (MQL5)
Can memory dumping recover EX4 source code?
Memory analysis can potentially provide information about a program while it is running, but it does not guarantee recovery of the original MQ4 project.
Does Build 600 matter?
Yes. Build 600 introduced major changes to MQL4 and its development environment, making the age and compiler generation of an EX4 relevant to any recovery assessment. (MQL5)
Can DLL code be recovered from an EX4?
Not automatically. A DLL is a separate component and its source code is not equivalent to the MQL4 source used to create an EX4.
Can an old EX4 be different from a modern EX4?
Yes. Historical MQL4 builds used different compiler and program formats, and MetaQuotes introduced significant changes beginning with Build 600.
Will recovered MQ4 be identical to the original?
Not necessarily. A reconstructed MQ4 can implement substantially the same functionality while having different names, formatting, organization and implementation.
Is source recovery better than redevelopment?
That depends on the project. If the required behavior can be clearly established but the original architecture cannot be restored, redevelopment may sometimes be the more practical approach.
Final Thoughts
The phrase “decompile EX4 to MQ4 using reverse engineering and memory dumping” describes a much more complicated technical problem than a simple file conversion.
The basic MT4 development model is:
MQ4 → compilation → EX4
Recovering the source requires working backward from a compiled program, and the available information depends on the EX4’s history, compiler generation, protection, dependencies and runtime behavior.
For older files, historical compiler differences can be particularly important. For modern Build 600+ EX4 files, strong claims of universal decompilation should be approached cautiously because MetaQuotes introduced substantially revised protection, and MQL4 community moderators have repeatedly disputed claims of general-purpose modern EX4 decompilation. (MQL5)
For an authorized recovery project, the practical objective should therefore be clearly defined:
recover the original source if genuinely available, reconstruct the required functionality where possible, or redevelop the application when reconstruction is not realistic.
The final MQ4 should then be compiled, tested and compared against the original program before it is relied upon for live trading.