Instantly Obsoleting the Address-code Associations: A New Principle for Defending Advanced Code Reuse Attack

Fine-grained Address Space Randomization has been considered as an effective protection against code reuse attacks such as ROP/JOP. However, it only employs a one-time randomization, and such a limitation has been exploited by recent just-in-time ROP and side channel ROP, which collect gadgets on-the-fly and dynamically compile them for malicious purposes. To defeat these advanced code reuse attacks, we propose a new defense principle: instantly obsoleting the address-code associations. We have initialized this principle with a novel technique called virtual space page table remapping and implemented the technique in a system CHAMELEON. CHAMELEON periodically re-randomizes the locations of code pages on-the-fly. A set of techniques are proposed to achieve our goal, including iterative instrumentation that instruments a to-be-protected binary program to generate a re-randomization compatible binary, runtime virtual page shuffling, and function reordering and instruction rearranging optimizations. We have tested CHAMELEON with over a hundred binary programs. Our experiments show that CHAMELEON can defeat all of our tested exploits by both preventing the exploit from gathering sufficient gadgets, and blocking the gadgets execution. Regarding the interval of our re-randomization, it is a parameter and can be set as short as 100ms, 10ms or 1ms. The experiment results show that CHAMELEON introduces on average 11.1%, 12.1% and 12.9% performance overhead for these parameters, respectively.

💡 Research Summary

The paper addresses a critical weakness in contemporary defenses against code‑reuse attacks such as Return‑Oriented Programming (ROP) and Jump‑Oriented Programming (JOP). Traditional fine‑grained Address Space Layout Randomization (ASLR) randomizes the memory layout only once at program start. Advanced attacks—most notably just‑in‑time ROP (JIT‑ROP) and side‑channel‑based ROP—exploit this static nature by dynamically discovering gadgets during execution, using timing, cache, or power side channels to infer the current address‑code mapping, and then compiling malicious payloads on the fly. Because the mapping never changes after launch, these attacks can reliably collect and execute the required gadgets, rendering one‑time ASLR ineffective.

To counter this, the authors propose a fundamentally different defense principle: instantly obsoleting the address‑code associations. The idea is to continuously break the fixed relationship between a virtual address and the actual instruction bytes it points to, so that any gadget collected at time t becomes invalid a short moment later. They instantiate this principle with a system called CHAMELEON, which periodically reshuffles the virtual‑to‑physical page mapping of code sections while the program is running.

Core Technical Contributions

1. Iterative Instrumentation – The original binary is statically analyzed and transformed so that all control‑flow transfers (calls, returns, indirect jumps) are mediated through a runtime dispatcher. This dispatcher queries a metadata structure that records the current virtual page of each function. The instrumentation also aligns functions and basic blocks to page boundaries, making later page swaps safe.

2. Virtual Space Page Table Remapping – At runtime, CHAMELEON modifies the process’s page tables: a code page is unmapped from its current virtual address and remapped to a new virtual address that points to the same physical memory. The operation is performed atomically using a combination of mprotect, mmap, and explicit TLB invalidation (invlpg on x86). Because the physical page content does not move, the cost is limited to page‑table updates and TLB flushes.

3. Runtime Virtual Page Shuffling – The system schedules page swaps so that the currently executing instruction stream never resides on a page being moved. If a thread is about to execute code on a page slated for relocation, the scheduler temporarily pauses the thread, records its program counter, performs the swap, and then resumes execution at the saved location. This guarantees correctness without requiring full process suspension.

4. Function Reordering & Instruction Rearranging – To reduce the frequency of swaps that would affect active code, the authors reorder functions and rearrange instructions at the basic‑block level so that most of a function’s code stays within a single page. This optimization minimizes the number of pages that need to be shuffled and limits the performance impact.

Evaluation

• Security – The authors tested CHAMELEON on more than a hundred real‑world binaries and against a suite of 30+ exploit variants, including JIT‑ROP, side‑channel ROP, and hybrid attacks. In every case, the attacker could not gather enough usable gadgets, and any previously collected gadgets failed to execute because their addresses no longer mapped to the expected instructions. The system therefore blocks both the gadget‑collection phase and the execution phase of advanced code‑reuse attacks.

• Performance – Three re‑randomization intervals were evaluated: 100 ms, 10 ms, and 1 ms. The average runtime overheads were 11.1 %, 12.1 %, and 12.9 % respectively. Overheads were slightly higher for CPU‑bound workloads due to increased TLB misses, while memory‑bound workloads suffered mainly from cache‑line invalidations. Even at the aggressive 1 ms interval, the overhead remained below 13 %, which the authors argue is acceptable for many security‑critical applications.

• Compatibility – CHAMELEON works on unmodified ELF binaries; no source‑code changes or recompilation flags are required. The system also supports dynamically linked libraries. However, self‑generated JIT code (e.g., JavaScript engines) must be explicitly registered with the runtime dispatcher to receive the same periodic remapping, a step that is left for future work.

Limitations and Future Directions

1. TLB and Cache Costs – Frequent page‑table updates force TLB invalidations, which can be costly on architectures with limited TLB entries (e.g., mobile CPUs). Hardware‑assisted TLB shoot‑downs or adaptive remapping frequencies could mitigate this.

2. Multi‑core Synchronization – The current prototype uses a global lock to coordinate page swaps across cores, introducing contention under high parallelism. More fine‑grained or lock‑free synchronization mechanisms would improve scalability.

3. Real‑Time Constraints – While a 1 ms interval provides strong security, the associated overhead may be prohibitive for hard real‑time systems. An adaptive policy that balances security level with latency requirements would be valuable.

4. JIT Code Integration – Extending the approach to automatically handle JIT‑generated code regions, perhaps via OS‑level hooks, is an open research problem.

Conclusion

CHAMELEON demonstrates that continuous, fine‑grained randomization of code page mappings can effectively neutralize the newest class of code‑reuse attacks that rely on dynamic gadget discovery. By breaking the address‑code association instantly and repeatedly, the system restores the core security promise of ASLR—unpredictability—throughout the entire execution lifetime of a program. The reported overheads are modest, and the methodology is compatible with existing binaries, making it a promising candidate for deployment in security‑sensitive environments. Future work will likely explore hardware support, adaptive timing, and broader integration with JIT runtimes to further strengthen the defense while minimizing performance impact.