Introduction

In the world of technology and software engineering every application begins as human-readable source code. Before a computer can execute that software the code is compiled into machine instructions. During this compilation original variable names, developer comments and high-level architectural boundaries are removed. What remains is a raw binary file that runs efficiently on hardware but is difficult for a person to understand.

Reverse engineering is the discipline of analyzing these compiled binaries to reconstruct how a program was designed and how it works. It is not about copying code; it is about understanding behavior, protocols and internal structure.

Throughout software history reverse engineering has driven major technological breakthroughs and practical engineering solutions:

  • In 1984 Phoenix Technologies reverse engineered the IBM PC BIOS without copying proprietary code, building compatible firmware that allowed manufacturers to produce affordable personal computers worldwide.
  • In 1992 Andrew Tridgell analyzed the network file sharing protocols of Microsoft to create Samba, enabling Linux and Unix systems to communicate with Windows networks seamlessly.
  • In 2019 the National Security Agency released Ghidra as a free open source reverse engineering framework, allowing cybersecurity researchers and software teams to audit compiled binaries for security flaws.
  • Today major technology companies such as Google, Apple and Microsoft maintain dedicated security research teams who reverse engineer software and firmware to uncover vulnerabilities before attackers can exploit them.

Historically reverse engineering was slow and required years of specialized practice reading assembly language. An analyst had to trace thousands of functions manually.

To explore how modern artificial intelligence transforms this process, I used REA (Reverse Engineer Anything) with Antigravity and the Argon 4 model to analyze real-world compiled software such as VLC media player. In this post I will explain how REA works and share the complete reverse engineering experiment step by step.

How REA Works

Before diving into how REA operates, it is worth clarifying what problem it actually solves. If you already have access to an application’s original source code, you do not need a reverse engineering framework like REA. Standard code editors and AI agents can already read, search and reason over plaintext repositories directly.

REA is built specifically for compiled binaries: executables, shared libraries, disk images and application packages where original source code is entirely absent. In a compiled binary, variable names, developer comments and high-level abstractions have been stripped away into raw machine instructions. REA helps decompile and reconstruct these opaque binaries by driving headless decompilers such as Ghidra alongside binary inspection utilities through the Model Context Protocol (MCP).

In short: we are not inspecting readable source code; we are investigating compiled “black-box” binaries where every architectural fact must be forensically extracted from raw bytes.

REA (Reverse Engineer Anything) is an open source project available on GitHub under the name morluto/rea. Rather than replacing trusted analysis tools, REA connects them to an AI agent over MCP. The AI agent coordinates the investigation, runs the tools on your local system and explains the findings with verifiable evidence.

To understand how this operates, we should first examine the two sides that REA brings together.

The existing tools

For many years analysts have relied on a standard set of tools:

  • Disassemblers and decompilers: Tools like Ghidra, IDA Pro and Hopper translate binary machine code into readable assembly instructions and structured high-level logic.
  • Binary and symbol inspectors: Utilities such as objdump, nm and strings examine file headers, inspect symbol tables and extract readable text like error messages or web addresses.
  • Dynamic tracers and debuggers: Frameworks such as Frida, GDB and LLDB observe program execution in real time, inspect memory and trace active function calls.
  • Network and protocol analyzers: Packet capture tools such as Wireshark inspect network communications to understand data exchange formats and protocols.
  • Package and resource extractors: Utilities such as apktool and container inspectors unpack application bundles, asset catalogs and embedded interface files safely.

These tools are accurate and dependable. However they do not understand meaning. They show everything but they do not tell us what is important. A human has to decide where to look next and what each part is for.

The gap with AI alone

Now consider the other side. An AI agent is very good at reading code and explaining its purpose. So one might think we can simply give a compiled file to the agent and ask questions.

This does not work well for two reasons. First a real program is very large and the agent can only read a limited amount at one time. Second without proper evidence the agent may give an answer that sounds correct but is actually a guess. In reverse engineering a wrong guess is worse than no answer.

How REA bridges the gap

REA sits between the AI agent and the existing tools. It uses a standard called the Model Context Protocol, commonly known as MCP. This standard gives AI agents a common way to use outside tools. You can think of it as an agreed language between the agent and the tool.

With REA in place the work happens in a loop. In AI agent terms this loop is called tool calling. The agent does not run the analysis itself. It requests a tool to run and then reads the result.

  1. You give the AI agent a question in plain words about a program on your computer.
  2. The agent picks a suitable tool offered by REA and sends a small and specific request. This is the tool call.
  3. REA runs the matching program on your machine. This could be Ghidra for decompiling the code or a utility for listing the readable text.
  4. The result goes back to the agent as real facts from the file.
  5. The agent reads the result and decides on the next tool call.
  6. After several rounds the agent gives you an explanation along with the evidence it collected.

The diagram below shows the main parts of the system and how they talk to each other.

flowchart LR
    user(["Developer"])
    agent["AI Agent<br/><small>Plans and Coordinates</small>"]
    rea["REA Server<br/><small>Local MCP Bridge</small>"]
    tools["Analysis Tools<br/><small>Ghidra and System Utilities</small>"]
    target[("Target Program<br/><small>Compiled binary or app</small>")]

    user <-->|"1. Prompt and Answers"| agent
    agent <-->|"2. Tool Calls via MCP"| rea
    rea <-->|"3. Runs Commands"| tools
    tools <-->|"4. Inspects Code"| target

Each step represents a clear two-way exchange:

  1. You give the AI agent a request and it explains the findings back to you.
  2. The agent sends tool requests over MCP and REA returns structured facts.
  3. REA runs the matching tool on your computer and collects the output.
  4. The tool reads and analyzes the compiled target file directly.

Steps 2 to 4 repeat in a loop until the agent gathers enough evidence to answer your question.

The important point is that the tools provide the facts and the AI provides the understanding. Neither one is asked to do the job of the other. Also all of this runs on your own machine so your files are not uploaded anywhere for the analysis itself.

A Working Example: Investigating VLC Media Player

To observe how REA operates in practice, I conducted a simple reverse engineering experiment on real-world compiled software. I chose VLC media player specifically because of its open source nature and open licensing. This study was conducted purely for educational purposes to examine binary structure and modern software architecture.

In software engineering, one must always understand software licenses and legal considerations before reverse engineering any binary.

Target Selection and Setup

The experiment was conducted locally on an Apple Silicon M4 Mac running macOS 26.5. This host hardware provided the processing performance required to run headless decompilation, binary inspection and artifact analysis entirely on machine without transmitting binary files to external servers.

For the target application, I chose the official Apple Silicon release of VLC media player version 3.0.24, distributed as a compressed 57 megabyte disk image file. VLC is famous for playing almost any media format without requiring extra downloads. I wanted to discover its internal architecture, how it starts up, how it handles security and how its playback pipeline is organized without looking at its source code.

For this investigation, I set up Antigravity running the Argon 4 AI model and connected the AI agent to the REA server using the Model Context Protocol. Rather than relying solely on a decompiler, I installed and configured a complete local analysis toolchain through REA, where each specialized tool contributed a distinct capability:

  • Ghidra and the Java Development Kit: An open source software reverse engineering suite that decompiles compiled machine code into structured high-level logic and reconstructs variable types.
  • GNU Binary Utilities (objdump and nm): Low-level binary inspection tools that parse Mach-O headers, inspect memory segments and extract symbol tables from compiled binaries.
  • Disk image and archive tools (hdiutil and artifact graphers): Container management tools that unpack, map and verify compressed disk images or filesystem packages without mounting or running untrusted code.
  • Code signing and security auditors (codesign and security): Operating system security utilities that audit digital signatures, verify developer certificate chains and inspect runtime entitlement permissions.
  • Property list decoders (plutil): Structured configuration parsers that extract application metadata, registered URL schemes, document associations and system settings.
  • Dynamic linker tracers (otool and resolution analyzers): Linker inspection tools that trace shared library search paths and map runtime dependencies between modules.
  • Interface Builder and asset decoders (ibtool and assetutil): Resource extraction tools that parse compiled graphical screens and decode visual asset catalogs.

I gave the AI agent a clear starting goal:

“Analyze this VLC installation disk image. Tell me how it starts up, which libraries it depends on, how its media pipeline is designed and provide evidence for every finding."

The Tool-Calling Workflow

A compiled application contains millions of machine instructions and thousands of files. You cannot feed raw binary files into an AI model directly without overwhelming its context window and triggering hallucinations.

Instead, I directed the AI agent to operate as an investigative planner using REA over the Model Context Protocol. Rather than guessing at file contents, the agent formulated specific hypotheses and invoked the configured local toolchain through structured MCP tool calls across three logical phases:

  1. Reconnaissance and safety audit: The agent mapped the container structure and verified code signatures before examining executable code.
  2. Structural and dependency mapping: It decoded metadata and traced dynamic linker paths to identify how the application interfaces with the operating system.
  3. Targeted headless decompilation: Once the key binaries were isolated, the agent invoked Ghidra in headless mode to reconstruct high-level logic, control flow and data structures without manual GUI interaction.

Every tool call recorded its output in an immutable local evidence ledger, ensuring that each architectural conclusion was grounded in verified facts.

The workflow followed an orderly progression:

flowchart LR
    step1["1. Inspect Disk Image<br/><small>1,709 cataloged items</small>"]
    step2["2. Audit Signatures<br/><small>VideoLAN certificates</small>"]
    step3["3. Parse Metadata<br/><small>13 streaming schemes</small>"]
    step4["4. Trace Dependencies<br/><small>Internal library paths</small>"]
    step5["5. Decompile Launcher<br/><small>7 startup functions</small>"]
    step6["6. Decompile Plugins<br/><small>334 dynamic modules</small>"]

    step1 --> step2
    step2 --> step3
    step3 --> step4
    step4 --> step5
    step5 --> step6

VLC Internal Architecture

By coordinating package inspection, binary analysis, dynamic dependency tracing and decompilation, the AI agent reconstructed the complete internal architecture of VLC at the component level (C3 architectural view). The software is organized into three distinct tiers: the bootstrap launcher, the core multimedia microkernel and the modular plugin ecosystem, communicating through well-defined interfaces and interacting directly with native operating system hardware.

flowchart LR
    subgraph STAGE1["1. Interface and Bootstrap"]
        LAUNCHER["Bootstrap Launcher<br/><small>89 KB • 7 Functions</small>"]
        GUI["macOS Cocoa Interface<br/><small>139 Classes • 28 Screens</small>"]
    end

    subgraph STAGE2["2. Core Microkernel"]
        API["Public API Controller<br/><small>295 Exported Functions</small>"]
        CORE["Object Tree and Memory<br/><small>Lifecycle Hierarchy</small>"]
        REG["Module Registry<br/><small>Capability Scoring</small>"]
    end

    subgraph STAGE3["3. Dynamic Plugins"]
        PLUGINS["Dynamic Plugin Ecosystem<br/><small>334 Modular Shared Libraries</small>"]
    end

    subgraph STAGE4["4. Media Pipelines"]
        INPUT["Input and Demuxer<br/><small>Stream Reader Pipeline</small>"]
        DECODER["Decoder Manager<br/><small>Hardware and Software Codecs</small>"]
        CLOCK["Audio Master Clock<br/><small>Sound and Sync Timing</small>"]
        VIDEO["Video Frame Pool<br/><small>Zero-Copy Picture Buffers</small>"]
    end

    subgraph STAGE5["5. Hardware Output"]
        SOUND_HW["CoreAudio Output<br/><small>Sound Hardware</small>"]
        DISP_HW["Metal Display<br/><small>Video Surface</small>"]
    end

    LAUNCHER -->|"1. Initializes"| API
    GUI -->|"2. User Controls"| API
    API -->|"3. Manages State"| CORE
    API -->|"4. Queries Plugins"| REG
    REG <-->|"5. Binds Modules"| PLUGINS

    API -->|"6. Starts Stream"| INPUT
    PLUGINS -->|"7. Reader Modules"| INPUT
    INPUT -->|"8. Elementary Streams"| DECODER
    PLUGINS -->|"9. Codec Modules"| DECODER

    DECODER -->|"10. Decoded Audio"| CLOCK
    DECODER -->|"11. Decoded Video"| VIDEO
    CLOCK -->|"12. Clock Sync"| VIDEO

    CLOCK -->|"13. Sound Output"| SOUND_HW
    VIDEO -->|"14. Display Frames"| DISP_HW

Tier 1: The Bootstrap Launcher and Safety Controls

The bootstrap executable (Contents/MacOS/VLC) is only 89 kilobytes on disk, with its executable code accounting for just 1,988 bytes across seven internal functions. Decompilation with Ghidra confirmed that it contains zero multimedia processing code. It integrates the Google Breakpad crash reporter while its role is strictly environment validation, process isolation and engine bootstrapping.

// Reconstructed initialization logic from the 1,988-byte bootstrap executable
int main(int argc, const char **argv) {
    if (getenv("VLC_DISABLE_BREAKPAD") == NULL) {
        initBreakpad(); // Allocates ~/Library/Caches/org.videolan.vlc
    }

    signal(SIGPIPE, SIG_IGN); // Ignore broken pipes

    // Guard against execution under root
    if (geteuid() == 0) {
        fprintf(stderr, "VLC is not supposed to be run as root.\n");
        return 1;
    }

    // Mask signals and route to Grand Central Dispatch
    sigset_t set;
    sigemptyset(&set);
    sigaddset(&set, SIGINT);
    sigaddset(&set, SIGTERM);
    sigaddset(&set, SIGCHLD);
    pthread_sigmask(SIG_BLOCK, &set, NULL);

    // Bootstrap microkernel and load default interface
    libvlc_instance_t *vlc = libvlc_new(argc, argv);
    libvlc_add_intf(vlc, "hotkeys,none");
    libvlc_add_intf(vlc, NULL);

    // Launch Cocoa event loop or fall back to headless run loop
    if (NSApp != nil) {
        [NSApp run];
    } else {
        CFRunLoopRun();
    }
    return 0;
}

The launcher also registers a background child process reaper using non-blocking wait calls to clear exited helper processes automatically.

Tier 2: The Core Multimedia Microkernel

Dynamic linker tracing confirmed that the launcher resolves two internal libraries through relative search paths (@executable_path/lib), guaranteeing self-contained execution without conflicting with system libraries:

  • libvlc.5.dylib: The stable public boundary exporting 295 functions for high-level playback and playlist control.
  • libvlccore.9.dylib: The multimedia microkernel exporting 592 internal functions coordinating threading, memory, pipelines and device output.

Ghidra decompilation recovered the internal memory layout of the main player instance structure (168 bytes) and the reactive variable bus:

// Recovered memory layout of the main player instance structure (168 bytes)
struct libvlc_instance_t {
    vlc_object_t *p_libvlc_int; // Offset 0: pointer to core engine instance
    void         *p_reserved;   // Offset 8: reserved field initialized to zero
    int           ref_count;    // Offset 16: atomic reference count
    vlc_mutex_t   lock;         // Offset 24: 64-byte mutual exclusion lock
    void         *event_list;   // Offset 88: registered event callback list
};

// Reactive variable bus pattern: decoupled observer registration
var_Create(obj, "volume", VLC_VAR_INTEGER);
var_AddCallback(obj, "volume", VolumeCallback, client_data);

The microkernel designates the audio hardware output as the master timekeeper. If video frames arrive out of phase, the engine dynamically adjusts video presentation timing against the master audio clock to maintain exact lip-sync.

Tier 3: The Modular Plugin Ecosystem

Artifact graph analysis cataloged 334 modular shared libraries in the plugins directory. Every plugin exports a standardized entry function (_vlc_entry__3_0_0f) that executes an opcode-driven registration protocol rather than static descriptor tables:

// Dynamic capability registration pattern in plugins (_vlc_entry__3_0_0f)
int vlc_entry(int (*activate)(void *target, void *data, int opcode), void *target) {
    activate(target, NULL, VLC_MODULE_CREATE);
    activate(target, "demux", VLC_MODULE_CAPABILITY);
    activate(target, (void *)100, VLC_MODULE_SCORE); // Priority score
    activate(target, OpenDemux, VLC_MODULE_CB_OPEN);
    activate(target, CloseDemux, VLC_MODULE_CB_CLOSE);
    return 0;
}

For media rendering, Ghidra decompilation revealed how codec plugins coordinate with display plugins to achieve zero-copy hardware playback on Apple Silicon using Apple VideoToolbox:

// Zero-copy hardware video decoding pipeline (libvideotoolbox_plugin.dylib)
VTDecompressionSessionCreate(...); // Apple VideoToolbox hardware decode
CVPixelBufferRef pixelBuffer;      // Hardware-backed buffer in unified memory (IOSurface)

// Direct GPU surface binding in video output (libcaopengllayer_plugin.dylib)
CGLTexImageIOSurface2D(cgl_ctx, GL_TEXTURE_RECTANGLE, GL_RGBA, width, height,
                       GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, ioSurface, 0);

At startup, VLC parses a pre-computed module cache (plugins.dat), activating plugins on demand across six categories:

  • Access protocols (34 plugins): File systems, optical discs, network shares and capture devices.
  • Demuxers (45 plugins): Container parsers for MP4, MKV, AVI, OGG, FLAC and adaptive streams.
  • Codecs (59 plugins): Apple VideoToolbox hardware acceleration and software codecs.
  • Audio and video filters (104 plugins): Equalizers, spatial audio, deinterlacers and GPU shaders.
  • Outputs (38 plugins): OpenGL and Metal surfaces, Chromecast streaming and network broadcast.
  • Control and security (34 plugins): Keyboard shortcuts, macOS Keychain storage and Lua scripts.

The macOS Interface Plugin

Artifact graphing and resource decoding proved that the user interface is completely decoupled from the main binary as a 1.6 megabyte dynamic plugin (libmacosx_plugin.dylib). Resource tools decoded 28 compiled interface screens (.nib) and 297 visual assets in Assets.car, while Ghidra analyzed its 139 Objective-C classes.

To shut down cleanly without hanging AppKit‘s modal run loop, Ghidra revealed that the plugin posts a synthetic application-defined event to wake the loop:

// Graceful AppKit termination handshake reconstructed from Ghidra
static void vlc_stop_main_loop(void *context) {
    if (NSApp != nil) {
        [NSApp stop:nil];
        // Post synthetic event code 15 to unblock modal [NSApp run]
        NSEvent *wake = [NSEvent otherEventWithType:NSEventTypeApplicationDefined
                                           location:NSMakePoint(0.0, 0.0)
                                      modifierFlags:0
                                          timestamp:0.0
                                       windowNumber:0
                                            context:nil
                                            subtype:0
                                              data1:0
                                              data2:0];
        [NSApp postEvent:wake atStart:YES];
    } else {
        CFRunLoopStop(CFRunLoopGetCurrent());
    }
}

The plugin registers with a priority score of 200 for the user interface and 100 for the video window surface. It integrates directly with macOS for dynamic dark mode styling, global keyboard media keys, Touch Bar track display and automatic keyboard backlight dimming during fullscreen video.

Deep Dive into the Evidence

When an AI agent analyzes compiled software, the greatest risk is hallucination: producing plausible claims that do not correspond to the actual machine instructions. REA prevents this using a local Evidence Ledger. Every time a tool executes, its raw inputs, outputs and cryptographic digests are recorded in an immutable ledger stored on disk before any reasoning takes place. The agent cannot make an architectural claim without referencing a verified evidence record.

The investigation moved through six progressive layers, systematically peeling back the software from its outer container down to compiled machine instructions:

1. Target Provenance and Integrity

  • Rationale: Establishing chain of custody is essential before reverse engineering. If the disk image has been modified, damaged or acquired from an unverified source, all subsequent technical deductions are compromised.
  • What this evidence is: A tamper-proof JSON ledger record created when REA first ingested the disk image using inspect_artifact. It stores the exact file size, cryptographic hash and provenance verification status on local disk.
// REA evidence record (ev_8719890237218a77...)
{
  "evidence_id": "ev_8719890237218a77ed03a6b0fefda4ca4895967879ade3af4836cc033284f724",
  "tool": "inspect_artifact",
  "artifact_name": "vlc-3.0.24-arm64.dmg",
  "sha256": "64a89d93cdd30b0e97131743e246373db82d6826ea882d265d46d74b136da2b7",
  "byte_count": 56960605,
  "provenance": "match-official-release"
}
  • Key finding: The SHA-256 digest matches the official VideoLAN release signature, proving that the analyzed binary is genuine and untampered.

2. Container Composition and Packaging Integrity

  • Rationale: Mounting an untrusted disk image directly in the operating system creates security risks and can modify file timestamps. The investigation required safely cataloging the internal directory hierarchy without mounting the disk.
  • What this evidence is: An artifact containment graph (agm_1b8f3c44...) produced by REA’s safe disk image parser. It indexes all packaged files, directories and symlinks to detect structural corruption or unexpected payloads.
Artifact Graph Metrics (Graph ID: agm_1b8f3c44f1f6b860d5e15dd9ddc2d666fffabf37a52d3fa498e19a8c51c9af1c):
  Root Container       : Apple Disk Image (vlc-3.0.24-arm64.dmg)
  Cataloged Nodes      : 1,709 unique components
  FileSystem Paths     : 1,403 regular files, 418 directories and 19 symbolic links
  Containment Edges    : 1,820 structural relationships
  Integrity Violations : 0 contradictions
  • Key finding: The package contains 1,709 components with zero structural integrity errors. Every single executable binary, including all 334 plugin modules, shares a valid code signature from VideoLAN validated against Apple’s Root Certificate Authority.

3. Security Permissions and Application Metadata

  • Rationale: An application’s declared system contract establishes its attack surface and security boundaries. Auditing entitlements and registered URL handlers reveals what system privileges and network protocols the software can access.
  • What this evidence is: The extracted Apple Hardened Runtime XML dictionary from the code signature header (inspect_signature) combined with protocol registrations from Info.plist (inspect_plist).
<!-- Extracted Hardened Runtime entitlements from Contents/MacOS/VLC -->
<dict>
    <key>com.apple.security.cs.allow-jit</key>
    <true/> <!-- Enables MAP_JIT for Blu-ray Java menus -->
    <key>com.apple.security.cs.disable-library-validation</key>
    <true/> <!-- Permits loading third-party plugins -->
    <key>com.apple.security.automation.apple-events</key>
    <true/> <!-- Controls external media players -->
    <key>com.apple.security.device.audio-input</key>
    <true/> <!-- Microphone audio capture -->
    <key>com.apple.security.device.camera</key>
    <true/> <!-- Video camera capture -->
</dict>
  • Key finding: VLC enforces Apple Hardened Runtime while requesting five specific entitlements. It registers 13 streaming URL schemes across 9 network protocols (including HTTP, HTTPS, RTSP, UDP, RTP, RTMP, SFTP and SMB) and associates with 108 distinct media file extensions.

4. Dynamic Linkage and Dependency Boundaries

  • Rationale: Standalone applications must resolve their shared libraries reliably across different macOS versions without causing conflicts with system libraries. Tracing dynamic load commands proves how libraries are located at runtime.
  • What this evidence is: A dynamic linker dependency trace (trace_dylib_resolution and inspect_macho) simulating how the operating system dynamic linker maps executable load paths.
Dynamic Load Commands in Contents/MacOS/VLC:
  LC_RPATH      : @executable_path/lib
  LC_RPATH      : @executable_path/../Frameworks
  LC_LOAD_DYLIB : @rpath/libvlc.5.dylib     -> Contents/MacOS/lib/libvlc.5.dylib
  LC_LOAD_DYLIB : @rpath/libvlccore.9.dylib -> Contents/MacOS/lib/libvlccore.9.dylib
  LC_LOAD_DYLIB : @rpath/Breakpad.framework/Versions/A/Breakpad
  • Key finding: The launcher uses relative runtime search paths (@executable_path/lib) to load bundled copies of libvlc.5.dylib and libvlccore.9.dylib. This guarantees self-contained operation without external library conflicts.

5. Decompiled Logic and Memory Structures

  • Rationale: High-level metadata cannot confirm internal execution behavior. To understand memory management, thread synchronization and object lifecycles, machine instructions must be decompiled into high-level source logic.
  • What this evidence is: High-level C code recovered by headless Ghidra decompilation (analyzeHeadless) from the public API initialization routine (_libvlc_new) inside libvlc.5.dylib.
// Decompiled struct initialization in libvlc.5.dylib (_libvlc_new)
long *inst = malloc(168); // Exact allocation size for libvlc_instance_t
if (inst != NULL) {
    *inst = internal_engine_create();          // Offset 0: p_libvlc_int pointer
    inst[1] = 0;                               // Offset 8: reserved field
    *(int *)(inst + 2) = 1;                    // Offset 16: atomic ref_count
    vlc_mutex_init((vlc_mutex_t *)(inst + 3)); // Offset 24: 64-byte mutex lock
    inst[11] = 0;                              // Offset 88: event callback list
}
  • Key finding: The decompiler proved the exact 168-byte memory layout of the main player instance structure (libvlc_instance_t), confirming mutex protection and reference counting offsets directly from machine instructions.

6. User Interface Screens and Visual Assets

  • Rationale: A native desktop application couples its event loop to compiled graphical resources. Decoding interface files and asset catalogs verifies how the presentation layer connects to the underlying playback engine.
  • What this evidence is: Structural element counts from decoding 28 compiled Interface Builder screen files (.nib) using decode_interface_builder and the compiled Apple asset catalog (Assets.car) using inspect_asset_catalog.
Interface Builder Screens (.nib) Metrics:
  SimplePreferences.nib : 540 visual objects and 290 connection bindings
  MainMenu.nib          : 419 visual objects and 385 connection bindings
  Open.nib              : 439 visual objects and 146 connection bindings
  VideoEffects.nib      : 482 visual objects and 289 connection bindings
Compiled Asset Catalog (Assets.car Version 556.0):
  Total Renditions      : 297 graphical assets (Retina bitmaps with LZFSE compression)
  • Key finding: The interface layer contains dense object graphs with hundreds of data bindings. The asset catalog bundles 297 vector and Retina bitmap renditions taking 645 kilobytes, showing comprehensive native AppKit integration.

Practical Applications

Having a clear architectural map and verified evidence enables several practical engineering activities:

  • Clean-room software development: Engineers can study how complex software operates to build independent, compatible implementations without copying any proprietary code.
  • Security auditing and vulnerability research: Security teams can examine how an application handles external inputs, permissions and background signals to identify potential risks before they are exploited.
  • Legacy system maintenance: When maintaining older software whose original authors or documentation are no longer available, this approach allows teams to quickly understand internal designs and plan migrations.
  • Educational analysis: Students and junior engineers can explore how production-grade systems handle concurrency, modularity and cross-platform compatibility in compiled environments.

What People Are Doing With It

Since REA went viral on GitHub, developers and security researchers have shared practical experiments showcasing agentic reverse engineering. By connecting AI agents to local decompilers and protocol tracers, users have explored everything from desktop app mechanics to full-scale software reconstruction.

The Rise of AI-Assisted Clones: The Adobe Suite Experiments

The most viral experiments involve attempting to recreate complex, subscription-heavy proprietary software. The most prominent example is ArtCraft, an ambitious open-source initiative that used AI coding agents alongside REA to analyze and prototype native Rust alternatives to Adobe Creative Cloud applications:

  • PhotoCraft (aiming at Adobe Photoshop): Prototyping layer systems, blending modes and canvas manipulation pipelines by analyzing image rendering loops.
  • FilmCraft (aiming at Adobe Premiere Pro): Mapping timeline coordination, audio-video synchronization and multi-track video sequencing.
  • LightCraft (aiming at Adobe Lightroom): Studying non-destructive photo adjustment pipelines and color grading parameter models.

While projects like ArtCraft demonstrate how quickly an AI agent can build functioning user interfaces and basic editing workflows from scratch, they also highlight real-world limitations. Decades of specialized optimizations, hardware acceleration and edge-case handling in mature commercial suites cannot be recreated overnight. Today these clones remain early alpha experiments rather than production-grade replacements.

Other Popular Community Experiments

Beyond creative suites, developers are using REA for several practical engineering use cases:

  • Deconstructing Electron and Desktop Applications: Modern desktop applications often wrap complex web applications inside frameworks like Electron. Developers use REA to parse packaged archives, trace Inter-Process Communication (IPC) messages, inspect local SQLite databases and uncover offline data synchronization protocols.
  • Software and Game Preservation: Retro gaming enthusiasts use REA to inspect vintage DOS binaries and classic arcade game mechanics, decompiling low-level processor routines to build portable WebAssembly or native ports for modern computers.
  • Auditing Agentic AI Frameworks: Security engineers and researchers use REA to analyze proprietary AI command-line tools, examining internal prompt scaffolding, system instructions and tool definitions directly from compiled runtime binaries.
  • Automated Security Triage: Incident response teams use REA to perform rapid preliminary assessments of unknown binaries, cataloging digital signatures, external network endpoints and suspicious memory calls before committing hours to manual analysis.

The Legal and Ethical Risks of Touching Proprietary Software

The ability to inspect and recreate software with AI agents introduces serious legal and ethical questions. Reverse engineering proprietary software carries substantial legal exposure if conducted without strict precautions.

Reverse engineering proprietary software is subject to strict legal boundaries. Breaching license agreements, copying protected code or distributing trade secrets can lead to civil litigation and criminal liability.

When working with commercial software, several critical risks must be considered:

  • End User License Agreement (EULA) Violations: Almost all commercial software licenses explicitly forbid disassembly, decompilation and reverse engineering. Bypassing these terms can constitute breach of contract.
  • Copyright Infringement vs Clean-Room Design: There is a fundamental legal distinction between studying how software behaves and copying its implementation. In legitimate clean-room engineering, two separate teams must be used: an analysis team inspects the original software and writes behavioral specifications, while an independent development team writes new code from those specifications without ever seeing the original binary or decompiled output. If an AI agent reads proprietary decompiled code and directly generates replacement code in the same session, that separation is broken, exposing the author to direct copyright infringement claims.
  • Trade Secret Misappropriation: Proprietary algorithms, proprietary codecs and internal communication protocols may be protected as trade secrets. Extracting and publishing them can result in severe legal action.
  • Circumvention of Copyright Protection (DMCA): In many jurisdictions, including under Section 1201 of the Digital Millennium Copyright Act (DMCA) in the United States, reverse engineering mechanisms designed to protect copyrighted material (such as license checkers or copy protection systems) is illegal, regardless of educational intent.
  • Security and Supply-Chain Dangers: Unofficial clones and unauthorized binaries circulating online frequently serve as distribution channels for trojans, credential stealers and backdoors.

What the Future Holds

The combination of AI agents, local reverse engineering tools and the Model Context Protocol brings a significant change to how software engineering teams analyze compiled applications. While this approach is still evolving, we can expect several practical trends and industry shifts in the coming years:

1. Client-Side Code Obfuscation Will No Longer Be Sufficient

For many years companies have relied on techniques like code minification, stripping debug symbols and scrambling control flow to hide their business logic inside client applications. With AI agents capable of driving decompilers, reconstructing function logic and recovering variable names from surrounding code, hiding secrets inside compiled binaries will no longer work.

Development teams will need to follow strict zero-trust principles. Any critical algorithm, secret key or sensitive business logic must reside securely on backend servers rather than inside client-side software.

2. Automated Binary Auditing in CI/CD Pipelines

Today most software security reviews happen manually before major releases. In the future engineering teams will integrate AI agents directly into their continuous integration and continuous deployment (CI/CD) pipelines to audit compiled build outputs automatically.

These agents will decompile final release binaries, verify memory allocations, check input validation routines and flag security vulnerabilities such as buffer overflows or insecure permissions before the software reaches end users.

3. Faster Malware Analysis and Incident Response in Security Operations

In cybersecurity, analyzing unknown or malicious binaries typically requires hours of manual work by experienced reverse engineers. Today security operations teams are already using AI agents with local binary tools to accelerate this process.

By automatically unpacking suspicious files, identifying network command addresses and highlighting dangerous system calls, AI-assisted tools help analysts classify threats and extract indicators of compromise (IOCs) in minutes rather than days. This allows organizations to respond to security incidents much faster.

4. Clear Standards for Clean-Room Development

With open-source projects using AI to study commercial applications and create alternative software, legal guidelines around software copyright will require clear updates.

In the future we can expect formal standards for AI-assisted clean-room engineering. This will involve two isolated setups: one AI agent analyzes the target binary and writes clear functional specifications, while a separate engineering team or isolated agent writes completely fresh code based only on those specifications, backed by audit logs proving no proprietary code was copied.

5. Modernizing Legacy Systems Without Source Code

In many core industries such as banking, manufacturing and public utilities, critical software systems run on compiled binaries whose original source code was lost years ago. Finding engineers who understand the original setup is often difficult and expensive.

AI-driven reverse engineering offers a practical way to preserve these systems. By converting machine instructions into structured high-level logic and documenting internal data structures, engineering teams can safely migrate legacy software to modern languages like Rust and Go with confidence.

Conclusion

Reverse engineering has always been one of the most challenging areas in software engineering. Traditionally it required years of dedicated practice in assembly language, processor registers and operating system internals.

What REA shows is that artificial intelligence does not replace established tools like Ghidra, nor does it remove the need for engineering fundamentals. Instead it acts as a reliable coordinator. Rather than spending hours reading machine code instruction by instruction, the engineer can guide an AI agent to investigate specific parts of a program and review the findings.

The real strength of this workflow is its reliance on verifiable evidence. Large language models often produce guesses when context is missing. By saving every tool output to a local evidence ledger, REA ensures that every deduction is backed by real binary data. In technical analysis, verifiable facts will always be more valuable than unverified claims.

My experiment with VLC media player proved that this methodology works on production-grade software. From unpacking the 57 megabyte disk image and auditing Apple Hardened Runtime permissions to decompiling the 168-byte player structure and tracing hardware video decoding pipelines, the entire architecture was systematically understood through a step-by-step dialogue.

As modern software ecosystems grow larger and more complex, having the ability to inspect and verify what compiled binaries are doing is essential. By connecting local developer tools to AI agents through open standards, we gain a practical, transparent way to study, secure and maintain the software we rely on every day.

Citations

Here are the primary projects, tools, documentation and legal references discussed throughout this article:

Share this Insight