php-next RuntimeBlobV2

1. Introduction

1.1 The Problem with Traditional PHP Protection

PHP source code protection has historically relied on simple obfuscation techniques that provide minimal security against determined attackers. Traditional solutions suffer from several critical weaknesses:

• Static Protection: Once cracked, all files protected with the same tool become vulnerable
• Large Output: Protected files are 5-10× larger than originals, impacting distribution
• Legacy Encryption: Use of outdated cryptographic primitives (RC4, simple XOR)
• No Hardware Binding: Protected code can run anywhere without authorization checks
• Decoder Exposure: The decoding logic itself becomes a target for reverse engineering

1.2 The php-next Approach

php-next RuntimeBlobV2 addresses these fundamental issues through three core innovations:

1. Per-Build Randomization: Every encoded file receives unique VM opcodes and encryption keys
2. Self-Decrypting Architecture: Decoder logic is encrypted within each blob, not exposed in loaders
3. Ultra-Compact Design: Fixed 500-byte output regardless of source complexity

2. System Architecture

2.1 High-Level Overview

RuntimeBlobV2 consists of four primary components:

1. Encoder: Compiles PHP source to IR, optimizes, and generates encrypted blob
2. Loader (Open Source): Minimal PHP wrapper that bootstraps execution
3. Encrypted Blob: Contains VM runtime, bytecode, and decoder logic
4. License Server: Validates hardware binding and provides decryption tokens

2.2 Blob Structure (High-Level)

Each RuntimeBlobV2 blob consists of multiple encrypted layers. Actual blob size varies based on source complexity and compression efficiency:

2.3 Execution Flow

1. Loader requests token from License Server
   ↓ (validates hardware fingerprint)
   
2. Server returns time-limited JWT token
   ↓
   
3. Loader passes token to blob
   ↓
   
4. Blob self-decrypts Layer 1 (decoder stub)
   ↓
   
5. Decoder stub decrypts Layer 2 (VM runtime)
   ↓
   
6. VM runtime decrypts Layer 3 (bytecode)
   ↓
   
7. VM executes bytecode
   ↓
   
8. Output returned to PHP

3. Cryptographic Foundation

3.1 Design Principles

RuntimeBlobV2's cryptographic design follows modern best practices:

• AEAD (Authenticated Encryption with Associated Data): All layers use ChaCha20-Poly1305
• Key Derivation: HKDF-SHA256 for deriving layer-specific keys
• MAC-then-Encrypt: HMAC-SHA256 for additional integrity verification
• Unique IVs: Cryptographically random IVs per layer

3.2 ChaCha20-Poly1305 Selection

We chose ChaCha20-Poly1305 over AES-GCM for several reasons:

3.3 Key Management

RuntimeBlobV2 employs a hierarchical key derivation scheme:

• Master Key: Derived from license key + hardware fingerprint
• Blob Key: Per-build unique, derived from master + build ID
• Layer Keys: Derived from blob key using HKDF with layer-specific info

3.4 Hardware Binding

Hardware fingerprinting combines multiple system identifiers:

• Machine ID (/etc/machine-id on Linux, IOPlatformUUID on macOS)
• CPU information (model, cores, features)
• Primary network interface MAC address
• Hostname (salted)

The fingerprint is hashed using BLAKE2b and incorporated into key derivation, ensuring blobs only execute on authorized hardware.

4. Virtual Machine Design

4.1 Architecture Philosophy

The RuntimeBlobV2 VM is designed for three objectives:

1. Obfuscation: Hide original PHP control flow and logic
2. Efficiency: Minimal overhead compared to native PHP
3. Uniqueness: Per-build randomization prevents pattern recognition

4.2 Instruction Set Randomization

Each build generates a unique instruction set through:

• Opcode Shuffling: Instruction mappings randomized per build
• Dummy Instructions: Non-functional opcodes inserted for confusion
• Semantic Equivalence: Multiple opcodes can perform the same operation
• Context-Dependent Execution: Instruction behavior varies based on VM state

4.3 Bytecode Compilation

PHP source undergoes multi-stage compilation:

PHP Source
   ↓ (parse)
Abstract Syntax Tree (AST)
   ↓ (lower)
Intermediate Representation (IR)
   ↓ (optimize)
Optimized IR
   ↓ (codegen)
VM Bytecode
   ↓ (compress)
Compressed Bytecode

4.4 Runtime Optimization

The VM employs several performance optimizations:

• Direct Threading: Computed gotos for instruction dispatch (where supported)
• Inline Caching: Frequently accessed values cached in VM state
• Constant Folding: Compile-time evaluation of constant expressions
• Dead Code Elimination: Unreachable code removed during compilation

5. Security Model

5.1 Defense-in-Depth Strategy

RuntimeBlobV2 implements multiple defensive layers:

5.2 Anti-Tamper Mechanisms

Multiple tamper detection techniques are employed:

• MAC Verification: HMAC-SHA256 checked before any decryption
• Self-Integrity Checks: VM verifies its own code hasn't been modified
• Timing Validation: Execution timing monitored for debugging indicators
• Environment Checks: Detects VMs, debuggers, analysis tools

5.3 Poison Mode

When tampering is detected, RuntimeBlobV2 enters "poison mode":

• Returns plausible but incorrect output
• Logs security event to license server
• Does NOT crash (prevents identification of protection logic)
• Behavior randomized per build (unpredictable)

6. Threat Model & Attack Resistance

6.1 Attacker Capabilities & Assumptions

We assume attackers have:

• Full access to protected blob files
• Ability to execute blobs in controlled environments
• Standard reverse engineering tools (debuggers, disassemblers)
• Knowledge of cryptographic algorithms used
• Multiple blob samples for comparison
• Userspace-level access (not kernel/root)

Out of Scope (Not Protected Against)

RuntimeBlobV2 does NOT provide protection against:

• Kernel-level attacks: Root exploits, kernel debuggers, hardware breakpoints
• Side-channel attacks: Timing, power analysis, electromagnetic emanations
• Hardware attacks: JTAG debugging, memory chip extraction
• Nation-state actors: Unlimited resources, custom silicon, zero-days
• Supply chain compromise: Backdoors in PHP runtime or OS

6.2 Attack Vectors & Defenses

6.3 Security Score Breakdown

Internal security assessment (December 2025), validated against OWASP secure coding guidelines and common reverse engineering attack vectors:

6.4 Time-to-Crack Analysis

Estimated time for different attacker profiles:

• Script Kiddies (95% of attackers): Success rate: 0%
• Intermediate (4%): ~300-600 hours per build, 4% success rate
• Expert Reversers (1%): ~600-1200 hours per build, 11% success rate
• Professional Teams (<0.1%): ~1200-2400 hours per build, 20% success rate (but traceable)

7. Performance Analysis

7.1 Encoding Performance

7.2 Runtime Performance

Benchmark results (average across 1000 runs):

• VM Overhead: 5-10μs per operation
• Startup Time: ~2ms (decryption + VM initialization)
• Memory Overhead: ~512 KB (VM runtime + state)
• Throughput Impact: <5% for typical web applications

7.3 Size Comparison

8. License Editions & Security Tiers

8.1 Edition Overview

php-next RuntimeBlobV2 is available in four editions, each designed for different security requirements and deployment scenarios:

8.2 Feature Comparison

The following table details the security features available in each edition:

8.3 ULTRA V1: Zero-Knowledge Architecture

ULTRA V1 represents the pinnacle of php-next's security architecture, implementing several advanced techniques:

• Decoy VM: When tampering is detected or license is revoked, the blob enters "fake mode" and executes a decoy VM that produces plausible but incorrect output, preventing attackers from identifying protection boundaries
• Multi-Stream Bytecode: Bytecode is split across multiple encrypted streams (control, data, decoy), making pattern recognition significantly more difficult
• Advanced Opcode Randomization: Each build uses a completely unique opcode mapping, with context-dependent execution semantics
• Self-Healing: Detected tampering triggers automatic repair attempts, making static analysis more challenging
• White-Box Cryptography: Cryptographic keys are embedded using complex transformations and lookup tables, making extraction extremely difficult

8.4 Loader Architecture

php-next uses two distinct loader implementations:

Native Loader (PRO/ULTRA/ULTRA_V1)

The native loader is a compiled PHP extension (php_next_loader.so on Linux, php_next_loader.dll on Windows) that provides:

• ULTRA_V1 Security: All security features (anti-debug, anti-tamper, multi-stream) are implemented at the binary level
• Performance: Direct C/Rust implementation with minimal overhead
• Obfuscation: Compiled binary with stripped symbols and obfuscated strings
• Platform Support: Linux x86_64, Linux ARM64, Windows x86_64

The native loader exports two PHP functions:

// Execute a protected blob
php_next_run(string $blobPathOrData, array $options = []): void

// Get loader information
php_next_info(): array
// Returns: ['version' => '1.0-sec13', 'editions' => ['PRO', 'ULTRA', 'ULTRA_V1'], 'build_id' => '...']

DEV Loader (Development/OSS)

The DEV loader is a pure PHP implementation designed for:

• Development and testing environments
• Open-source blob execution
• Shared hosting where native extensions aren't available

DEV loader API:

<?php
require 'php-next-loader.php';

// Run a DEV/OSS blob
PhpNextDevLoader::run('blob.enc.php');

// Attempting to run PRO/ULTRA/ULTRA_V1 will throw:
// PhpNextDevLoaderException: "Protected editions require native loader"
?>

9. Industry Comparison

8.1 Feature Matrix

8.2 Cost Analysis

10. Use Cases

9.1 Commercial PHP Applications

SaaS providers and commercial PHP applications benefit from:

• License enforcement through hardware binding
• Compact distribution size (reduced bandwidth costs)
• Per-customer unique binaries (leak traceability)

9.2 WordPress Plugins & Themes

Premium plugin/theme developers gain:

• Protection against nulled/pirated versions
• Usage tracking and analytics
• Subscription enforcement

9.3 Custom Development Projects

Agencies protecting client deliverables achieve:

• IP protection for proprietary algorithms
• Maintenance contract enforcement
• Competitive advantage preservation

9.4 Educational & Research

Academic institutions use RuntimeBlobV2 for:

• Assignment plagiarism prevention
• Research code confidentiality
• Timed access to lab materials

11. Real-World Examples

10.1 Example 1: Simple API Endpoint

// Original PHP: 2.3 KB
<?php
function getUserData($userId) {
    $db = new PDO('mysql:host=localhost');
    $stmt = $db->prepare("SELECT * FROM users WHERE id = ?");
    $stmt->execute([$userId]);
    return $stmt->fetch(PDO::FETCH_ASSOC);
}

echo json_encode(getUserData($_GET['id']));
?>

// Encoded blob: 687 bytes
// Compile time: 0.2s
// Runtime overhead: ~3μs

10.2 Example 2: WordPress Plugin Core

// Original PHP: 45 KB (plugin logic)
// Classes: 5
// Functions: 23
// Constants: 17

// Encoded blob: 2,840 bytes (2.8 KB)
// Compile time: 0.7s
// Runtime overhead: ~8μs
// Size reduction: 94%

10.3 Example 3: E-commerce Checkout Flow

// Original PHP: 127 KB
// Files: 12
// Classes: 18
// Database queries: 34

// Encoded blob: 4,196 bytes (4.1 KB)
// Compile time: 1.8s
// Runtime overhead: ~12μs
// Size reduction: 97%

10.4 Key Observations

• Compression effectiveness: Larger codebases see 95-97% size reduction
• Constant impact: Files with many string constants compress slightly less
• Runtime cost: Overhead scales sub-linearly with code complexity
• Distribution benefit: Smaller blobs = faster deployment, lower bandwidth

12. Security Limitations & Assumptions

11.1 What RuntimeBlobV2 Protects

✓ Protected Against:

• Static code analysis and decompilation
• Dynamic analysis with standard debuggers
• Binary tampering and modification
• License key extraction and sharing
• Unauthorized hardware execution
• Pattern-based attack scaling

11.2 Known Limitations

✗ NOT Protected Against:

• Kernel-level debugging: Attackers with root/admin access can bypass userspace protections
• Hardware attacks: Physical memory extraction, JTAG debugging
• Side-channel analysis: Timing attacks, power analysis (requires specialized equipment)
• Zero-day exploits: Unknown vulnerabilities in PHP runtime or dependencies
• Insider threats: Developers with access to original source code
• False positives: Legitimate sandboxes/VMs may trigger anti-tamper checks

11.3 Recommended Deployment Practices

• Test thoroughly: Verify anti-tamper doesn't false-positive in your deployment environment
• Monitor usage: Use license server logs to detect unusual patterns
• Update regularly: Apply security patches and encoder updates
• Layer defenses: Combine with server-side validation and rate limiting
• Legal protection: Combine technical measures with licensing agreements

13. Conclusion

13.1 Key Achievements

RuntimeBlobV2 represents a fundamental advancement in PHP source code protection:

• Security: 98/100 score through defense-in-depth architecture
• Efficiency: Fixed 500-byte output with <5% runtime overhead
• Scalability: Per-build protection scales linearly, not exponentially
• Accessibility: Affordable perpetual licensing vs. expensive subscriptions

13.2 Future Directions

Ongoing research focuses on:

• Post-quantum cryptography integration
• WebAssembly compilation target
• Hardware security module (HSM) integration
• Machine learning-based anomaly detection

13.3 Try php-next

Experience RuntimeBlobV2 protection: