Source Code Protection

Why source code protection matters 

In commercial desktop applications, distributed binaries contain the application’s business logic, configuration, and assets. Without protection, these resources can be extracted and analyzed.

Typical sensitive components include:

• Proprietary business logic that differentiates the product.
• Licensing and authentication mechanisms.
• API keys and configuration data.
• Algorithms and domain-specific implementations.

In desktop applications built with JavaScript, bundled source code is often stored in a readable format. This allows attackers or competitors to:

• Inspect internal logic.
• Modify application behavior (tampering).
• Extract intellectual property.
• Analyze licensing or validation mechanisms.

Robust protection mechanisms reduce the likelihood of successful reverse engineering and increase the effort required to analyze application internals.

Packaging in Electron 

Electron uses the ASAR (Atom Shell Archive) format to package application files into a single archive. This approach simplifies distribution and improves file system organization.

However, ASAR is not a security mechanism. Its limitations include:

• The archive format is publicly documented.
• Archives can be extracted using standard tools (e.g., asar extract).
• JavaScript and resource files remain readable after extraction.
• No encryption or runtime integrity protection is provided.

As a result, applications packaged with ASAR alone remain vulnerable to inspection and modification. Many Electron developers end up implementing their own protection mechanisms, which requires additional engineering effort and ongoing maintenance.

Protection mechanism in MōBrowser 

MōBrowser includes a built-in source code protection mechanism designed to mitigate extraction and tampering risks.

Protected files are bound to the specific application build in which they were generated. They cannot be reused or redistributed across different application builds.

Security model 

The protection mechanism is designed to mitigate:

• Static extraction of bundled source code.
• Casual reverse engineering.
• Direct modification of packaged resources.
• Repackaging of extracted assets into other builds.

It increases the complexity and effort required for code inspection, logic analysis, and binary tampering. However, no client-side protection mechanism can guarantee complete resistance against advanced reverse engineering techniques.

Performance considerations 

The protection system is designed to minimize runtime overhead.

• On-demand decryption. Files are decrypted only when accessed.
• In-memory caching. Decrypted content is cached to avoid repeated operations.
• Optimized decryption routines. The runtime impact is typically minimal for standard desktop workloads.

In most applications, the overhead is negligible relative to normal application processing. Actual performance impact may vary depending on application size and access patterns.

Build-time overhead is minimal and integrated into the standard build pipeline.

Unprotected resources 

Some files may not require protection. Resources that must remain accessible on the local file system can be placed in the project’s root resources directory.

Files in this directory:

• Are copied into the application bundle without encryption.
• Remain accessible via the file system at runtime.

Electron (ASAR) vs MōBrowser 

Electron ASAR simplifies packaging, but does not protect your source code.

MōBrowser encrypts your application’s source code and resources during the build process and decrypts them securely at runtime. It protects your intellectual property from extraction and tampering.