EX4 to MQ4 Decompiler: Recovering Source Code from Copy-Trading EAs and DLL-Protected Files

EX4 to MQ4 Decompiler: Recovering Source Code from Copy-Trading EAs and DLL-Protected Files

Recovering source code from an EX4 file can become significantly more complicated when the program is a copy-trading Expert Advisor, uses external libraries, depends on DLLs, or includes licensing and protection mechanisms.

A simple EX4 file may contain most of the functionality needed by the Expert Advisor itself. A more complex trading system may instead rely on several components working together.

For example:

CopyTradingEA.ex4

        ↓

Signal processing

        ↓

EX4/EX4 library

        ↓

External DLL

        ↓

Server/API or additional service

In this situation, recovering or reconstructing the MQ4 source of the main EX4 does not necessarily recreate every component of the original system.

This guide explains what makes these files different, what source-code recovery can realistically involve, and why copy-trading EAs and DLL-dependent programs require a broader technical assessment.

Important: Source-code recovery should only be performed on software you own or are authorized to analyze.

What Is an EX4 to MQ4 Decompiler?

An EX4 to MQ4 decompiler generally refers to software or a service intended to analyze a compiled MetaTrader 4 EX4 program and reconstruct source-level information.

The terminology can be misleading.

An EX4 is the compiled form of an MQL4 application, while MQ4 is source code. Therefore, recovering MQ4 from EX4 is not equivalent to converting one ordinary file format into another.

The realistic objective may instead be:

• source-code reconstruction,
• functional reconstruction,
• program analysis,
• maintenance of an old EA,
• recovery of lost trading logic,
• or redevelopment of a compatible MQ4 implementation.

The exact result depends on the individual EX4.

Why Copy-Trading EAs Are More Complicated

A basic Expert Advisor might perform its calculations and trading operations entirely inside one program.

A copy-trading EA can have a much larger architecture.

For example:

Master Account

      ↓

Signal Generation

      ↓

Communication Layer

      ↓

Copy-Trading EA

      ↓

Risk / Lot Calculation

      ↓

Slave Account

Some systems use files, sockets, local communication, libraries or external components to transfer information between programs.

MetaQuotes has documented examples of MetaTrader programs exchanging information through external components, including DLL-based communication. (MQL5)

Therefore, looking at only one EX4 may not tell the entire story.

What Is a Copy-Trading EA?

A copy-trading Expert Advisor is generally designed to receive, interpret or reproduce trading information.

Depending on the system, that information can include:

• symbol
• direction
• entry price
• stop loss
• take profit
• lot size
• trade identifier
• account information
• position changes
• order closures

A simplified architecture could look like:

SOURCE ACCOUNT

      │

      ▼

SIGNAL / TRADE DATA

      │

      ▼

COPYING COMPONENT

      │

      ▼

TARGET MT4 ACCOUNT

The implementation can vary significantly.

Some systems communicate through local files, while others use libraries, network communication or external services.

Why Recovering a Copy-Trading EA Can Be Difficult

A copy-trading EA may not contain the entire system inside the EX4.

For example, the EX4 could contain the client-side logic while a separate DLL handles:

• communication,
• encryption,
• data processing,
• account validation,
• licensing,
• or another proprietary function.

MetaQuotes documents that MQL programs can import functions from DLL libraries, and that the imported module must be available for those functions to work. (MQL5)

This creates an important distinction:

Recovering the EX4 does not automatically recover the DLL’s internal source code.

EX4 + DLL: What Does the DLL Actually Do?

A DLL is an external binary library.

An MQL program can declare functions from a DLL using an import section.

A simplified example is:

#import "MyLibrary.dll"

   int ProcessSignal(string symbol);

   double CalculateRisk(double balance);

#import

The EA can then call those functions while it is running.

MetaQuotes’ documentation describes imported functions and the loading of external DLL modules during program execution. (MQL5)

This means a trading EA can effectively have two separate layers:

MQL4 / EX4

     │

     ├── Trading interface

     ├── Inputs

     ├── Order handling

     └── DLL calls

              │

              ▼

          External DLL

              │

              └── Additional functionality

If the DLL contains important proprietary logic, recovering the EX4 alone will not recreate that internal DLL implementation.

Can an EX4 Using a DLL Still Be Recovered?

Potentially, yes—but the scope needs to be defined correctly.

There are several different situations.

Situation 1: DLL Is Only a Supporting Component

The EA may contain most of its trading logic internally and use the DLL for a limited function.

In that situation, the EX4 may still provide substantial information about the EA.

Situation 2: DLL Contains Important Trading Logic

The EX4 may primarily act as an interface to the DLL.

For example:

EX4

 │

 ├── receives market data

 ├── calls DLL

 └── executes returned decision

             ↓

          DLL

             ↓

       Trading logic

Recovering the EX4 alone would not reproduce the complete system.

Situation 3: DLL Handles Communication

The DLL may be responsible for communication with another application or service.

MetaQuotes has published examples showing how MT4 programs can communicate with external applications through DLL-based mechanisms. (MQL5)

In this situation, the recovered MQ4 may require the original DLL or a replacement implementation to function correctly.

What About DLL-Protected EAs?

Some EA developers use DLLs as part of software protection or licensing systems.

For example, an EA may check:

• account number
• license status
• expiration date
• server information
• installation information
• file integrity

The exact architecture varies between products.

A source-recovery assessment should therefore determine whether the DLL is:

1. a dependency,
2. a communication layer,
3. a licensing component,
4. a calculation engine,
5. or a combination of these.

What Can Be Seen From the EX4?

Depending on the specific file, an assessment may identify useful information such as:

• imported functions
• program structure
• external dependencies
• input parameters
• trading-related operations
• indicator references
• library references
• program behavior

However, identifying a DLL import does not mean the internal source code of that DLL is available.

For example:

#import "RiskEngine.dll"

   double CalculateRisk(double balance);

#import

The EX4 can contain information needed to call the function, but the implementation of CalculateRisk() resides in the external library.

That distinction is critical when estimating the scope of recovery.

Copy-Trading EA Dependencies

A copy-trading system may include multiple files.

For example:

CopyMaster.ex4

CopyReceiver.ex4

SignalLibrary.ex4

Communication.dll

Settings.ini

Configuration.set

Recovering only:

CopyReceiver.ex4

may not provide everything needed to rebuild the entire system.

A complete assessment should therefore collect all legally available components.

EX4 Libraries Can Also Matter

MQL4 supports libraries that can be called by other programs.

MetaQuotes documents that the MQL4 libraries directory can contain MQ4 source files and compiled EX4 libraries used by other MQL4 programs. (MQL5)

For example:

MainEA.ex4

     ↓

TradingLibrary.ex4

     ↓

RiskLibrary.ex4

If the main EA depends on these libraries, recovering the main EX4 without the libraries may leave missing functionality.

This is one reason a single-file recovery can sometimes be incomplete.

Build 509 vs Build 600+ Still Matters

MT4 changed significantly beginning with Build 600.

MetaQuotes documented changes to the MQL4 language, development environment and file structure during the Build 600 transition. Old EX4 programs were copied during the upgrade rather than automatically recompiled. (MQL5)

This historical information can be important when evaluating an old EX4.

A recovery assessment should therefore record, where possible:

• approximate compiler generation
• terminal build
• original development environment
• age of the EX4
• related libraries
• DLL dependencies

Older and newer programs should not automatically be assumed to have the same recovery characteristics.

Does DLL Protection Mean the EX4 Contains No Useful Information?

Not necessarily.

A DLL-dependent program can still contain useful program-level information.

The important question is where the functionality actually resides.

Consider two architectures.

Architecture A

EX4

 ├── Entry logic

 ├── Exit logic

 ├── Risk management

 └── DLL → licensing only

Recovering the EX4 may potentially provide substantial information about the trading logic.

Architecture B

EX4

 ├── Market data

 ├── DLL call

 └── Order execution

DLL

 ├── Entry logic

 ├── Exit logic

 ├── Risk management

 └── Signal processing

In this architecture, recovering only the EX4 would leave a major part of the system outside the recovered source.

This is why file assessment matters more than the file extension alone.

What Does “Protected EX4” Actually Mean?

“Protected” can describe several different things.

It may refer to:

• licensing
• account restrictions
• external DLL dependencies
• proprietary communication
• anti-tampering mechanisms
• encrypted or obfuscated data
• commercial distribution controls

These mechanisms should not automatically be treated as identical.

A protected EX4 can still be analyzed for legitimate maintenance or recovery purposes, but the technical scope depends on how the protection was implemented.

What Can Actually Be Recovered?

A realistic recovery project can fall into several categories.

1. Source-Level Reconstruction

The goal is to produce editable MQL4 source representing as much of the original program as practical.

2. Functional Reconstruction

The objective is to reproduce the behavior of the original program rather than recreate the original developer’s exact source.

3. Dependency Mapping

The goal is to identify what the EX4 relies on.

For example:

Main EA

 ├── Indicator A

 ├── Library B

 └── DLL C

This can be extremely useful when maintaining an old trading system.

4. Maintenance Recovery

Sometimes the user does not need the entire original project.

They may only need to:

• change an input,
• update compatibility,
• fix a bug,
• replace a dependency,
• change risk parameters,
• modify an alert,
• or migrate an old EA.

In that case, functional reconstruction may be more practical than attempting to reproduce the original project exactly.

What Usually Cannot Be Promised

A professional EX4-to-MQ4 service should avoid promising that every file will produce the original MQ4 source.

The following should not automatically be guaranteed:

• identical source code
• original comments
• original variable names
• original function names
• original formatting
• complete external DLL source
• missing library source
• identical project structure

The more dependencies a program has, the more important these limitations become.

What If the Original DLL Is Missing?

This is one of the most important questions.

If the EA requires:

TradingEA.ex4

+

TradingCore.dll

and only the EX4 is available, the recovered MQ4 may still be useful, but it may not operate exactly as the original.

There are several possible approaches depending on the purpose:

Reconnect the original dependency

If the DLL is legitimately available, restore the required dependency.

Replace the dependency

If the functionality can be recreated, a developer may implement a replacement.

Remove the dependency

If the DLL performs a nonessential function, it may be possible to redesign the program without it.

Rebuild the relevant functionality

If the required behavior can be determined, it may be possible to recreate the relevant component independently.

These are development decisions rather than simple file-conversion operations.

Testing a Recovered Copy-Trading EA

Testing is especially important for copy-trading systems.

A recovered EA should be tested for:

Signal accuracy

Does the receiver recognize the intended signal?

Symbol mapping

Does the system correctly map instruments?

Lot calculation

Does the target account receive the appropriate volume?

Stop-loss and take-profit

Are protective levels reproduced correctly?

Trade opening

Are positions opened under the same conditions?

Trade modification

Are changes to the source position reflected correctly?

Trade closure

Does the receiving EA close positions when expected?

Duplicate prevention

Does the EA avoid opening duplicate trades?

Connection failures

What happens if communication is temporarily unavailable?

Account restrictions

Does the EA respond correctly when account conditions change?

These tests can reveal differences that would not appear simply by compiling the reconstructed MQ4.

A Practical Recovery Workflow for Copy-Trading EAs

Step 1: Preserve Every Original File

Keep the original files untouched.

Collect:

EX4

EX4 libraries

MQ4 files

MQH files

DLLs

SET files

configuration files

documentation

Step 2: Map the Architecture

Create a dependency diagram.

For example:

Master EA

   │

   ▼

Signal / Data Layer

   │

   ├── Library.ex4

   │

   └── Communication.dll

             │

             ▼

       Receiver EA

This immediately shows whether the main EX4 is self-contained.

Step 3: Identify the MT4 Environment

Record the relevant MT4 build and available source/development information.

Build history can affect compatibility and program structure. (MQL5)

Step 4: Determine the Recovery Objective

Ask:

Do you need the original source, editable code, or simply a working replacement?

Those are different projects.

Step 5: Assess Dependencies

Determine whether the EA uses:

• EX4 libraries
• DLLs
• indicators
• external files
• communication services
• licensing systems

Step 6: Reconstruct the MQ4 Where Technically Appropriate

The resulting source should be treated as reconstructed code unless there is strong evidence that the original source itself has been recovered.

Step 7: Compile and Debug

Compile the reconstructed source in the appropriate MQL4 environment.

Resolve:

• missing functions
• missing includes
• missing libraries
• incompatible calls
• type issues
• dependency errors

Step 8: Test Against the Original

Where possible, run the original and reconstructed programs under comparable conditions.

Compare:

• signals
• trades
• lot sizes
• SL/TP
• timing
• alerts
• communication
• error handling

Why “It Compiles” Is Not Enough

Suppose a recovered EA compiles successfully.

That proves that the source can produce an executable.

It does not prove that the resulting EA behaves identically.

For a copy-trading EA, a small difference in:

signal timing

or:

lot calculation

could produce substantially different trading results.

Therefore:

Compilation is one milestone, not the final validation.

EX4 Recovery vs DLL Recovery

These should be treated as separate technical problems.

A service that recovers an EX4 should not automatically imply that it has recovered the source code inside an external DLL.

Is It Possible to Recover a Complete Copy-Trading System?

Sometimes the available files may provide enough information to reconstruct a functional system.

But a complete system requires more than one EX4 if its architecture depends on external components.

For example:

COMPLETE SYSTEM

Master EA

   ↓

Signal engine

   ↓

Communication layer

   ↓

Receiver EA

   ↓

Risk management

   ↓

Broker execution

If several of these layers are proprietary binaries or remote services, recovering one EX4 will not necessarily recreate the entire system.

Legal and Ownership Considerations

Source-code recovery should be performed only where the user has the necessary ownership rights or authorization.

Possessing an EX4 file does not automatically establish permission to reverse engineer, reproduce or redistribute its source.

This is especially important for commercial copy-trading products, paid Expert Advisors and proprietary trading systems.

If the objective is legitimate maintenance of software you own, keep documentation showing your ownership or authorization.

Frequently Asked Questions

Can an EX4 copy-trading EA be converted to MQ4?

A source-recovery or functional-reconstruction process may be possible depending on the specific EX4, its compiler generation and dependencies.

Can DLL-protected EX4 files be recovered?

The presence of a DLL changes the scope of the project. The EX4 and DLL are separate components, so recovering one does not automatically recover the other’s internal source.

Does an EX4 contain the DLL’s source code?

No. An external DLL is a separate binary module. MQL programs can import functions from DLLs at runtime. (MQL5)

What if my copy-trading EA uses an EX4 library?

The library should be treated as a separate dependency. MetaQuotes documents that MQL4 libraries can exist as compiled EX4 files and can be called by other MQL4 programs. (MQL5)

Can the original variable names and comments be recovered?

They should not be assumed to survive compilation or reconstruction.

Will a recovered EA behave exactly like the original?

That should be verified through testing rather than assumed.

What files should I provide for a recovery assessment?

Ideally provide all legally available related files: EX4s, MQ4/MQH files, libraries, DLLs, configuration files, SET files and documentation.

Is a copy-trading EA harder to recover than a simple EA?

It can be, particularly when the system depends on multiple EAs, libraries, DLLs or external communication.

Final Takeaway

An EX4 to MQ4 decompiler should not be viewed as a magic tool that automatically restores every line of an original trading system.

This becomes especially important with copy-trading EAs and DLL-protected programs.

A modern trading application may consist of:

EX4

+

EX4 libraries

+

DLLs

+

configuration

+

external communication

Recovering the main EX4 can therefore be only one part of the project.

The most reliable approach is to first map the complete architecture, identify the dependencies, establish the recovery objective, reconstruct what can legitimately be recovered, and then validate the resulting MQ4 through compilation and functional testing.

For copy-trading systems, the final question should not simply be:

“Can this EX4 become MQ4?”

It should be:

“What parts of the original system can realistically be reconstructed, and what dependencies are required to make the recovered program function correctly?”

• Share :