Abstract

In the realm of cybersecurity, protecting software intellectual property (IP) remains a difficult and unresolved challenge. Traditional obfuscation techniques such as packing, virtualization, and encryption-at-rest—while effective against casual analysis—are routinely bypassed by sophisticated static and dynamic analysis tools. These approaches typically rely on reconstructible stubs, interpreters, or decryption keys that are identifiable in the binary or memory, presenting avenues for reverse engineering.

To address this limitation, we introduce Ghost Canvas, a novel obfuscation architecture based on three core principles: the vessel model, the canvas execution model, and the keystone derivation system. The vessel model uses dispersed single-byte carriers embedded in plausible library functions to conceal intent. The canvas execution model minimizes the residence time of assembled machine code in memory. The keystone derivation system uses a deterministic hash (we use SHA‑256) and a Fisher‑Yates permutation to convert a short secret into a deterministic assembly order so that an adversary must separately overcome multiple independent defenses. Earlier prototypes used a custom ARX mixer; we migrated to SHA‑256 for public verifiability and to reduce risk from unvetted cryptographic constructions.

In one sentence: Ghost Canvas compiles target code into many short, plausibly‑looking "vessel" functions that deposit single bytes onto a transient writable/executable canvas; a keystone‑derived permutation and a background "river" control assembly so the final code is assembled, executed once, and immediately destroyed.

This paper does not claim theoretical unbreakability. Instead, we present a design that increases the practical cost of recovery by compounding independent defenses and we evaluate those tradeoffs empirically.

1. Introduction

1.1 Problem Statement

In today's cybersecurity landscape, protecting software intellectual property remains an unsolved challenge. Despite advancements in encryption and virtualization techniques, adversaries continue to bypass these defenses through sophisticated static and dynamic analysis methods. Commercial software protection products such as Themida, VMProtect, and Enigma Protector have been systematically defeated by automated analysis tools, with peer-reviewed techniques demonstrating full devirtualization and control-flow recovery across multiple product versions [Lee et al. 2021; Li et al. 2022; Jin et al. 2025]. Traditional obfuscation strategies (code packing, virtual machine-based execution, and runtime decryption) are systematically dismantled by freely available toolchains: UPX-unpack strips packed binaries in milliseconds; Ghidra and IDA Pro reconstruct control flow graphs from VM bytecode in minutes; and x64dbg with ScyllaHide neutralizes most anti-debug schemes transparently. The net result is that no existing technique reliably prevents a determined analyst equipped with modern tools from reconstructing protected algorithms within a practical time frame.

1.2 The Structural Weakness of Existing Approaches

Despite their differences in implementation, all conventional obfuscation strategies share one architectural property: a recoverable artifact exists somewhere in the binary or in memory at execution time. Packing tools require a decompression stub that must itself remain executable. Virtual machine obfuscation requires an interpreter whose semantics can be recovered by tracing. Encryption-at-rest schemes must decrypt the protected code before it runs, placing either the key or the plaintext in reachable memory.

These are not three independent vulnerabilities. They are three expressions of the same structural problem: the system cannot function without exposing something that can be used to reconstruct the original algorithm. The breadth of attack tooling available today such as: automated unpackers, VM decompilers, memory snapshot utilities, and hardware-assisted tracers are a direct reflection of how many ways this single structural property can be exploited. New tools will continue to emerge, targeting this property through methods that do not yet exist.

Ghost Canvas is designed to eliminate the recovery root itself, not to enumerate and close the specific toolchains that currently exploit it.

1.3 Innovation: Ghost Canvas

We introduce Ghost Canvas, a novel obfuscation architecture that avoids persistent, reconstructible artifacts by assembling executable code only at the point of use. Rather than producing a static image of the protected algorithm in source, binary, or memory, Ghost Canvas drives short-lived assembly through a keystone‑derived permutation.

Concretely, Ghost Canvas (a) transforms compiled machine code into a large corpus of short vessel functions and a permutation specification derived from a keystone, (b) runs a background river that intermixes faux and real vessels against a canvas region, and (c) on direction assembles the final code into the canvas, executes it once, and burns the memory.

1.4 Overview

Ghost Canvas is built on three core principles: the vessel model, the canvas execution model, and the keystone derivation system. The vessel model embeds single‑byte drops inside plausible functions. The canvas execution model reduces the time assembled code is observable in memory. The keystone derivation system derives a deterministic seed (via SHA‑256) which feeds a Fisher‑Yates permutation to produce deterministic assembly orders; together, these mechanisms raise the effort required for successful recovery. Note: the river/canvas mechanism is typically applied selectively to a small set of high‑sensitivity components (for example, a decrypter); implementation specifics are intentionally omitted from this paper to avoid providing operational detail that could aid misuse.

1.5 Contributions

We make the following contributions; each is presented as an independently assessable novelty so readers can quickly understand what is new:

  1. Vessel architecture: Embedding single‑byte drops inside plausibly useful functions so carriers are statistically indistinguishable from ordinary library code while still depositing code bytes onto a writable/executable canvas.
  2. River execution model: A continuous background execution stream that intermixes real vessels and indistinguishable faux vessels to mask the timing and occurrence of directed assembly.
  3. Keystone‑derived assembly ordering: A deterministic pipeline (keystone → SHA‑256 → seed → Fisher‑Yates permutation) that produces reproducible, keystone‑gated assembly orders for JIT construction.
  4. Cost‑compounding security model: An analysis and practical design demonstrating how multiple independent defensive barriers (static analysis resistance, runtime noise, keystone gating, ephemeral execution) multiply adversary cost rather than merely add to it.

1.6 Threat Model

This paper evaluates Ghost Canvas against a clearly scoped set of attacker capabilities. We state these explicitly so that claims about increased analyst cost and reduced structural signal are unambiguous.

In scope

  • User‑mode reverse engineering and static analysis (tools such as IDA Pro, Ghidra).
  • Interactive dynamic analysis and debugger‑assisted tracing at the process level (user‑mode debuggers, breakpoints, Intel PT when used from user context).
  • Memory dumping and process‑level inspection on an uncompromised host.

Partially in scope

  • Kernel‑level instrumentation and kernel debuggers. Ghost Canvas raises attacker cost here, but an adversary with kernel privileges may gain additional observability depending on platform and configuration.

Out of scope

  • Hypervisor‑level introspection and full platform emulation (hypervisor monitors, VM introspection).
  • Physical attacks (chip‑off, microprobing, JTAG, and lab‑grade silicon probing).
  • Microarchitectural and side‑channel attacks that require dedicated hardware or extended measurement.

Note: even when protected code is produced JIT and never exists as a complete static image in process memory, laboratory‑grade physical attacks (chip‑off, microprobing, bus sniffing, EM/power analysis, and fault injection) can capture execution traces or internal state. These high‑cost hardware attacks require specialized equipment and expertise and are treated as out‑of‑scope for this work; evaluating defenses against them (hardware attestation, TEEs, tamper sensors) is left for future work.

2. Conceptual Framework: Drops, Vessels, River, Canvas

The following vocabulary is both metaphor and precise technical description. Readers who understand the model will understand every design decision that follows.

2.1 The Drop

Definition : At the heart of Ghost Canvas lies the drop, a function whose sole purpose is to deposit bytes at a caller-specified offset on an executable memory region called the canvas. This drop is an atomic primitive, meaning it represents the smallest meaningful unit of operation within the system.

Role in the System : The drop ensures that no complete form of the algorithm exists in source, binary, or memory for longer than a single call duration. By being the foundational element, drops prevent adversaries from piecing together the full algorithm through static analysis tools like IDA Pro and Ghidra, as each drop operates independently with no context. This isolation substantially increases the difficulty of reconstructing the entire algorithm from component analysis alone.

Metaphorical Understanding : Imagine a canvas painter who places individual droplets of paint onto a blank surface. Each droplet represents a single byte being deposited by a drop function. Just as these droplets, when combined, form an image, the drops collectively assemble the executable code. However, at any given moment, only one droplet (drop) is active on the canvas, ensuring that the full picture (algorithm) never exists simultaneously.

2.2 The Vessel

Definition : A vessel is a drop in disguise. It wraps the byte deposit inside real-looking computation such as Linear Congruential Generator (LCG) steps, CRC rounds, and hash mixing. This vessel function appears to perform plausible mathematical operations, making it statistically indistinguishable from ordinary library code.

Role in the System : The vessel functions serve two primary purposes: disguise and camouflage. Firstly, they add layers of arithmetic noise that prevent dead-code elimination by modern compilers. Secondly, they bury the actual byte deposit as a side effect within the computation, making it appear as just another mathematical operation to static analysis tools. This duality ensures that each carrier (vessel function) is indistinguishable from ordinary library code, thereby obfuscating the algorithm's structure.

Metaphorical Understanding : Think of vessels as sea containers carrying cargo. Each container appears normal on the surface but contains a secret payload hidden within. The vessel functions perform regular tasks like LCG steps and CRC rounds, which are essential for many applications, while also subtly depositing bytes onto the canvas. This dual nature ensures that the true purpose of each vessel remains hidden from static analysis.

2.3 The River

Definition : The river is a background thread that continuously calls both real vessels and faux-vessel functions against the same memory region, called the canvas. Faux vessels are structurally identical to real vessels but deposit incorrect bytes at positions real vessels later overwrite, creating indistinguishable noise.

Role in the System : The river provides an unbroken stream of writes to the canvas, concealing the precise moment of directed assembly. By continuously calling vessels and faux-vessels in random order, the river transforms a discrete event (code assembly) into a continuous process, making it substantially harder for external observers to detect the exact moment when the algorithm is being assembled.

Metaphorical Understanding : Imagine a flowing river made up of two components: real water droplets and indistinguishable mud particles. The river continuously moves, mixing these components together so that no one can identify where the true water droplets (real vessels) are coming from. Similarly, the river thread in Ghost Canvas keeps a constant flow of vessel and faux-vessel calls, ensuring that the assembly process remains hidden.

2.4 Direction

Definition : Direction marks the moment when the river stops being random and becomes intentional. This transition is driven by the keystone, which transforms the river into an image where drops are correctly ordered to form coherent executable code.

Role in the System : The keystone-derived permutation orders the drops correctly, ensuring that they land at their designated positions on the canvas. Without the correct keystone, the river produces only noise, structurally identical to the directed flow. Direction is brief and externally silent; it occurs seamlessly within the ongoing stream of writes from the river.

Metaphorical Understanding : Picture a compass in a ship navigating through stormy seas. At the moment when the wind aligns with the compass direction (direction), the ship steers towards its destination, ensuring that it reaches its intended position. Similarly, at the moment of direction in Ghost Canvas, the keystone guides the drops to their correct positions, forming the executable code.

2.5 The Canvas

Definition : The canvas is a writable/executable memory region that accumulates byte deposits during the river phase. After direction, it is sealed, executed once, and immediately destroyed. This process ensures that the complete algorithm exists only briefly in memory.

Role in the System : The canvas execution model eliminates any window of opportunity for analysis by ensuring that the assembled machine code exists for a minimal duration, typically microseconds. By burning the canvas after a single use (overwriting it with 0xCC and freeing the memory), Ghost Canvas prevents adversaries from capturing the complete algorithm in memory.

Metaphorical Understanding : Imagine an artist sketching on a piece of paper, which is then immediately torn and discarded after being displayed for just a moment. The canvas in Ghost Canvas serves this purpose, accumulating byte deposits during the river phase but ensuring that the final drawing (executable code) exists only briefly before being destroyed.

2.6 Script for Generating Drops and Vessels

2.6.1 Script Overview

The creation of drops and their integration into the system is a critical step in implementing Ghost Canvas. To facilitate this process we developed a program that automates the generation of vessel functions based on input machine code. This tool allows us to transform any arbitrary executable into a dynamic assembly process powered by our "river."

The script performs several key functions:

  • Input Processing : Takes raw machine code bytes and converts them into a format suitable for integration into the Ghost Canvas system.
  • Drop Generation : Creates individual drop functions, each responsible for depositing bytes at a specified offset on the canvas.
  • Vessel Creation : Wraps each drop function inside a vessel that performs plausible-looking computations, making it statistically indistinguishable from ordinary library code.
  • Permutation Derivation : Utilizes the keystone to derive a permutation that orders the drops correctly during the direction phase.

2.6.2 Ethical Considerations and Security Implications

The primary ethical concern around publishing Ghost Canvas is not that the repository or toolchain will be casually repurposed for wrongdoing, but that the knowledge of this technique lowers the barrier to building similar systems. In other words "capability diffusion". As in the fact that researchers and practitioners now know this design is practical is the real risk vector.

Framing the response this way focuses attention on governance and risk management rather than on policing individual tool access. Practical steps organizations and researchers can take include:

  • Responsible disclosure & documentation: describe limitations, threat models, and safe deployment practices alongside any implementation details.
  • Risk-based code review: prioritize review and testing for components that affect runtime assembly, key handling, and platform-specific behavior.
  • Operational controls: maintain appropriate access controls, audit logs, and monitoring for build/runtime systems that generate or execute assembled code.
  • Threat modeling & education: surface the specific attacker capabilities that the design changes, and train teams on what the mitigations actually achieve.

This reframing keeps the focus on realistic, proportionate safeguards and on informing defenders about the existence and implications of this technique, rather than implying that possession of the tool alone creates an imminent misuse risk.

2.7 The Compiler

The compilation process in Ghost Canvas is essential for transforming raw machine code into the obfuscated format that leverages drops, vessels, and the river model. Here’s a high-level overview of the key steps involved:

2.7.1 Input Requirements

  • Raw Machine Code Bytes : The compiler takes the raw machine code bytes extracted from a release build of the target executable.
  • Keystone String : A passphrase that seeds the permutation derivation process.
  • Faux Count : The number of faux vessels to generate, which adds noise and complicates analysis.

3. Analysis Resistance and Anti-Debug Protection

3.1 Static Analysis Resistance

Static analysis tools like IDA Pro and Ghidra are designed to dissect binary executables in search of recognizable patterns, structures, and code artifacts that can reveal the underlying algorithm or functionality. Ghost Canvas is engineered to present a substantially more opaque surface to these tools, reducing the structural information available and making meaningful recovery significantly more difficult for the threat models considered here.

3.1.1 Why IDA Pro / Ghidra See Only Noise:

When analysts employ static analysis on a Ghost Canvas-obfuscated executable, they encounter a landscape that appears as a collection of numerous short, independent functions. Each function is approximately 10 instructions long, and high-level patterns or straightforward connections are intentionally minimized. This design reduces the structural signals that static analysis normally leverages to reconstruct algorithms.

3.1.2 No Call Graph, No Clues:

One of the fundamental techniques static analysis relies on is the construction of a call graph to trace the flow of execution. In Ghost Canvas, this endeavor is greatly complicated. The vessel functions, which are responsible for depositing bytes onto the canvas, do not form any cohesive call graph that links them to a recognizable algorithm. Each vessel function operates independently and in random order, making it considerably harder to deduce their purpose or sequence.

3.1.3 No String Literals, No Purpose:

Static analysis often relies on string literals within the binary to infer the functionality of the code. However, Ghost Canvas eliminates this avenue by ensuring that no meaningful strings are present. Instead, all text is embedded as integer immediate values and rewritten in a manner that avoids the .rodata section. This obfuscation technique renders any attempt to extract semantic meaning from string literals futile.

3.1.4 No Crypto Primitives, No Easy Targets:

In some traditional obfuscation methods, reverse engineers might look for cryptographic primitives or decryption routines as potential entry points. However, Ghost Canvas does not employ any such mechanisms. The assembled code is native x86-64 machine code, with no need for an interpreter or encryption key. This absence of recognizable crypto primitives further complicates the analyst's efforts.

3.1.5 Only a WRITERS Dispatch Table Remains:

The only visible artifact left after Ghost Canvas processing is the WRITERS dispatch table. A function pointer array that maps vessel indices to their corresponding writer functions. Importantly, this dispatch table is not unique to Ghost Canvas; it is a common feature in any callback-heavy codebase. This similarity ensures that the presence of the WRITERS array does not provide any clues about the obfuscation method being used.

3.1.6 Static Analysis Resistance Conclusion:

Ghost Canvas raises the practical cost of static analysis by ensuring that no complete form of the algorithm exists in source, binary, or memory for longer than a single call duration. The deliberate removal or obfuscation of call-graph signals, string literals, and recognizable primitives, combined with a generic dispatch table, significantly reduces the ability of conventional static-analysis toolchains to recover execution ordering or high-level structure without additional information (for example, the keystone or a full dynamic trace). This higher operational cost for the analyst is the intended security property of the system.

3.2 Dynamic Analysis Resistance

Dynamic analysis tools aim to trace and monitor the behavior of a running program in real-time to uncover its inner workings. Ghost Canvas is designed with multiple layers of defense to thwart these efforts, ensuring that the protected algorithm remains hidden from dynamic reverse engineering.

3.2.1 Short-lived Canvas Page:

The canvas page, which serves as the temporary memory region for assembling the executable code, exists only for the duration of a single function call, typically ranging from microseconds to milliseconds. This extremely brief window of existence makes it difficult for a debugger to capture and inspect the canvas content before it is destroyed.

3.2.2 Timing Attacks Mitigation:

Even if an analyst sets a breakpoint on the base address of the canvas page, the rapid execution of the function means that the page might be freed by the time the debugger can respond. This introduces a significant challenge in attempting to pause the program at the exact moment the assembly occurs.

3.2.3 Page Guard Traps:

While page guard traps can detect the allocation of an RWX (Read-Write-Execute) memory page, they provide no insight into the content of the page before it is burned. The burning process, which overwrites the canvas with a specific pattern (0xCC), ensures that even if the page content were captured, it would be meaningless to the analyst.

3.2.4 Three-phase River Structure:

The river thread in Ghost Canvas operates through three distinct phases: Free Flow, Direction, and another Free Flow. This structure produces a continuous, flat write-frequency signal across all phases, effectively concealing any detectable assembly moment. An observer watching memory write frequency sees no discernible pattern that would indicate when the actual directed assembly is taking place.

3.2.5 False Positive Vessel Call Patterns:

The river thread continuously calls both real vessels and faux-vessel functions in random order against the same canvas region. This results in a high volume of vessel call patterns, which can overwhelm trace analysis tools. The sheer number of function calls makes it difficult for an analyst to distinguish between legitimate assembly activities and noise.

3.2.6 Dynamic Analysis Resistance Conclusion:

Ghost Canvas effectively resists dynamic analysis by ensuring that the protected algorithm never exists in a form that can be easily captured or inspected during execution. The short-lived canvas page, combined with timing attacks mitigation, page guard trap limitations, and the river’s flat write-frequency signal, create a robust defense against real-time reverse engineering. These mechanisms collectively ensure that Ghost Canvas remains resilient to dynamic analysis techniques, thereby protecting software intellectual property from unauthorized access.

3.3 Anti-Debug Layer

The anti-debug layer in Ghost Canvas is a critical component designed to detect and thwart debugging attempts, ensuring that the protected algorithm remains hidden from reverse engineers. This layer is implemented in the platform::debugger_detected() function, which is executed twice per invocation of the system. Once before and one after the compose() function. By employing multiple sophisticated checks, Ghost Canvas aims to provide a robust defense against various types of debugging techniques.

3.3.1 Four Checks Executed in Order of Cost:

IsDebuggerPresent:

  • Functionality : This check reads the Process Environment Block (PEB) user-mode flag to determine if a debugger is present.
  • Advantages : It is fast and simple, making it an initial layer of defense.
  • Limitations : This flag can be patched with a single byte write by an advanced attacker.

NtQueryInformationProcess:

  • Functionality : This kernel-level query checks if the process is attached to a debugger.
  • Advantages : It survives patches to IsDebuggerPresent, providing a more reliable detection mechanism.
  • Limitations : While robust, it can still be bypassed by sophisticated attackers who modify kernel-level data structures.

Timing:

  • Functionality : The execution time of the compose() function is measured using QueryPerformanceCounter. The system checks if the elapsed time exceeds a threshold (10 ms) when vessels are processed.
  • Advantages : A stepping debugger or call-level hook inflates the elapsed time, making this check effective in identifying debugging attempts.
  • Limitations : It assumes that normal execution will complete within microseconds, which might not hold true under all conditions.

Hardware Breakpoints :

  • Functionality : This check reads the debug registers of the current thread to determine if any are set in the canvas region.
  • Advantages : It detects hardware breakpoints, which are often used by analysts to inspect memory content without modifying the process state.
  • Limitations : This check is only effective after the canvas has been allocated, as the address must be live at that point.

3.3.2 Pre-compose and Post-compose Checks:

  • Pre-compose Check : Executes checks 1, 2, and 4. Timing is skipped because the canvas is not yet assembled, making the hardware breakpoint check valid.
  • Post-compose Check : Runs all four checks with real timing values to ensure comprehensive detection after the canvas has been populated.

3.3.3 Response to Detection:

If any of the checks indicate the presence of a debugger, the burn function is invoked. This function overwrites every byte in the canvas with 0xCC (an invalid instruction), effectively destroying the protected algorithm before returning an empty string to the caller. This ensures that even if an attacker captures the memory content, it will be meaningless.

3.3.4 Limitations and Future Considerations:

  • Kernel-mode Debuggers : Tools like WinDbg KD, VirtualKD, VMware introspection, and Hyper-V debugging operate below the user-mode API surface, bypassing all four checks. While these tools represent a significant challenge, they are not typical for most threat actors.
  • Arms Race Nature : The anti-debug layer is an ongoing arms race between defenders (such as Ghost Canvas) and attackers. The goal is to achieve practical impossibility for the overwhelming majority of threat actors, rather than theoretical unbreakability.

3.3.5 Anti-Debug Layer Conclusion:

In summary, the anti-debug layer in Ghost Canvas provides a comprehensive defense against various types of debugging attempts. By employing multiple sophisticated checks, including user-mode and kernel-level detection, timing analysis, and hardware breakpoint inspection, Ghost Canvas ensures that the protected algorithm remains hidden from reverse engineers. While some advanced tools can still bypass these defenses, Ghost Canvas significantly raises the barrier to unauthorized access, making it an effective tool for protecting software intellectual property.

4. What an Adversary Actually Gets

When faced with the challenge of breaching the defenses provided by Ghost Canvas, adversaries encounter two independent layers of protection: source obfuscation and Ghost Canvas itself. Each layer presents unique challenges that must be overcome separately.

4.1 Layer 1: Source Obfuscation

The first line of defense involves the obfuscation of the application logic. This is typically achieved through a separate system not detailed in this paper but designed to convert the original source code into an unreadable form. Key aspects of this layer include:

  • Pure cryptographic entropy : Cryptographic hash chains transform source code into uniform token streams (_xxxxxxxx), which substantially reduce structural signal available to static analysis. The obfuscated file contains no readable syntax, identifiers, or structural patterns.
  • Non-recoverable Source Code : Reconstructing the original source code from the obfuscated artifact is expected to be highly challenging without access to additional contextual information (for example, the keystone or original build artifacts).

4.1.1 AI Analysis Result: 11/14/2025 @ 19:51

ChatGPT-4's key findings:

  • Not recognizable as Python code : "This is not syntactically valid Python, nor is it a recognizable output of a known Python obfuscation system"
  • Pure cryptographic entropy : "Entropy indicates randomness typical of encryption output (AES, ChaCha20), compressed binary, or PRNG noise"
  • No structural patterns : "No recognizable patterns, no recognizable structure of compiled Python opcodes"
  • Complete analysis failure : "There is no way to recover code or functionality from this alone"

4.2 Layer 2: Ghost Canvas

The second line of defense employs advanced dynamic obfuscation techniques to prevent reverse engineering at runtime. Key components and their implications are:

  • Compiled Binary with Vessel Functions : The executable contains a large number of vessel functions, approximately ( N + FAUX_N ), each consisting of roughly 10 instructions. These functions appear as statistically indistinguishable computations, making it difficult for static analysis tools to identify their purpose. These values change each time the compiler runs.
  • Function Pointer Dispatch Table (WRITERS) : A common feature in many codebases, the dispatch table does not provide any specific clues about the obfuscation method being used. This ensures that an adversary cannot infer the presence or nature of Ghost Canvas from the binary's structure alone.
  • Memory Allocation Evidence : The use of VirtualAlloc, VirtualProtect, and VirtualFree is a common practice in many applications, making it more difficult for adversaries to reliably identify these calls as unique to Ghost Canvas. This blurs the line between legitimate memory management operations and those employed by the obfuscation system.
  • Lack of Complete Algorithm : Unlike traditional obfuscation methods that store the algorithm or its components in memory, Ghost Canvas minimizes the temporal co‑presence of assembled machine code. Each drop function operates independently, making it substantially more difficult to reconstruct the entire algorithm through static or dynamic analysis alone.
  • Non-existent Key : The keystone used for deriving the permutation is not stored within the binary and cannot be derived from the vessel byte values alone without solving the permutation itself. This introduces a significant barrier as the key must be obtained before any meaningful progress can be made.
  • Immediate Burning of Canvas : After each execution cycle, the canvas (a temporary memory region where the algorithm is assembled) is overwritten with 0xCC (an invalid instruction) and immediately freed. This ensures that there is no window of opportunity to capture or analyze the assembled machine code.

4.3 The Adversary's Position

This section does not enumerate every possible attack path against Ghost Canvas. The attack surface of any sufficiently complex system exceeds what any paper can fully describe, and the security field's history is largely a record of novel techniques arriving after defenders assumed completeness. Presenting a closed list of attack vectors, and their specific mitigations, would be precisely the mistake this paper argues against elsewhere.

What can be said is structural. An adversary who reaches Ghost Canvas after defeating source-layer obfuscation encounters a binary with no complete algorithm, no recoverable key, and a canvas that self-destructs after a single use. The hardest-known cryptographic paths involve brute-forcing a Fisher-Yates permutation over thousands of elements or breaking the preimage resistance of a 256-bit ARX hash, both computationally intractable under current and foreseeable models. Other attack paths exist, known and unknown. Ghost Canvas's architecture responds to this uncertainty by design: each defensive layer is structurally independent, so no single breakthrough yields the algorithm. The cost of a successful attack is not the cost of one insight, it is the cumulative cost of independently defeating barriers whose complete enumeration is, by design, left open.

5. Implementation

5.1 Target Platform

At the time of writing, Ghost Canvas is designed with the Windows x64 platform in mind, leveraging its capabilities to ensure robust execution. The use of SSE2 instructions allows for efficient auto-vectorization by LLVM, enhancing performance without compromising security. Future developments aim to extend support to multiple operating systems.

5.2 The ghost_hash (SHA-256)

Historically, ghost_hash was implemented as a custom ARX‑based mixer. After review we migrated to a SHA‑256‑based derivation to rely on a widely‑reviewed primitive and to reduce the risk of subtle weaknesses in bespoke constructions. The obfuscator and runtime now compute ghost_hash as the canonical SHA‑256 digest of the domain‑separated input (the same context prefixes such as GHOST_MAP_KEY:, KEYSTONE, and CHAR: are preserved).

Implementation notes (for reproducibility): ghost_hash is defined as SHA256(domain_prefix || input) with the published domain prefixes. For key derivation and entropy handling we use standard constructions (HKDF‑SHA256) rather than ad‑hoc squeezing or custom PRF wrappers. Both the Python reference implementation and the Rust runtime have been updated to compute SHA‑256 identically for the published test vectors.

Both the Python reference implementation and the Rust canvas implementation have been verified to produce identical outputs for the paper's test vectors. Formal cryptanalysis of this mixer is out of scope for this work.

Prototype entropy device: practical note

The reference implementation used in our experiments incorporates a prototype physical entropy source (a separate hardware device that measures a non‑deterministic physical process) to seed keystone derivation in some builds. At the time of writing detailed, audited entropy‑estimation results (min‑entropy, NIST STS/Dieharder summaries, SP800‑90B assessments) are not yet published. We plan to publish a dedicated TRNG validation report once formal testing is complete. To avoid overclaiming, the paper treats the device as a high‑quality entropy input only: raw samples are passed through a standard key‑derivation function (HKDF‑SHA256 in our reference build) and protected inside an HSM before being used to derive runtime permutation seeds.

5.3 Drop and Vessel Generation

The keystone function, a critical component of Ghost Canvas, serves to initialize the permutation process. It is designed to be compact, fitting within approximately 1944 bytes of x86-64 machine code. This compactness ensures that the overhead introduced by the keystone function itself is minimal.

Vessels are generated based on the keystone and the input machine code. Each vessel function is crafted to appear like ordinary library code, performing plausible-looking computations while discreetly depositing a single byte onto the canvas at a specified offset. To maintain this camouflage, each vessel function is embedded with arithmetic noise that prevents modern compilers from eliminating dead code.

Faux vessels are structurally identical to real vessels but deposit incorrect bytes at positions that real vessels later overwrite. This design introduces indistinguishable noise into the system, making it difficult for static and dynamic analysis tools to discern between legitimate writes and decoy writes.

The overall implementation results in approximately 1964 vessel functions being generated, contributing to a comprehensive yet subtle obfuscation strategy. The resultant Rust codebase spans around 11,300 lines, reflecting the complexity and precision required for Ghost Canvas's dynamic assembly process.

These numbers can be adjusted per compile.

5.4 Canvas Compatibility

Ensuring canvas compatibility is crucial for maintaining the integrity of the Ghost Canvas system. Initially, the keystone function utilized heap-allocated data structures like Vec<Vec<u64>> and String, which introduced potential vulnerabilities during execution. To address this, the implementation has been refactored to use stack-based buffers for hash inputs and arithmetic hex encoding, eliminating the need for heap allocations.

Additionally, all helper functions are inlined (#[inline(always)]), ensuring that there are no extraneous CALL instructions in the compiled output. This approach further reduces the attack surface by minimizing potential entry points for adversaries attempting to trace or manipulate execution flows.

The "GHOST_KEYSTONE:" prefix is rewritten as integer immediates, avoiding the .rodata section altogether. This change ensures that strings embedded within the code cannot be easily extracted or utilized in static analysis efforts.

5.5 Performance Considerations

Ghost Canvas is intentionally aggressive: it trades runtime cost for a materially higher bar against static and dynamic analysis. That tradeoff is the product, and the point of the design. We recommend and support deploying Ghost Canvas across an entire codebase when source-code protection is the priority; the system is meant to be used broadly, not only on isolated functions.

Measured figures on a development/debug workstation (representative, not definitive) show the following:

  • Baseline: trivial host-language add(a,b) ≈ 0.0476 µs per call (microbenchmark).
  • Simulated compose+execute: memory-write + minimal seal ≈ 80.8 µs per compose.
  • Full obfuscated lifecycle: compose + OS protect/exec transition + burn ≈ 35.78 ms per invocation.

What this means in practice:

  • Expect measurable latency when protecting frequently-called code paths; the full lifecycle is heavier than an ordinary function call because it includes OS transitions and native-code setup.
  • That said, if your deployment objective is comprehensive source protection across the product, using Ghost Canvas pervasively is a valid, honest choice, you get a significantly higher protection level in exchange for runtime cost.

Practical guidance to make that tradeoff workable:

  • Build for release and benchmark on target hardware: release builds and faster CPUs materially reduce the observed numbers.
  • Amortize where possible: when policy allows, compose once and reuse assembled code across multiple logical operations rather than composing on every single call.
  • Parallelize and pipeline: perform composition on worker threads or during low-load windows to hide latency from interactive paths.
  • Profile to prioritize: if absolute latency is critical in small inner loops, consider hybrid strategies (e.g., keep extremely hot micro-kernels native, protect the rest).

Framing for decision-makers: Ghost Canvas lets you choose protection level as a deliberate product decision. If the primary goal is to protect IP and prevent algorithm recovery, the performance cost is an upfront, quantifiable trade, one we believe is often worth making. Provide customers with benchmark data for their target platforms and recommendations for amortization so they can decide the deployment pattern that fits their needs.

6. The Honest Admission: On the Fundamental Limits of Software Protection

The security industry shares an open secret that almost no one states plainly: no software protection scheme is unbreakable. Code must execute on real hardware. Real hardware can be observed, at the instruction level, at the memory bus level, at the silicon level, by someone who controls it. This means that any executable, given a sufficiently motivated adversary with physical access and unlimited time, can in principle be fully analyzed. Every lock, no matter how sophisticated, is a negotiation with time and motivation, not an impassable barrier.

Every commercial protection product, Themida, VMProtect, Enigma Protector, and every academic proposal before this one, operates on the same implicit contract: we are not stopping the attack, we are making it expensive. The industry markets these products as locks. They are speed bumps. The distinction matters enormously, and the field's reluctance to state it clearly has produced decades of overclaiming, inflated expectations, and products that fail the moment a sufficiently determined analyst sits down with the right tools.

Ghost Canvas is built on a different foundation: honesty about what software protection actually is.

The goal of Ghost Canvas is not theoretical unbreakability. The goal is practical impossibility for the realistic threat model. Most adversaries are not nation-state actors with months to spend, custom silicon, and unrestricted hardware access. Most adversaries are opportunistic, they will move on when the cost of attack exceeds the value of what they are attacking. Ghost Canvas is designed to ensure that this cost threshold is prohibitively high for the overwhelming majority of realistic threat actors.

For the ceiling, a hypervisor-level monitor, a hardware logic analyzer, a kernel debugger operating below the user-mode API surface; there is no software answer. These tools, in the hands of a patient and resourced adversary, will eventually capture what Ghost Canvas protects. This paper does not claim otherwise. What Ghost Canvas claims is narrower and more defensible: that within the realistic threat model, skilled reverse engineers using industry-standard toolchains, the architecture described here raises the cost of attack to a point that is, in practice, prohibitive.

Acknowledging this ceiling is not a weakness. It is the precondition for an honest conversation the field has been avoiding. Software protection is not a solved problem. Claiming otherwise does not protect anyone, it only delays the reckoning. If the industry were forced to confront the fact that no lock is truly unbreakable, it would be compelled to search for genuinely new approaches: hardware-bound attestation, trusted execution environments, cryptographic protocol designs that do not require the secret to be present at execution time at all. Those conversations cannot begin until the field is willing to admit what it already knows.

Ghost Canvas is one step in that direction: a design that is honest about its limits, rigorous within them, and explicit about what it does and does not claim.

References

Jin, H., Lee, J., Kim, T., Sung, M. Y., & Lee, D. H. (2025). asmMBA: Robust virtualization obfuscation with assembly-based mixed boolean-arithmetic. Proceedings of the 40th ACM/SIGAPP Symposium on Applied Computing. https://doi.org/10.1145/3672608.3707862

Lee, Y. B., Suk, J. H., & Lee, D. H. (2021). Bypassing anti-analysis of commercial protector methods using DBI tools. IEEE Access, 9, 7655–7673. https://doi.org/10.1109/ACCESS.2021.3049198

Li, S., Jia, C., Qiu, P., Chen, Q., Ming, J., & Gao, D. (2022). Chosen-instruction attack against commercial code virtualization obfuscators. Proceedings of the 29th ACM Conference on Computer and Communications Security (CCS). https://doi.org/10.1145/3548606.3559386

Manikyam, R., McDonald, J. T., & Mahoney, W. R. (2016). Comparing the effectiveness of commercial obfuscators against MATE attacks. Proceedings of the ACM Workshop on Software PROtection (SPRO). https://doi.org/10.1145/3015135.3015143

Sudhir, A., Basque, Z. L., Gibbs, W., & Bajaj, A. P. (2026). Pushan: Trace-free deobfuscation of virtualization-obfuscated binaries. arXiv preprint arXiv:2603.18355. https://arxiv.org/abs/2603.18355