Introduction to Trojan Source Detection

During a recent red team engagement for a fintech firm in Bengaluru, I encountered a pull request that appeared to be a standard logic fix for a transaction fee calculator. The code looked clean in the GitHub UI. However, a manual check using a hex editor revealed hidden Unicode bidirectional (BiDi) control characters. These characters manipulated the visual order of the code without changing its logical execution. This is the essence of a Trojan Source attack.

What is a Trojan Source Attack?

Trojan Source attacks exploit the discrepancy between how a compiler or interpreter parses source code and how a human developer perceives it in an IDE. By using specific Unicode characters, an attacker can reorder the visual display of code elements. A line of code that looks like a comment to a human might be executed as part of the logic by the JavaScript engine.

We observed that these attacks primarily target the supply chain. If a developer copies a snippet from an unverified forum or a malicious contributor submits a PR, the hidden logic can bypass traditional security reviews. The most common manifestations are Bidirectional (BiDi) overrides and Homoglyph attacks.

The Mechanics of Unicode-Based Vulnerabilities

Unicode includes control characters designed to support scripts that read from right-to-left (RTL), such as Arabic or Hebrew. The Bidirectional Algorithm (BiDi) handles the mixing of left-to-right (LTR) and RTL text. Attackers use these control characters to "flip" the visual direction of strings and comments.

For instance, the character U+202E (Right-to-Left Override) tells the UI to display the following text in reverse order. If placed inside a comment, it can make subsequent code appear as part of that comment, while the compiler sees it as executable logic. In JavaScript, this can lead to critical bypasses in authentication or authorization checks.

Why Traditional Code Reviews Fail to Spot These Threats

Most web-based Git interfaces and many legacy IDE configurations do not render BiDi control characters by default. They are invisible. A reviewer sees:

if (isAdmin) { // Check if user is admin      executeSensitiveAction(); }

But the actual byte sequence might include a BiDi override that makes the closing brace of the if statement appear inside the comment, effectively moving executeSensitiveAction() outside the conditional block. Without specialized tooling, the human eye is incapable of detecting these deviations.

---

Core Mechanisms: Bidi and Homoglyph Attacks

We categorize Trojan Source attacks into two primary vectors: BiDi overrides (CVE-2021-42574) and Homoglyph identifiers (CVE-2021-42694), both of which are documented in the NIST NVD. Both techniques rely on the visual ambiguity of Unicode.

Understanding Bidirectional (Bidi) Overrides (CVE-2021-42574)

CVE-2021-42574 describes the use of BiDi control characters to reorder code. The dangerous characters include:

• U+202A: Left-to-Right Embedding (LRE)
• U+202B: Right-to-Left Embedding (RLE)
• U+202C: Pop Directional Formatting (PDF)
• U+202D: Left-to-Right Override (LRO)
• U+202E: Right-to-Left Override (RLO)
• U+2066: Left-to-Right Isolate (LRI)
• U+2067: Right-to-Left Isolate (RLI)
• U+2068: First Strong Isolate (FSI)
• U+2069: Pop Directional Isolate (PDI)

When these characters are embedded in string literals or comments, they change the visual layout of the entire line. I have seen cases where a PDI character was used to prematurely "end" a comment visually, while the actual comment continued until the newline character.

The Danger of Homoglyph and Near-Visual Identifiers (CVE-2021-42694)

CVE-2021-42694 involves homoglyphs—characters that look identical or nearly identical but have different Unicode points. A classic example is the Latin 'a' (U+0061) versus the Cyrillic 'а' (U+0430).

In a large codebase, an attacker could define a malicious function using a homoglyph name:

const userIsAdmin = () => true; // Maliciously defined elsewhere const userIsAdmіn = () => false; // The real function (note the Cyrillic 'і')

If the developer calls the malicious version, the visual difference is zero in most fonts, but the logic is entirely different. This is particularly effective in environments where external libraries are frequently audited but local utility files are overlooked.

How Invisible Characters Alter Logic Flow

Invisible characters like the Zero Width Space (U+200B) or Zero Width Non-Joiner (U+200C) can be used to break string comparisons or variable name matching. During our testing, we injected a Zero Width Space into a configuration key. The application failed to match the key against its whitelist, defaulting to a permissive "all-access" state. Because the character has no width, the configuration file looked perfectly valid to the sysadmin.

---

Effective Methods for Trojan Source Detection

Detection must happen at multiple layers: the developer's local environment, the pre-commit stage, and the CI/CD pipeline. Relying on a single point of failure is a recipe for a breach.

Leveraging IDE Extensions and Visual Indicators

Modern IDEs like VS Code have started implementing native warnings for BiDi characters. However, I often find these settings disabled in Indian SDCs (Software Development Centers) to reduce "noise" in legacy projects. We recommend enforcing the following VS Code settings via .vscode/settings.json:

{   "editor.unicodeHighlight.ambiguousCharacters": true,   "editor.unicodeHighlight.invisibleCharacters": true,   "editor.unicodeHighlight.nonBasicASCIICharacters": true,   "editor.unicodeHighlight.allowedCharacters": {     "₹": true    } }

This configuration explicitly flags ambiguous and invisible characters while allowing the Indian Rupee symbol (₹), which is common in local financial applications.

Automated Scanning with Static Analysis (SAST) Tools

Static analysis tools must be configured to treat specific Unicode ranges as high-severity findings. Standard SAST rules often focus on SQL injection or XSS, ignoring the source code's encoding integrity, which is a vital component of modern threat detection. We use custom rules to scan for the BiDi control characters listed in CVE-2021-42574.

Using Grep and Command-Line Utilities to Find Hidden Unicode

For quick audits of a repository, especially when managing secure SSH access for teams across multiple remote servers, grep and ripgrep (rg) are the fastest tools. We use Perl-compatible regular expressions (PCRE) to identify the dangerous byte sequences.

To find BiDi characters recursively in a directory:

grep -rP '[\x{202A}-\x{202E}\x{2066}-\x{2069}]' .

To get a more detailed JSON output using ripgrep for integration with other tools:

rg --json '[\u202A-\u202E\u2066-\u2069]' | jq '.'

If you suspect a specific file, use cat -A to reveal non-printing characters. BiDi overrides often show up as ^[.

cat -A src/auth.js | grep -E '\^\['

We also utilize fdfind for targeted scans of specific file extensions:

fdfind -e js -x grep -lP '[\x{202A}-\x{202E}\x{2066}-\x{2069}]'

---

Integrating Detection into the Development Lifecycle

Manual scans are insufficient for continuous delivery, much like the processes required for Hardening CI/CD Pipelines. We must automate Trojan Source detection within the JavaScript ecosystem using ESLint and pre-commit hooks.

Implementing Custom ESLint Rules for Trojan Source Detection

ESLint provides a powerful framework for AST-based analysis. We can write a custom rule that scans the entire source text of a file for dangerous Unicode characters before the code is even parsed into an AST. This is crucial because BiDi characters can exist within comments, which some AST parsers might discard.

Create a file named eslint-rules/detect-bidi.js:

module.exports = {   meta: {     type: 'problem',     docs: {        description: 'Detect BiDi Trojan Source characters (CVE-2021-42574)',       category: 'Security',       recommended: true     },     schema: []   },   create(context) {     const bidiChars = /[\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]/;     return {       Program(node) {         const sourceCode = context.getSourceCode();         const text = sourceCode.getText();         if (bidiChars.test(text)) {           context.report({             node,             loc: { start: { line: 1, column: 0 }, end: { line: 1, column: 1 } },             message: 'Trojan Source Alert: Hidden BiDi control characters detected in file.'           });         }       }     };   } };

To run this rule against your project, use the --rulesdir flag:

npx eslint --rulesdir ./eslint-rules --ext .js,.ts .

Implementing Pre-commit Hooks for Unicode Validation

In the Indian IT sector, where many SMEs lack strict CI/CD enforcement, local pre-commit hooks are the first line of defense. We use husky and lint-staged to ensure no developer can commit code containing BiDi overrides.

Install the dependencies:

npm install husky lint-staged --save-dev npx husky install

Add the following to your package.json:

{   "lint-staged": {     "*.{js,ts}": "npx eslint --rulesdir ./eslint-rules"   } }

This setup forces the custom ESLint rule to run on every commit. If a BiDi character is detected, the commit is rejected, preventing the malicious code from ever reaching the remote repository.

Automating Trojan Source Scans in CI/CD Pipelines

For enterprise-grade security, the check must be replicated in the CI/CD pipeline. This prevents bypasses where a developer might use --no-verify to skip local hooks. Here is a sample GitHub Action configuration:

name: Security Scan on: [push, pull_request] jobs:   trojan-source-check:     runs-on: ubuntu-latest     steps:       - uses: actions/checkout@v3       - name: Install Dependencies         run: npm install       - name: Run Trojan Source Scan         run: |           npx eslint --rulesdir ./eslint-rules --ext .js,.ts .         continue-on-error: false

This pipeline ensures that any PR containing Trojan Source vectors is automatically flagged and blocked from merging, providing a critical safety net for the software supply chain.

---

Prevention Strategies and Security Best Practices

Detection is reactive; prevention is proactive. We must establish protocols that align with the OWASP Top 10 to make it difficult for Trojan Source attacks to succeed even if detection tools fail.

Establishing Code Review Protocols for Non-ASCII Characters

Code review checklists should include a mandatory check for non-ASCII characters in sensitive files (e.g., auth logic, payment gateways). If a developer uses a non-ASCII character, they must justify its presence. In the context of the DPDP Act 2023, ensuring the integrity of data processing logic is not just a technical requirement but a legal one for Indian companies handling personal data.

Restricting Unicode Usage in Critical Source Files

We recommend a "Strict ASCII" policy for core logic files. You can enforce this using a simple shell script in your CI pipeline that fails if any byte value exceeds 127 in specific directories.

Check if any file in src/core contains non-ASCII characters
find src/core -type f -name "*.js" -exec grep -P '[^\x00-\x7f]' {} + && exit 1 || exit 0

Updating Build Systems and Language Runtimes

Ensure that your build tools (Webpack, Vite, Esbuild) and runtimes (Node.js) are updated. Node.js has introduced mitigations to handle certain Unicode reordering issues, but these are not foolproof. The build process should ideally strip or escape all non-essential Unicode characters during the minification phase.

In your tsconfig.json or jsconfig.json, ensure that the encoding is explicitly set to UTF-8 to avoid misinterpretation by different environments:

{   "compilerOptions": {     "charset": "utf8",     "noEmit": true   } }

---

Conclusion: Securing the Software Supply Chain

The Trojan Source attack vector highlights a fundamental weakness in our reliance on visual code representation. As supply chain attacks become more sophisticated, particularly with the rise of AI-generated code that might inadvertently include malicious Unicode from its training data, automated detection is mandatory.

The Evolving Landscape of Source Code Obfuscation

We are seeing a shift from simple BiDi overrides to complex, multi-layered obfuscation that combines homoglyphs with Zero Width characters. Attackers are also targeting configuration files like .env or Dockerfile, where security linters are often less stringent.

Summary of Key Detection Tools and Techniques

To maintain a robust security posture, we recommend the following stack:

• ESLint: Custom rules for BiDi and Homoglyph detection.
• Ripgrep: Fast CLI scanning for CI/CD runners.
• Husky: Enforcement of security checks at the developer's machine.
• VS Code Settings: Mandatory highlighting of ambiguous Unicode characters.

For organizations operating under Indian jurisdiction, compliance with CERT-In advisories regarding supply chain security is essential. Implementing these custom ESLint rules directly addresses the risks of source code manipulation and helps meet the data integrity requirements of the DPDP Act 2023.

Verify your environment now:

$ grep -rP '[\x{202A}-\x{202E}\x{2066}-\x{2069}]' ./src