Reverse Engineering • Binary Analysis • Security Research • Systems Engineering

I build analysis platforms that help understand complex software at scale.

My work focuses on reverse engineering, binary analysis, malware research, program visualization, and automation. Most of my projects are built from scratch around large datasets, graph analysis, and interactive tooling rather than simple proof-of-concepts.

Current areas of interest include:

• Binary analysis & reverse engineering
• Program graph construction and visualization
• Static + dynamic analysis pipelines
• Vulnerability research
• Malware analysis & behavioral clustering
• OSINT and security automation
• Bioinformatics visualization
• Generative algorithms (CPPN / HyperNEAT)

• Reverse Engineering

• Malware Analysis

• Static Binary Analysis

• Dynamic Analysis & Debugging

• Program Graph Construction

• Call Graph Recovery

• Control Flow Analysis

• Binary Visualization

• SQL-backed Program Analysis

• Vulnerability Research

• Python Automation

• Interactive Data Visualization

• Bioinformatics Tool Development

• Evolutionary Algorithms

• AI-assisted Security Research

• 🚀 Featured Projects

Infrastructure-Driven Threat Intelligence & Campaign Discovery
IOC Enrichment • Multi-Vantage Traceroutes • BGP Intelligence • ASN Correlation • Infrastructure Graphs • Offline Discovery

Waypoint is an infrastructure-driven threat intelligence and malware campaign discovery platform designed to uncover relationships between indicators of compromise, network infrastructure, routing paths, autonomous systems, and observed malware families.

Traditional threat intelligence workflows frequently begin with known indicators and attempt to enrich or classify them using external feeds.

Waypoint takes a different approach.

It combines IOC collection with BGP data, reverse DNS, ASN metadata, geographic enrichment, and multipath traceroutes collected from multiple vantage points. These observations are correlated into an infrastructure intelligence graph that can reveal additional candidate infrastructure not present in the original IOC feeds.

The platform is designed to help answer a different question:

What additional infrastructure can we discover by investigating the network surrounding an indicator, rather than investigating only the indicator itself?

Core data sources and analytical dimensions include:

• Indicators of compromise from multiple sources
• IPv4 and IPv6 network intelligence
• BGP prefixes and routing relationships
• Autonomous system numbers and ASN metadata
• Reverse DNS and PTR records
• Multi-vantage traceroutes
• Router and hop-level observations
• IP-to-prefix and IP-to-ASN relationships
• Malware-family associations
• Infrastructure convergence across vantage points
• Fast-flux candidates
• DGA-like hostname candidates
• Shared-infrastructure clusters
• SQL-based threat hunting
• Evidence-backed graph exploration

The goal is to move beyond static IOC lists toward a continuously enriched, infrastructure-oriented view of potential malware campaigns.

                  IOC Sources
                      |
                      v
               IOC Collection
                      |
           +----------+----------+
           |          |          |
           v          v          v
          BGP        RDNS       ASN Metadata
           |          |          |
           +----------+----------+
                      |
                      v
            Multi-Vantage Tracing
                      |
             +--------+--------+
             |        |        |
             v        v        v
           Routers   ASNs    Prefixes
             |        |        |
             +--------+--------+
                      |
                      v
             Infrastructure Graph
                      |
          +-----------+-----------+
          |           |           |
          v           v           v
       Clusters    Candidates    SQL
          |           |           |
          +-----------+-----------+
                      |
                      v
           Infrastructure Discovery

Waypoint investigates relationships between known indicators and the surrounding network infrastructure.

An IOC is not treated as an isolated IP address or hostname. It becomes an entry point into a larger investigation involving its routing environment, network prefix, autonomous system, observed routers, DNS records, and other indicators associated with related infrastructure.

Potential discovery paths include:

Known IOC
   |
   v
Observed Router
   |
   v
Upstream ASN
   |
   v
Shared Infrastructure
   |
   v
Additional Candidate IOC

Infrastructure relationships can also be explored laterally and downstream where the collected observations support those connections.

This allows investigators to identify infrastructure candidates that may be worth examining even when those candidates were not included in the initial threat feeds.

One of the project's central design goals is to discover candidate infrastructure from locally available intelligence and previously collected observations.

Once the enrichment data is available, investigators can query existing relationships without requiring a fresh Internet-wide scan for every investigation.

This enables offline analysis of:

• Shared routing infrastructure
• Repeated ASN associations
• Common BGP prefixes
• Infrastructure observed along multiple traceroutes
• Related IOC records
• Historical infrastructure relationships
• Potentially connected malware-family clusters

In small-scale experimental runs, the platform has surfaced additional infrastructure candidates beyond the original feed entries.

These results are investigative leads rather than confirmed campaign attribution. Their value comes from providing new candidates for validation.

Waypoint automatically collects indicators from multiple configured sources and enriches them in the background.

Instead of requiring analysts to manually investigate every IP address, the platform builds a local intelligence dataset that can be queried and correlated.

Enrichment dimensions include:

• BGP announcements and prefixes
• ASN ownership and metadata
• Reverse DNS records
• Traceroute observations
• Router addresses
• Geographic information where available
• Source-feed provenance
• Malware-family labels
• Prefix and ASN relationships

              Raw IOC Feeds
                    |
                    v
             Normalize IOCs
                    |
                    v
            Background Enrichment
                    |
       +------------+------------+
       |            |            |
       v            v            v
      BGP          RDNS        Traces
       |            |            |
       +------------+------------+
                    |
                    v
             Local Intelligence
                 Database
                    |
                    v
             SQL Investigation

The architecture separates collection from investigation, allowing existing enrichment data to be explored without repeatedly querying every upstream source.

A central feature of Waypoint is the ability to compare observed routing paths from different vantage points.

Traceroutes collected from separate environments can reveal different visible portions of a destination's network path. Comparing them can expose shared routers, different upstream providers, ASN transitions, and convergence points.

The platform can compare observations from environments such as a local Windows host and a remote Linux or cloud-based vantage point.

Vantage A
   |
   v
AS15169 - Google
   |
   v
AS196844 - PIONIER
   |
   v
AS29414 - Destination Network
   |
   v
Target IOC

Vantage B
   |
   v
AS1299 - Arelion
   |
   v
AS13293 - Observed Transit
   |
   v
Shared Observed Routers
   |
   v
Target Network

These examples illustrate why one traceroute should not be treated as a complete description of a destination's network environment.

• Compare routes collected from different vantage points
• Track responding routers and observed hops
• Associate hops with ASN and BGP information where available
• Enrich routers with reverse DNS and geographic data
• Identify ASN transitions
• Highlight routers observed by multiple vantage points
• Compare protocol-specific probes
• Display round-trip time and RTT changes
• Identify unresponsive hops and incomplete paths
• Investigate upstream, lateral, and downstream infrastructure candidates

Traceroutes show the responding network interfaces visible to a particular probe. They do not necessarily reveal every router, the physical Internet path, or a definitive bidirectional route.

Waypoint transforms collected and derived relationships into an interactive infrastructure investigation environment.

Graph relationships can connect:

IOC
 |
 +---- IP Address
 |       |
 |       +---- BGP Prefix
 |       |
 |       +---- ASN
 |       |
 |       +---- Reverse DNS
 |       |
 |       +---- Observed Router
 |
 +---- Source Feed
 |
 +---- Malware Family
 |
 +---- Traceroute
         |
         +---- Hop
         |
         +---- ASN Transition
         |
         +---- Shared Router

Investigators can move between an IOC, its routing environment, related network entities, and the evidence supporting each relationship.

Potential investigative pivots include:

• IP address to ASN
• IP address to BGP prefix
• IP address to PTR hostname
• Router to observed routing paths
• ASN to associated indicators
• Shared prefix to related IP addresses
• IOC to source-feed provenance
• Malware-family label to associated infrastructure
• Multiple vantage points to shared routers
• Infrastructure cluster to its constituent evidence

The graph is designed to help generate and prioritize hypotheses, not to equate shared hosting or common transit with common malicious ownership.

Waypoint identifies potential relationships across indicators using shared infrastructure characteristics.

Cluster dimensions can include ASN, prefix, routing observations, malware-family labels, and other recorded relationships.

Example results from the current dataset:

Illustrative results from the current dataset, not live measurements.

A cluster can expose infrastructure associated with several recorded malware-family labels, creating useful pivots for further investigation.

• Shared hosting or network providers
• Repeated ASN associations across indicators
• Infrastructure used by multiple recorded malware families
• Candidate relationships between previously separate IOC groups
• Network entities worth investigating for additional indicators
• Historical changes in observed associations

An ASN can host unrelated customers, benign services, compromised systems, and multiple unrelated malware operations.

A shared ASN is not proof that two indicators belong to the same operator. Confidence labels are properties of the platform's derived scoring, not definitive attribution verdicts.

Waypoint analyzes hostname-to-IP diversity and infrastructure turnover to identify domains that may warrant fast-flux investigation.

The current candidate scoring uses recorded infrastructure diversity and turnover evidence.

Features include:

• Number of observed IP addresses
• Number of associated ASNs
• Country diversity
• Prefix diversity
• Observation span
• Observed IP turnover rate
• Candidate score

Example:

Illustrative results from the current dataset.

A hostname associated with a large and changing set of addresses across multiple ASNs, countries, and prefixes may deserve closer examination.

Waypoint uses these characteristics to generate candidates for investigation.

TTL is not part of the current score, because TTL information is not stored in the current passive-DNS dataset.

High diversity is not by itself proof of fast-flux behavior. CDNs, hosting platforms, load balancing, and other legitimate architectures can produce similar patterns.

Waypoint identifies suspicious-looking hostnames using lexical and cardinality features.

The current heuristic examines characteristics such as:

• Character entropy
• Digit proportion
• Vowel proportion
• Consonant-run patterns
• Hostname length
• IP cardinality

Example:

Illustrative results from the current dataset.

The current scoring is based on lexical and cardinality heuristics over the collected hostname dataset.

It does not currently use a dictionary model, an n-gram model, or TLD weighting.

The resulting scores are candidate-ranking signals, not proof that a hostname was generated algorithmically or is malicious.

Waypoint aggregates observed IOC routing paths to identify autonomous systems that appear frequently across the collected dataset.

This creates an infrastructure-oriented view of the network entities traversed by or associated with many observed IOC paths.

Example:

Illustrative results from the current dataset.

These statistics can help investigators prioritize infrastructure pivots and understand which networks recur across the observed routing dataset.

Waypoint includes a SQL REPL for directly querying the enriched intelligence dataset.

Rather than relying entirely on predefined dashboards, investigators can formulate their own questions against the locally available records.

• Do any upstream routers or ASNs also appear in another IOC's observed route?
• Which ASNs occur most frequently across malware-associated routes?
• Which prefixes contain multiple indicators from different feeds?
• Which routers appear from multiple vantage points?
• Which indicators have the largest number of related infrastructure entities?
• Which fast-flux candidates overlap with known IOC records?
• Which domains have high lexical scores and multiple associated IPs?
• Which network relationships are supported by multiple independent observations?

The following are conceptual query patterns. Adapt table and column names to the current database schema.

Find ASNs associated with multiple indicators:

SELECT
    asn,
    COUNT(DISTINCT ip) AS unique_iocs
FROM bgp_asn
GROUP BY asn
HAVING COUNT(DISTINCT ip) > 1
ORDER BY unique_iocs DESC;

Inspect repeated router observations:

SELECT
    router_ip,
    COUNT(*) AS observations,
    COUNT(DISTINCT vantage) AS vantage_points
FROM traceroute_hops
GROUP BY router_ip
HAVING COUNT(DISTINCT vantage) > 1
ORDER BY vantage_points DESC, observations DESC;

Find hostnames with high candidate scores:

SELECT
    hostname,
    candidate_score,
    ip_count,
    asn_count
FROM fast_flux_candidates
ORDER BY candidate_score DESC;

The SQL engine makes it possible to test hypotheses immediately without needing a new feature or a fresh external query for every question.

Selecting a node opens a detail view that combines observed information with derived relationships.

For an IP address, this can include:

• Associated ASN and network holder
• BGP prefix
• Country or geographic enrichment
• Indicator classification
• Source-feed provenance
• Malware-family associations
• Observed traceroute paths
• Router relationships
• Derived infrastructure connections

Example:

IOC Detail

Classification:
    TrickBot-associated indicator

ASN:
    AS29414

Network:
    ASN-BIAMAN-COM

BGP Prefix:
    82.139.146.128 - 82.139.146.255

Country:
    PL

Source:
    

Waypoint distinguishes directly recorded observations from correlations inferred by the platform.

OBSERVED
    An IOC feed lists the IP as associated with TrickBot.

OBSERVED
    BGP data associates the address with an ASN.

OBSERVED
    The address falls within an announced prefix.

DERIVED
    Related infrastructure candidates are identified
    from recorded relationships.

This separation is essential when investigating shared infrastructure.

A relationship may justify further investigation without establishing common ownership, operator identity, or campaign attribution.

Multi-vantage analysis can reveal routers that appear in more than one observed path.

When separate vantage points encounter the same responding router, that convergence becomes an additional investigative pivot.

The interface can distinguish:

• Observed routers
• Unobserved segments
• Convergence points
• ASN transitions
• RTT changes
• Vantage origins
• Incomplete traces

Example:

Vantage A --------------------+
                              |
                              v
                       Shared Router
                              |
                              v
                         Target Network
                              ^
                              |
Vantage B --------------------+

Shared routers can help identify overlapping portions of observed routes and reveal additional infrastructure relationships worth investigating.

Combined with ASN, PTR, and prefix enrichment, these observations may reveal network entities that do not appear in the original IOC feeds.

Convergence is evidence of a shared observed router, not proof that the source indicators share an operator or campaign.

One of Waypoint's central design goals is to enable discovery from already collected intelligence.

Many intelligence workflows depend heavily on constant scanning, external lookups, and new feed ingestion.

Waypoint can instead investigate the relationships already represented in its local dataset.

             Existing IOC Dataset
                      |
                      v
             Previously Collected
              Network Evidence
                      |
                      v
              Local Correlation
                      |
          +-----------+-----------+
          |           |           |
          v           v           v
       Shared       Router      ASN / Prefix
       Routers      Overlap      Relationships
          |           |           |
          +-----------+-----------+
                      |
                      v
             New Candidate Leads

This supports repeatable investigations, offline analysis, and hypothesis testing without requiring every investigative pivot to initiate another network scan.

The discovery process is bounded by the evidence available in the local dataset. Offline analysis can derive new candidate relationships from existing observations, but it cannot independently observe previously uncollected infrastructure without new evidence.

Waypoint supports an investigation workflow that starts with an IOC and expands outward through the network infrastructure.

Known Indicator
      |
      v
Collect Existing Intelligence
      |
      v
Enrich BGP / RDNS / ASN
      |
      v
Inspect Existing Traceroutes
      |
      v
Compare Multiple Vantage Points
      |
      v
Identify Shared Routers & Networks
      |
      v
Generate Infrastructure Candidates
      |
      v
Query Related IOCs
      |
      v
Review Evidence & Provenance
      |
      v
Validate Campaign Hypotheses

The result is an iterative workflow in which each observed relationship can generate new investigative pivots.

Potential extensions to the existing platform include:

Integrate Selenium and a managed browser environment to capture screenshots of domains under investigation.

Potential functionality:

• Automated page rendering
• Screenshot capture
• Redirect-chain recording
• Page-title and metadata extraction
• Timestamped evidence
• Domain-to-screenshot association
• Visual comparison between domains

Browser automation should run in an isolated environment with appropriate restrictions for untrusted content.

Provide interoperable exports for graph-oriented investigation tools.

Potential formats and capabilities:

• Node-and-edge JSON
• CSV edge lists
• GraphML
• Relationship provenance
• Confidence and evidence annotations
• Exportable investigation subgraphs
• Pivotable IOC and infrastructure entities

• Historical BGP change correlation
• Time-based infrastructure relationship graphs
• TLS certificate and certificate-transparency pivots
• Domain-to-IP historical association analysis
• Autonomous-system relationship visualization
• Infrastructure change detection
• Cluster evolution over time
• Cross-source IOC deduplication
• Investigation case exports
• Automated candidate prioritization
• Reproducible enrichment snapshots
• Additional passive DNS and public intelligence sources
• SIEM integration

These are proposed extensions and should not be interpreted as already implemented functionality.

• Threat Intelligence Analysts
• Threat Hunters
• Malware Researchers
• Incident Responders
• Network Security Engineers
• Infrastructure Investigators
• Detection Engineers
• Cybersecurity Researchers
• Digital Forensics Analysts
• Academic Security Research

Traditional IOC investigation often starts with a known indicator and stops when its direct enrichment is exhausted.

Waypoint explores what happens when the investigation continues outward.

A known indicator is not the boundary of an investigation.

It is the starting point.

Infrastructure relationships can expose new candidates. Multi-vantage routing observations can reveal shared network entities. Local correlation can turn existing evidence into additional investigative leads.

The objective is not to claim attribution from shared infrastructure.

It is to discover relationships worth validating, preserve the evidence behind them, and help analysts investigate beyond the original feed.

Waypoint is an infrastructure intelligence and candidate-discovery platform.

• Shared ASNs do not establish shared malicious ownership.
• Shared hosting does not establish campaign attribution.
• Traceroutes reveal responding hops, not a complete physical network path.
• Fast-flux and DGA scores are heuristics, not verdicts.
• Infrastructure clusters represent derived relationships that require validation.
• Offline discovery is limited to the relationships supported by collected data.

The platform is intended to prioritize investigation and generate evidence-backed hypotheses for further analysis.

Waypoint aims to move threat intelligence beyond static indicators toward a continuously enriched, infrastructure-oriented investigation model.

IOC Intelligence
      |
      v
Network Infrastructure
      |
      v
Routing Relationships
      |
      v
Cross-Vantage Correlation
      |
      v
Infrastructure Discovery
      |
      v
Campaign Hypotheses
      |
      v
Evidence-Based Validation

Don't just enrich the IOC. Investigate the infrastructure around it.

Don't just consume threat feeds. Discover what their indicators connect to.

Don't confuse correlation with attribution. Use infrastructure evidence to find the next question.

Interactive Binary Intelligence Platform
Reverse Engineering • Call Graph Analysis • Vulnerability Discovery • API Correlation • Graph Exploration

Binary Atlas is an interactive reverse engineering and vulnerability research platform that transforms raw binaries into an explorable intelligence graph.

Instead of manually navigating thousands of functions inside a disassembler, Binary Atlas builds a searchable knowledge graph linking:

• Functions
• Imports
• API usage
• Wrappers & thunks
• Call relationships
• Security-relevant behaviors
• Clusters
• Risk indicators
• Cross references
• Semantic categories

The result is a system that allows researchers to move from:

Binary
   ↓
Disassembly
   ↓
Function Graph
   ↓
Behavior Graph
   ↓
Vulnerability Discovery

Explore thousands of functions in real time.

• Function-to-function call relationships
• Import ownership mapping
• Recursive traversal
• Path finding
• Connected component exploration
• Entry point discovery
• Cluster visualization

QuarantineLocation
      ↓
MoveFileWrapper
      ↓
MoveFileExW

Instead of hunting through hundreds of disassembly windows, the relationship is visible immediately.

Binary Atlas automatically categorizes APIs into behavioral groups.

Examples:

• CreateFileW
• DeleteFileW
• MoveFileExW
• CopyFileExW
• ReadFile
• WriteFile

• RegOpenKeyExW
• RegSetValueExW
• RegDeleteKeyW

• WinHttpOpen
• WinHttpConnect
• WinHttpSendRequest

• CreateThread
• Sleep
• ExitThread

• CreateMutexW
• SetEvent
• WaitForSingleObject

• IsDebuggerPresent
• QueryPerformanceCounter
• GetTickCount
• OutputDebugStringW

Binary Atlas automatically highlights suspicious behaviors.

Examples:

• Anti-debugging
• Security checks
• Fail-fast logic
• Exception-heavy routines
• Bitwise-heavy code
• Guard logic
• Wrapper functions
• Process interaction
• File-system modification chains

Automatically discovers:

Function
      ↓
Wrapper
      ↓
Import

Examples:

QuarantineLocation
      ↓
MoveFileWrapper
      ↓
MoveFileExW

This is extremely useful when analyzing:

• Malware
• EDRs
• AV engines
• Windows services
• Enterprise software

where API calls are often hidden behind dozens of wrappers.

Functions are grouped based on observed behavior.

Example clusters:

Filesystem
Networking
Registry
Crypto
Memory
Threading
Synchronization
Injection
Anti-Analysis
Execution

Rather than viewing 1,000+ isolated functions, analysts can navigate the binary at a subsystem level.

Binary Atlas assists vulnerability research by automatically identifying:

Lock
 ↓
Release
 ↓
Shared Object
 ↓
Reacquire

Check
 ↓
Use

• MoveFileExW
• DeleteFileW
• CreateFileW

without:

• GetFinalPathNameByHandleW
• PathFileExistsW
• Validation routines

• HeapFree
• VirtualProtect
• HeapReAlloc
• FreeLibrary

• OpenProcess
• ReadProcessMemory
• CreateProcessAsUserW

Instantly pivot between:

Import
 ↓
Wrapper
 ↓
Caller
 ↓
Caller of Caller

Find:

• Who calls this?
• What does it call?
• Where does data originate?
• Which subsystem owns it?

Every analysis exports to SQLite.

Researchers can perform custom investigations:

SELECT *
FROM instruction_refs
WHERE target_name='MoveFileExW';

SELECT *
FROM functions
WHERE risk_score > 80;

SELECT *
FROM edges
WHERE type='call';

Perfect for:

• Research
• Automation
• Reporting
• CI pipelines
• Large-scale binary comparison

Ask questions such as:

Show every path leading to MoveFileExW

Show all WinHTTP consumers

Find registry write chains

Show thread creation entry points

Find all anti-analysis functions

Find file operations lacking validation

Binary Atlas provides immediate visibility into:

• Functions
• Imports
• Exports
• Sections
• Clusters
• Graph density
• Security indicators
• Risk score
• API ownership
• Call relationships

without requiring users to manually traverse thousands of nodes.

• Reverse Engineers
• Malware Analysts
• Vulnerability Researchers
• Security Engineers
• Detection Engineers
• Incident Responders
• Threat Hunters
• Red Team Operators
• Software Security Researchers

Traditional workflows separate:

Disassembler

Debugger

Decompiler

Database

Notes

Graphs

Binary Atlas aims to unify them into a single intelligence platform.

Future directions include:

• Dynamic execution correlation
• Time-travel debugging integration
• Runtime call graph augmentation
• Taint analysis
• Symbolic execution
• Automatic exploit path discovery
• AI-assisted vulnerability triage
• Graph-based patch analysis
• Binary diffing
• Cross-version behavioral comparison

Stop reading binaries one function at a time.

Start exploring them as systems.

Dynamic Binary Intelligence & Execution Tracing Platform
Runtime Analysis • API Tracing • Caller Attribution • Resource Lifecycle Analysis • IPC • Security Context • BinaryAtlas Integration

Binary Mirror is a dynamic execution intelligence platform built around radare2 that transforms live binary behavior into an interactive, temporally correlated investigation environment.

Instead of relying exclusively on static disassembly, Binary Mirror observes what happens when a program actually executes.

It can launch a target from a cold start or attach to an existing process, tracing observed function activity across executable modules, nested DLLs, operating-system APIs, and supported process boundaries.

Binary Mirror correlates:

• Function execution events
• Timestamps and wall-clock time
• Function arguments and return values
• Immediate callers and cross-module relationships
• Thread activity and execution timelines
• Runtime addresses and loaded modules
• Resource creation, usage, and release
• Handle lifecycle anomalies
• Token and security-related API activity
• Process communication and IPC relationships
• Register state at captured events
• Function invocation statistics
• Temporal relationships between events
• Static-analysis findings from BinaryAtlas

The result is a platform for investigating how software behaves at runtime, which functions are actually exercised, what arguments they receive, and how execution moves through the underlying system.

             Target Binary
                  |
                  v
         Dynamic Instrumentation
                  |
                  v
          Function Execution
                  |
         +--------+--------+
         |        |        |
         v        v        v
       Calls    Threads   Arguments
         |        |        |
         +--------+--------+
                  |
                  v
          Temporal Correlation
                  |
         +--------+---------+
         |        |         |
         v        v         v
      Resource  Security    IPC
      Lifecycles Context    Graph
         |        |         |
         +--------+---------+
                  |
                  v
       Runtime Investigation
                  |
                  v
        BinaryAtlas Correlation

Binary Mirror records observed function executions and exposes their runtime context.

Captured event information can include:

• Relative timestamps
• Wall-clock timestamps
• Process and thread IDs
• Function names and addresses
• Module ownership
• Immediate caller attribution
• Captured function arguments
• Return values
• Observed execution duration
• Register state
• Previous and next events on the same thread
• Temporally neighboring events across threads

Example:

Time (s)    Thread    Function
------------------------------------------------
299.672323  20772     KERNELBASE.dll!RegOpenKeyExInternalW
299.526614  20772     KERNELBASE.dll!RegOpenKeyExW
299.231766  20772     ntdll.dll!RtlDisownModuleHeapAllocation

Select an event to inspect its arguments, return value, caller, registers, module, and surrounding execution activity.

The goal is to make individual runtime events navigable evidence rather than isolated log entries.

The live timeline provides a temporal view of observed function activity.

Features include:

• Function-level event visualization
• Time-axis zooming and navigation
• Event inspection
• Thread-aware execution analysis
• Temporal neighborhood exploration
• Module-boundary visualization
• Event-to-detail navigation
• Correlation between timeline events and function statistics

Rather than reading thousands of log lines sequentially, investigators can identify activity patterns and jump directly to interesting execution points.

Time ----------------------------------------------------->

Thread A   [API]---[API]------[ALLOC]---[CLOSE]----[API]
Thread B        [TOKEN]----------[IPC]--------[API]
Thread C   [MODULE LOAD]-------------------[ALLOC]

                     |
                     v
              Inspect Event
                     |
          +----------+----------+
          |          |          |
          v          v          v
        Caller     Arguments   Registers

Temporal proximity is used to help discover relationships. Events close together in time are not automatically assumed to be causally related.

One of Binary Mirror's primary goals is identifying which functions trigger lower-level APIs during an actual execution.

A program may invoke a high-level operation that passes through several libraries before reaching a Windows API.

Application
     |
     v
Application Wrapper
     |
     v
Windows Component
     |
     v
KERNELBASE.dll
     |
     v
ntdll.dll
     |
     v
Operating System Boundary

Binary Mirror helps investigate these paths using observed callers and module attribution.

Capabilities include:

• Immediate caller inspection
• Cross-module caller relationships
• Function-level caller statistics
• Caller graph navigation
• API invocation counts
• Function-to-module attribution
• Runtime address inspection
• Cross-reference investigation
• High-frequency caller identification

This is especially useful when a function in a deeply nested DLL is triggered indirectly through multiple wrappers.

Where caller resolution and capture coverage permit, investigators can work backward from an observed API toward the code that invoked it.

Windows applications frequently rely on extensive chains of system libraries.

Binary Mirror helps identify which instrumented functions were observed inside these modules during a particular execution.

Example modules include:

Taskmgr.exe
ntdll.dll
KERNEL32.dll
KERNELBASE.dll
ucrtbase.dll
ADVAPI32.dll
USER32.dll
RPCRT4.dll
SHCORE.dll
Windows.Storage.dll
dnsapi.dll

Investigations can focus on:

• Registry access
• File-system operations
• Dynamic module loading
• Memory allocation
• Heap management
• Process and thread operations
• Security-token APIs
• Networking-related APIs
• Inter-process communication
• Synchronization and handle management

The key question is no longer simply whether an API exists in the binary.

It becomes:

Which function invoked it, what arguments were observed, on which thread did it execute, and what happened around that event?

Binary Mirror aggregates observed execution activity into function-level statistics.

Example:

Function: KERNELBASE.dll!GetProcAddress

Calls:              340
First observed:     0.135871s
Last observed:      284.043031s
Mean call gap:      0.8375s

Top callers:
    ucrtbase.dll+0x91f2       x24
    ucrtbase.dll+0xb3955      x6
    combase.dll+0x17bebf      x4
    combase.dll+0x3a0d7       x4

Statistics can include:

• Total call count
• First and last occurrence
• Mean interval between calls
• Total observed execution time
• Thread distribution
• Top callers
• Argument diversity
• Individual occurrences with captured arguments

This makes it easier to identify repeatedly invoked APIs, unusual call patterns, and functions that warrant closer investigation.

Binary Mirror includes resource lifecycle analysis intended to identify suspicious acquisition, use, and release patterns.

Depending on the enabled capture options and supported resource types, it can expose candidate findings such as:

• Potential resource leaks
• Double-close candidates
• Double-free candidates
• Resource lifetime anomalies
• Unexpected release patterns
• Allocation and memory-pressure indicators
• Potential out-of-memory-related behavior

Example:

Resource Lifecycle

Handle      Type          State
-----------------------------------------------
0xfc#0      RegistryKey   LEAK_CANDIDATE
0xfc#1      RegistryKey   DOUBLE_CLOSED

Additional evidence may include:

Resource Type: RegistryKey

Created by:
    KERNELBASE.dll!RegOpenKeyExInternalW

State:
    DOUBLE_CLOSED

Evidence:
    DOUBLE_CLOSE_CANDIDATE

Observed lifetime:
    0.457 seconds

The lifecycle view helps connect a resource anomaly to the functions that created, used, or released the resource.

Some lifecycle analysis requires return-value capture, such as --capture-returns.

A candidate is not automatically a confirmed vulnerability.

A resource that remains open at the end of a trace may have been intentionally retained. Handle reuse, incomplete capture, and API-specific semantics can also affect lifecycle interpretation.

Double-free, memory-exhaustion, and related findings require suitable evidence and validation. Binary Mirror is designed to surface and investigate suspicious behavior rather than declare every candidate exploitable.

Memory-management APIs can expose useful evidence about allocation patterns, object lifetimes, and potential defects.

Binary Mirror can help investigators examine observed memory-related calls and their surrounding execution context.

Example APIs and operations of interest include:

HeapAlloc
HeapFree
HeapReAlloc
VirtualAlloc
VirtualFree
VirtualProtect
RtlAllocateHeap
RtlFreeHeap
RtlDisownModuleHeapAllocation

Potential investigative targets include:

• Unexpected allocation sizes
• Repeated allocation and release patterns
• Suspiciously large allocation requests
• Potential double frees
• Resource ownership inconsistencies
• Heap-related failures
• Allocation pressure and possible OOM behavior
• Calls occurring across multiple threads

Example event:

Function:
    ntdll.dll!RtlDisownModuleHeapAllocation

Argument:
    dwBytes = 0x7ffffffffffffffc

Thread:
    20772

Caller:
    Windows.Storage.dll+0xf771e

The value and function name provide an investigation lead, not proof of a successful allocation, a memory corruption vulnerability, or an out-of-memory condition. Interpretation depends on the function's actual semantics, argument capture, and surrounding evidence.

Binary Mirror provides complementary views of process security context and observed token-related API activity.

Where token probing is enabled, observations may include:

• User identity
• Process ID
• Session
• Integrity level
• Elevation type
• Elevated versus limited token state
• Observation timestamps

Example:

PID:        15656
Integrity:  Medium
Elevation:  Limited
Elevated:   false

Evidence:
    OBSERVED_TOKEN_STATE

Binary Mirror can also identify functions that perform token-related operations.

Example:

Time (s)    Thread    Function
------------------------------------------------
11.908186   13964     ntdll.dll!NtOpenThreadToken
12.570023   13964     ntdll.dll!NtOpenThreadToken
28.606842   13964     ntdll.dll!NtOpenThreadToken
28.967497   13964     ntdll.dll!NtOpenThreadToken

Event details can expose:

• Requested access masks
• Thread handles
• Token handles
• OpenAsSelf values
• Calling functions
• Thread distribution
• Return values
• Argument diversity

This helps answer questions such as:

• Which functions initiate token-related operations?
• Which threads repeatedly request token access?
• What access masks are being requested?
• Which callers should be investigated further?
• What security-related activity occurred around a suspicious event?

A token API call does not by itself establish privilege escalation.

Binary Mirror separates observed process-token state from traced token-related function activity. These sources can be correlated by time, but the tool should not infer a privilege transition without supporting evidence.

The objective is to help identify the actual functions participating in security-sensitive behavior, rather than merely reporting the final privilege state of a process.

Modern Windows applications rely on multiple communication mechanisms, including COM and ALPC.

Binary Mirror can visualize relationships derived from collected IPC events and link graph relationships back to their underlying event evidence.

The IPC investigation view helps explore:

• Observed communication entities
• COM-related activity
• ALPC activity
• Relationships between components
• Underlying calls associated with graph edges
• Temporal correlation with function execution
• Cross-component behavior

Example:

IPC Investigation

PID: 15656

ALPC events: 12
COM events:   1
Total:       13

IPC relationships can help identify interactions that are not obvious from the primary executable or a conventional process tree.

The graph represents relationships supported by collected events; it should not be treated as a complete inventory of every communication channel unless capture coverage establishes that completeness.

Binary Mirror maintains a module-oriented view of observed execution.

Example:

Module          Base Address       Size (KB)
------------------------------------------------
Taskmgr.exe     0x7ff761d30000     5614.5
ntdll.dll       0x7ffe07d40000     2463
KERNEL32.dll    0x7ffe05ab0000     824.7
KERNELBASE.dll  0x7ffe05090000     4113.4
ucrtbase.dll    0x7ffe05630000     1345.2
ADVAPI32.dll    0x7ffe062f0000     760.1

Module information can include:

• Loaded module names
• Runtime base addresses
• Image sizes
• First-seen timestamps
• Module paths
• Associated function activity
• Observed API usage

This helps investigators determine where runtime activity occurs and navigate between the executable, supporting libraries, and lower-level Windows components.

Binary Mirror organizes observed activity by thread and provides temporal context for investigating concurrent behavior.

Capabilities include:

• Per-thread execution lanes
• Thread-specific event navigation
• Function invocation counts by thread
• Cross-thread temporal neighborhoods
• Resource access correlation
• Overlapping-access candidates

Example:

Thread 13964    [API]----[TOKEN]----[API]--------[CLOSE]

Thread 15516          [ALLOC]------[API]----[RESOURCE]

Thread 20772     [REGISTRY]----[API]----[CLOSE]

Where sufficient resource and timing information is available, Binary Mirror can identify overlapping accesses to shared resources across threads.

These candidates can help prioritize investigation into:

• Possible race conditions
• Synchronization defects
• Resource lifetime inconsistencies
• Concurrent handle operations

Temporal overlap alone does not prove a race condition. Confirming a race requires understanding shared state, synchronization, ordering, and the relevant execution semantics.

Binary Mirror is designed for two primary investigation workflows.

Launch a target under observation to capture behavior from the beginning of the recorded execution.

Useful for examining:

• Initialization routines
• Startup-time API calls
• DLL loading
• Early resource acquisition
• Initial security-related operations
• Process and thread creation

Attach to a running target to investigate behavior during a particular operational phase.

Useful for:

• Long-running applications
• Background processes
• Windows services, where supported
• Delayed behavior
• Nested DLL activity
• Runtime troubleshooting

Attaching after startup does not recover earlier events that were not captured.

Actual coverage depends on the tracing backend, permissions, target architecture, instrumentation boundaries, and available symbols.

Binary Mirror is designed to complement BinaryAtlas, the static binary intelligence platform.

BinaryAtlas builds an explorable representation of functions, imports, call relationships, and security-relevant patterns.

Binary Mirror adds the runtime perspective: which instrumented functions were observed, when they executed, who called them, and what arguments were captured.

Together, they support a workflow that combines static hypotheses with dynamic evidence.

                 BinaryAtlas
              Static Intelligence
                      |
                      v
             Functions & Call Graph
                      |
                      v
             Identify Investigation
                   Targets
                      |
                      v
                Binary Mirror
              Dynamic Execution
                      |
          +-----------+-----------+
          |           |           |
          v           v           v
       Arguments   Callers      Timing
          |           |           |
          +-----------+-----------+
                      |
                      v
             Runtime Evidence
                      |
                      v
            Focused Investigation

1. Identify a suspicious function or call path in BinaryAtlas.
2. Launch or attach to the target with Binary Mirror.
3. Observe the function's runtime activity and captured arguments.
4. Identify the functions that invoke the relevant APIs.
5. Investigate repeated calls, resource lifecycle anomalies, and security-related activity.
6. Return to static analysis to inspect the responsible implementation and surrounding code.

This helps reduce the search space in large binaries and complex Windows dependency trees.

The integration is intended to complement static analysis, not replace it. Runtime traces describe observed executions and cannot establish that unobserved paths are unreachable.

Binary Mirror is built around radare2 and is designed to complement a broader reverse-engineering toolchain.

Integration availability depends on the implementation and target environment. These tools have distinct roles and are not necessarily enabled in every Binary Mirror configuration.

• Reverse Engineers
• Malware Analysts
• Vulnerability Researchers
• Windows Internals Researchers
• Security Engineers
• Detection Engineers
• Incident Responders
• Threat Hunters
• Software Security Researchers
• Systems Programmers
• Dynamic Analysis Researchers

Traditional reverse-engineering workflows often separate:

Static Analyzer
      |
      v
Disassembler
      |
      v
Debugger
      |
      v
API Monitor
      |
      v
Execution Logs
      |
      v
Call Graph
      |
      v
Investigation Notes

Binary Mirror aims to bring these perspectives closer together through a unified runtime investigation environment.

Potential future directions include:

• Deeper BinaryAtlas runtime correlation
• Expanded API and caller attribution
• Enhanced resource ownership analysis
• More comprehensive memory-lifecycle instrumentation
• Trace comparison across executions
• Improved IPC relationship analysis
• Additional symbolic execution workflows
• Dynamic taint-analysis integration
• More extensive concurrency investigation
• Reproducible evidence export
• Cross-version behavioral comparison
• Automated investigation prioritization

Static analysis shows you what a binary could do.

Dynamic analysis shows you what happened during an observed execution.

Binary Mirror connects the event to its arguments, caller, timing, and surrounding system behavior.

Don't just find the API. Find the execution path that triggered it.

Don't just inspect the process. Investigate the functions behind its behavior.

Don't stop at the trace. Turn runtime evidence into deeper binary intelligence.

BinaryAtlas — Interactive Binary Intelligence Platform

https://github.com/400lbhacker/BinaryAtlas

🧬 Neuroevolution for Procedural 3D Generation
HyperNEAT • CPPNs • Genetic Algorithms • Evolutionary Design • Interactive Mesh Synthesis

Nightingale 3D Engine is an experimental evolutionary modeling platform that treats 3D objects as genomes instead of static meshes.

Rather than sculpting vertices manually, objects are generated and evolved through HyperNEAT, Compositional Pattern Producing Networks (CPPNs), and genetic algorithms, allowing entirely new forms to emerge through mutation, crossover, and procedural growth.

Instead of asking:

"How do I model this?"

the engine asks:

"How could this evolve?"

Every object becomes an organism with inheritable traits, enabling procedural evolution instead of traditional mesh editing.

Generate geometry from neural networks instead of handcrafted meshes.

Features include:

• CPPN-based implicit geometry generation
• HyperNEAT substrate evaluation
• Continuous procedural shape generation
• Infinite variation without manually editing vertices
• Deterministic reproduction from genomes

Every generated model is reproducible from its genome.

Unlike conventional procedural generators that create one object at a time, Nightingale allows multiple organisms to breed together.

The engine supports:

• Multi-parent crossover
• Genome recombination
• Trait inheritance
• Regional feature blending
• Controlled diversity
• Evolutionary branching

A cactus can inherit characteristics from architecture.

A rocket can inherit characteristics from a tree.

Every generation produces new offspring instead of simple copies.

Every offspring can be procedurally mutated.

Mutation operators include:

• geometry perturbation
• recursive growth
• symmetry breaking
• complexity adjustment
• proportional scaling
• topology variation
• regional mutation
• genome noise injection

The result is an evolutionary search instead of random mesh distortion.

Every generation is preserved.

The engine records:

• parent relationships
• mutation history
• offspring lineage
• ancestry influence
• evolutionary branches

Objects become part of an evolving phylogenetic tree rather than isolated assets.

Instead of treating an object as one monolithic mesh, Nightingale automatically partitions geometry into functional regions.

Each region maintains independent metadata:

• surface area
• curvature
• confidence
• topology
• symmetry
• volume contribution

Individual regions can then be:

• mutated
• frozen
• hybridized
• grafted
• protected
• evolved independently

This enables localized evolution rather than mutating an entire object.

One of the engine's experimental features is regional transplantation.

Entire anatomical regions can be copied between unrelated models.

Examples include:

• transplant tree branches onto machinery
• attach gothic architecture onto organisms
• merge cactus ribs into sculptures
• splice biological structures into vehicles

This creates hybrids that traditional mesh interpolation cannot produce.

Geometry and appearance evolve independently.

Procedural texture generation includes:

• CPPN-generated textures
• neural color fields
• procedural gradients
• psychedelic patterns
• circuit textures
• crystalline materials
• biological pigmentation
• parameterized frequency
• warp controls

Textures remain procedural rather than bitmap-based.

Morphological changes can be layered using procedural operators.

Available transformation families include:

• Ribbing
• Tendrils
• Apertures
• Skeletonization
• Vascularization

• Circuit traces
• Panelization
• Mechanical joints
• Modular plating
• Vent systems

• Arches
• Trusses
• Support beams
• Lattice reinforcement
• Load paths

• Organic vines
• Floral motifs
• Spirals
• Flowing ribs
• Whiplash curves

• Flying buttresses
• Rose windows
• Rib vaults
• Spires
• Tracery

• Cellular
• Gyroid
• Bubble structures
• Crystallization
• Faceting
• Fragmentation
• Inflation
• Low-poly conversion
• Voxelization

Each modifier is evolutionary rather than destructive.

Every organism exposes its underlying genetic state.

Metadata includes:

• active genome
• evolutionary generation
• genome influence
• ancestry weights
• complexity
• symmetry
• recursion
• organicity
• mechanical bias

Rather than editing meshes, users manipulate genomes.

The interface includes:

• live OpenGL viewport
• generation browser
• mutation grid
• offspring comparison
• ancestry graph
• region explorer
• feature graph
• evolutionary timeline
• procedural texture preview
• segmentation inspector

Everything updates interactively during evolution.

Supported workflows include:

• OBJ export
• PNG rendering
• project serialization
• genome persistence
• evolutionary replay
• procedural regeneration

Entire evolutionary histories can be saved and revisited.

The long-term vision extends beyond procedural art.

Planned capabilities include:

• Neural implicit surfaces
• Signed Distance Function evolution
• differentiable evolution
• AI-guided fitness evaluation
• CLIP-assisted evolutionary search
• automatic phenotype classification
• topology-aware crossover
• procedural rig generation
• physics-aware fitness functions
• biomechanical evolution
• architectural optimization
• robotics morphology search
• generative manufacturing pipelines

Ultimately, Nightingale explores what happens when computer graphics, evolutionary computation, artificial life, and procedural modeling converge into a single creative system.

• Python
• HyperNEAT
• CPPNs
• Genetic Algorithms
• Flask
• Three.js
• OpenGL
• NumPy
• Procedural Geometry
• Signed Distance Fields (experimental)
• Marching Cubes
• OBJ Pipeline
• Hugging Face Spaces

Traditional CAD software asks the designer to build every vertex manually.

Nightingale instead defines a set of evolutionary rules and allows entirely new forms to emerge through mutation, inheritance, and natural selection.

It is less a modeling program than an experimental laboratory for evolving digital organisms.

An interactive RNA secondary structure platform for visualization, analysis, mutation, and AI-assisted interpretation.
RNA folding • Structural visualization • Motif discovery • Mutation simulation • Long RNA support

RNAverse is an interactive RNA secondary structure platform built to make RNA folding intuitive, explorable, and biologically meaningful.

Most RNA software either produces beautiful static figures or powerful command-line output—but rarely both. RNAverse combines the predictive power of the ViennaRNA toolkit with an interactive web interface that allows users to explore RNA structures at nucleotide resolution, inspect motifs, simulate mutations, and investigate structural stability in real time.

Whether you're studying microRNAs, viral genomes, tRNAs, long non-coding RNAs, or synthetic constructs, RNAverse provides a visual environment for understanding how sequence becomes structure.

RNAverse automatically selects the most appropriate folding algorithm based on sequence length.

For conventional RNA molecules:

• ViennaRNA RNAfold
• Minimum Free Energy (MFE) prediction
• Thermodynamic optimization

For extremely large RNAs:

• RNAplfold
• Sliding-window folding
• Local pairing probabilities
• Long transcript support

Automatic fallback chain:

RNAplfold
      ↓
RNAfold
      ↓
Internal topology-aware layout engine

allowing everything from small miRNAs to complete viral genomes to be analyzed seamlessly.

Rather than rendering RNA as static SVG figures, RNAverse represents every nucleotide as a fully interactive graph.

Features include

• nucleotide-level precision
• zoomable graph visualization
• draggable layouts
• backbone visualization
• base-pair visualization
• publication-quality rendering

The visualization remains responsive even for very large RNA molecules.

RNAverse directly integrates RNAplot to generate biologically realistic layouts.

Pipeline:

Sequence
      ↓
Dot-Bracket Structure
      ↓
RNAplot
      ↓
2D Coordinates
      ↓
Interactive Graph

When RNAplot is unavailable, an internal layout engine reconstructs the secondary structure while preserving stem-loop topology.

RNAverse automatically detects and labels major structural elements.

Including

• Hairpins
• Internal loops
• Bulges
• Multibranch junctions
• Stem regions
• Terminal loops
• Variable loops
• Acceptor stems
• Anticodon stems
• T-arms
• D-arms

allowing complex RNAs to be understood at a glance.

Rather than simply showing paired nucleotides, RNAverse understands biological organization.

Automatically identifies

• 5' regions
• 3' regions
• Stem boundaries
• Loop boundaries
• Consecutive stacking interactions
• Functional domains

Each region receives independent visual styling for rapid interpretation.

RNAverse supports visualization of complex RNA architectures that many traditional viewers cannot display naturally.

Examples include

• mature miRNA within pre-miRNA
• overlapping ncRNAs
• nested transcripts
• precursor structures
• multiple RNA annotations

making the platform particularly useful for non-coding RNA research.

RNAverse automatically extracts structural motifs from folded RNAs.

Current motif detection includes

• stem discovery
• stem length
• stem sequence extraction
• hairpin loops
• internal loops
• multiloops
• pseudoknot placeholders
• pairing statistics

forming the basis for future automated motif discovery pipelines.

One of RNAverse's most powerful capabilities is real-time mutation analysis.

Mutating any nucleotide immediately updates

• sequence
• predicted folding
• Minimum Free Energy
• pairing interactions
• secondary structure
• structural statistics

allowing researchers to rapidly explore sequence-function relationships.

Mutation history records

• original nucleotide
• mutated nucleotide
• position
• ΔG change
• structural impact

Every analysis automatically generates quantitative metrics including

• sequence length
• GC content
• paired fraction
• stem count
• loop count
• MFE
• prediction algorithm
• nucleotide composition

providing immediate structural summaries without external scripts.

RNAverse includes an optional AI layer for biological interpretation.

Using a lightweight background-loaded language model, users can ask natural-language questions such as

Is this RNA stable?

Show all hairpin loops.

What happens if I mutate position 42?

Explain this stem-loop.

Why is this region unstable?

The assistant combines folding statistics, motif extraction, and structural metadata to generate context-aware explanations while gracefully falling back to deterministic responses if the model is unavailable.

RNAverse is designed to integrate with downstream RNA analysis workflows.

Supported exports include

• Dot-Bracket notation
• FASTA
• BPSEQ
• Coordinate layouts
• Structural statistics
• Motif summaries

making interoperability straightforward with existing RNA bioinformatics tools.

Explore

• miRNA
• pre-miRNA
• lncRNA
• snoRNA
• snRNA
• ribozymes
• synthetic RNAs

with interactive visualization.

Long-sequence support enables structural exploration of

• SARS-CoV-2
• Zika Virus
• Dengue
• Influenza
• other RNA viruses

without requiring manual segmentation.

RNAverse highlights

• conserved stems
• exposed loops
• functional domains
• structural motifs

that may represent potential targets for

• antisense oligonucleotides
• aptamers
• RNA-binding proteins
• small-molecule therapeutics

Rapid mutation simulation makes RNAverse useful for

• riboswitch engineering
• aptamer design
• guide RNA optimization
• synthetic transcript design
• educational folding experiments

RNA secondary structure can be difficult to teach using static diagrams.

RNAverse allows students to

• mutate sequences
• observe structural collapse
• compare folding algorithms
• identify motifs
• understand thermodynamic stability

through interactive exploration.

• Python
• Flask
• ViennaRNA
• RNAfold
• RNAplfold
• RNAplot
• D3.js
• HTML5 Canvas
• TinyLlama (optional AI)
• Hugging Face Spaces

RNAverse is intended to become a complete interactive RNA informatics platform.

Planned capabilities include

Beyond conventional secondary structures.

Visualize pairing confidence directly from partition function calculations.

Overlay multiple RNA structures to visualize evolutionary conservation.

Direct integration with

• Rfam
• miRBase
• RNAcentral
• Ensembl

Bridge secondary structure with

• PDB
• AlphaFold RNA
• Cryo-EM models

for multi-scale visualization.

Future models will answer questions such as

Which mutations preserve this hairpin?

Which loop is most evolutionarily conserved?

Identify likely protein-binding motifs.

Predict structurally tolerant mutations.

Compare this RNA against known ncRNA families.

RNAverse was built around a simple idea:

RNA should be explored—not merely folded.

Instead of generating another static secondary structure image, RNAverse transforms RNA into an interactive environment where every nucleotide, stem, loop, mutation, and structural relationship becomes immediately accessible. By combining established RNA folding algorithms with modern web visualization and AI-assisted interpretation, the goal is to lower the barrier between computational prediction and biological insight.

Whether you're investigating microRNAs, designing synthetic RNAs, studying viral genomes, or teaching RNA biology, RNAverse aims to make RNA structure as interactive and intuitive as genome browsers have made DNA.

"Every RNA tells a story. RNAverse lets you explore it nucleotide by nucleotide."

An interactive comparative genomics platform for exploring the Carnegiea gigantea genome.
Genome browser • BLAST annotations • RNA visualization • DuckDB analytics • Hugging Face deployment

SaguaroScope is a high-performance interactive genome browser built specifically for the Saguaro cactus (Carnegiea gigantea).

The original genome assembly was publicly released, but no modern web platform existed for exploring it interactively. SaguaroScope was built from scratch to bridge that gap—combining genome visualization, sequence retrieval, BLAST annotation, comparative genomics, and interactive RNA analysis into a single web application.

Rather than functioning as a static annotation browser, SaguaroScope is designed as an exploratory research environment where genomic structure, functional annotation, and comparative biology can all be investigated in real time.

Navigate entire chromosomes/scaffolds with fluid pan-and-zoom rendering.

• GPU-friendly D3.js visualization
• Multi-level zoom
• Whole-genome minimap
• Smooth navigation across millions of bases
• Instant jumping to coordinates

Every genomic feature is rendered as its own visually distinct layer.

Supports:

• Genes
• mRNA
• CDS
• Exons
• Pseudogenes
• miRNA
• snoRNA
• snRNA
• tRNA
• rRNA
• Riboswitches
• Transposable Elements
  • LTR Retrotransposons
  • Non-LTR Retrotransposons
  • TIR Elements
  • Helitrons
  • Unknown repeats

Thousands of annotations remain responsive even while navigating large genomic regions.

Search by traditional identifiers:

• Gene IDs
• Transcript IDs
• Scaffold coordinates

or biologically meaningful annotation:

• Protein descriptions
• Species names
• Functional keywords

Examples:

Cytochrome P450

Lophophora williamsii

CAM

Heat Shock Protein

Aquaporin

making comparative genomics dramatically easier.

Every predicted gene was automatically annotated using large-scale BLAST analysis.

Each feature exposes:

• Best protein match
• Species
• Percent identity
• Bit score
• E-value
• Description

allowing rapid cross-species exploration without manually running BLAST searches.

SaguaroScope automatically identifies genomic relationships including

• Sense overlap
• Antisense overlap
• Nearby neighbors
• Intergenic regions

Relationships appear as interactive arcs directly inside the genome browser and remain clickable for rapid navigation.

Clicking any feature immediately opens a detailed inspection panel containing

• Coordinates
• Strand
• Feature type
• Length
• GC%
• Annotation source
• Protein description
• Percent identity
• E-value
• Bit score

allowing detailed biological inspection without leaving the browser.

Every annotated feature can be converted directly into nucleotide sequence.

Features include

• Automatic reverse complement handling
• Copy sequence
• FASTA download
• Instant retrieval from indexed genomes

without loading the full genome into memory.

Large plant genomes quickly become difficult to browse using conventional web technologies.

SaguaroScope instead uses

• DuckDB analytical queries
• bgzip compressed FASTA
• HTSlib indexing (.fai / .gzi)
• Lazy sequence retrieval

allowing gigabase-scale genomes to remain highly responsive.

Beyond genomic browsing, SaguaroScope includes an experimental RNA exploration interface.

Capabilities include

• RNA sequence visualization
• Live mutation
• Structural exploration
• Rapid iteration for transcript analysis

designed for future RNA folding and secondary-structure workflows.

Designed around analytical rather than transactional databases.

Instead of SQLite or PostgreSQL, SaguaroScope leverages DuckDB for high-performance genomic analytics.

Advantages include

• columnar execution
• vectorized SQL
• extremely fast aggregation
• low memory overhead
• excellent performance on large annotation datasets

making complex genomic searches feel nearly instantaneous.

SaguaroScope is intended to evolve beyond a traditional genome browser into a systems biology platform.

Planned additions include

Visual overlays for

• daytime genes
• nocturnal genes
• CAM photosynthesis regulation
• stomatal opening pathways
• circadian oscillators

allowing researchers to view genomic organization alongside temporal expression.

Overlay metabolic networks directly onto genomic regions.

Examples

• KEGG pathways
• Reactome pathways
• CAM photosynthesis
• Crassulacean Acid Metabolism enzymes
• Secondary metabolite synthesis
• Alkaloid biosynthesis
• Terpene biosynthesis

Future comparative datasets include

• Prickly Pear (Opuntia)
• Peyote (Lophophora)
• Dragon Fruit (Selenicereus)
• Barrel Cactus
• Agave

allowing evolutionary conservation to be explored directly within the browser.

Future automated annotation layers

• GO terms
• Pfam domains
• InterPro
• Conserved domains
• Ortholog clustering
• Gene family expansion
• Duplication events

Long-term plans include integrating LLM-assisted biological reasoning.

Examples

• "Show drought-related genes."

• "Find genes associated with CAM metabolism."

• "Locate all cytochrome P450 enzymes near terpene clusters."

• "Compare this scaffold against alkaloid-producing cactus species."

transforming the browser into an interactive genomic research assistant.

• Python
• Flask
• DuckDB
• D3.js
• NCBI BLAST
• HTSlib
• bgzip / FAI indexing
• HTML5 Canvas
• Hugging Face Spaces

SaguaroScope was created to make the Carnegiea gigantea genome genuinely explorable.

Rather than treating genome assemblies as static datasets hidden behind flat annotation files, the goal is to provide an environment where researchers, students, and enthusiasts can navigate genomic structure, discover functional relationships, inspect sequence-level detail, and build biological intuition through interactive visualization.

As additional annotations, pathway information, comparative genomes, and expression datasets become available, SaguaroScope is designed to grow into a comprehensive platform for cactus genomics and plant systems biology.

"If the data exists, it should be explorable."

Mutation Integration & Regulatory Analysis Genome Engine (MIRAGE) is an extensible multi-omics systems biology platform designed to reconstruct the complete regulatory landscape surrounding human genes and cancer genomes.

Rather than treating mutations as isolated events, MIRAGE models how genetic variation propagates through interconnected regulatory layers—including transcription factors, enhancers, DNA methylation, chromatin accessibility, non-coding RNAs, gene expression, and biological pathways—to generate mechanistic hypotheses about disease.

The platform transforms thousands of heterogeneous genomic datasets into an integrated regulatory graph capable of revealing upstream regulators, downstream consequences, network bottlenecks, and candidate driver mechanisms across cancer and complex disease.

MIRAGE is available both as a local Anaconda desktop environment for large-scale analyses and as a Google Colab edition for cloud-based execution without requiring local computational resources.

MIRAGE enables researchers to identify multi-layer regulatory vulnerabilities, prioritize candidate driver genes, characterize methylation-sensitive transcription factor networks, quantify regulatory disruption, and generate testable biological hypotheses from heterogeneous multi-omics datasets. Its modular architecture allows new genomic annotations, analytical methods, and machine learning models to be incorporated as the platform evolves.

By integrating diverse genomic data into a unified analytical ecosystem, MIRAGE seeks to bridge the gap between mutation catalogs and mechanistic understanding -providing researchers with a powerful framework for exploring the regulatory architecture of cancer and accelerating the discovery of clinically relevant biomarkers, therapeutic targets, and disease mechanisms.

As a systems biology platform designed to reconstruct the complete regulatory landscape surrounding any gene of interest. Rather than treating genes as isolated coding sequences, MIRAGE models them as dynamic nodes embedded within interconnected layers of transcriptional, epigenetic, post-transcriptional, and genomic regulation.

At its core, MIRAGE integrates diverse biological datasets into a unified regulatory graph. The engine combines experimentally validated and computationally predicted miRNA–mRNA interactions, lncRNA/circRNA ceRNA sponge networks, transcription factor binding sites, candidate cis-Regulatory Elements (cCREs), CpG islands, chromatin accessibility, gene expression, and somatic or germline mutation data. These relationships are synthesized into directed regulatory networks that identify upstream controllers, downstream effects, regulatory bottlenecks, and potential master regulators.

Unlike conventional annotation pipelines that simply report genomic features independently, MIRAGE performs cross-layer integration. For example, it can determine whether a disease-associated mutation falls within a transcription factor binding site located inside a CpG island that regulates a gene already targeted by multiple miRNAs and buffered by competing endogenous RNA (ceRNA) networks. This multi-dimensional context enables researchers to move beyond lists of annotations toward mechanistic hypotheses describing how regulatory disruptions may alter gene function.

The platform also includes analytical modules for ranking regulatory importance, identifying highly connected network hubs, predicting master regulatory switches, mapping tissue-specific expression profiles, detecting regulatory hotspots, and generating publication-quality regulatory graphs. As additional resources such as ClinVar, COSMIC, GWAS Catalog, JASPAR, HOCOMOCO, ENCODE, and GTEx are incorporated, MIRAGE becomes an increasingly comprehensive engine for interpreting both coding and non-coding genomic variation.

🔬 Core Capabilities 🧬 Multi-Omics Integration

Instead of analyzing one dataset at a time, MIRAGE combines multiple regulatory layers into a unified biological model.

Integrated resources include:

Somatic mutations Germline variants DNA methylation RNA expression miRNA expression Copy-number variation Chromatin accessibility Transcription factor binding Candidate cis-regulatory elements (cCREs) CpG islands Clinical metadata Tissue-specific expression

allowing every genomic feature to be interpreted within its surrounding regulatory context.

🧠 Regulatory Graph Reconstruction

Every queried gene becomes the center of an interconnected regulatory network.

MIRAGE reconstructs relationships including

miRNA → mRNA repression miRNA ↔ lncRNA sponge interactions ceRNA competition networks transcription factor regulation enhancer-promoter associations methylation-sensitive promoters chromatin accessibility mutation overlap with regulatory elements

instead of presenting disconnected annotation tables.

🎯 Mutation Context Engine

A mutation is never viewed in isolation.

MIRAGE determines whether variants occur inside

promoters enhancers transcription factor motifs CpG islands DNase hypersensitive regions miRNA target sites conserved regulatory elements

allowing researchers to evaluate functional regulatory disruption instead of genomic position alone.

🧬 Cancer Systems Biology

Built around TCGA Pan-Cancer Atlas datasets, MIRAGE enables large-scale analyses across thousands of patient tumors.

Supported analyses include

mutation frequency copy-number variation methylation RNA expression miRNA expression clinical outcome pathway enrichment regulatory network disruption 🌎 Environmental Carcinogenesis

A major focus of MIRAGE is understanding environmentally induced cancers.

The platform can investigate regulatory consequences associated with

alcohol-derived acetaldehyde tobacco smoke ultraviolet radiation oxidative DNA damage endogenous mutational processes

by connecting mutational signatures to altered transcriptional regulation and pathway activity.

📈 Biological Knowledge Integration

Rather than manually consulting dozens of independent databases, MIRAGE integrates them into a unified analytical framework.

Current resources include

Reference Genomes GRCh38 / hg38 GENCODE v46 UCSC Genome Browser Regulatory Annotation ENCODE cCRE Registry CpG Islands DNase I hypersensitive sites ENCODE TF ChIP-seq clusters Transcription Factors JASPAR CIS-BP HOCOMOCO

including complete PWM libraries and motif databases.

Non-Coding RNA

Integrated support for

miRBase miRTarBase ENCORI (starBase) TargetScan

covering experimentally validated and computationally predicted regulatory interactions.

Cancer Genomics

Pan-Cancer datasets include

TCGA MC3 mutations RNA-Seq DNA methylation SNP6 copy number clinical metadata miRNA expression Clinical & Population Genetics ClinVar GWAS Catalog GTEx Pathway Knowledge

Functional enrichment is supported through

KEGG Reactome Gene Ontology Hallmark Gene Sets (MSigDB) 📊 Systems-Level Analysis

MIRAGE performs higher-order biological analyses including

Regulatory network reconstruction Master regulator prediction Network hub ranking Regulatory hotspot detection Pathway enrichment Expression profiling Tissue specificity Multi-layer annotation scoring Candidate driver prioritization

instead of reporting isolated genomic annotations.

⚡ Modular Architecture

MIRAGE was designed as a modular framework rather than a fixed analysis pipeline.

New resources can be integrated with minimal effort, allowing future support for databases such as

COSMIC Open Targets DepMap AlphaMissense AlphaFold STRING BioGRID Human Protein Atlas

without requiring major architectural changes.

🚀 Platform Editions 💻 Desktop Edition

Designed for local high-performance analysis.

Windows Anaconda Jupyter large local datasets reproducible workflows ☁️ Google Colab Edition

Cloud-native execution requiring no local installation.

Ideal for

education rapid prototyping collaborative research publication notebooks 🧰 Technology Stack Python Pandas NumPy NetworkX Biopython SciPy Matplotlib Jupyter Google Colab Anaconda BEDTools htslib liftOver BLAST+ GTF/BED/VCF parsers 🎯 Long-Term Vision

MIRAGE aims to become a regulatory genome exploration engine that bridges molecular genetics, epigenomics, transcriptomics, and systems biology within a single computational ecosystem.

Rather than producing disconnected annotation tables, MIRAGE reconstructs how genomic variation propagates through regulatory networks to influence cellular behavior—transforming large-scale sequencing datasets into interpretable biological mechanisms, candidate therapeutic targets, and testable scientific hypotheses.

The long-term objective is to provide researchers with a scalable platform for exploring the regulatory architecture of human disease, accelerating biomarker discovery, precision oncology, and mechanistic cancer research.

Native Windows provisioning for radare2's r2ghidra and r2dec decompilers.

Automates the installation, compilation, configuration, and verification of a complete radare2 decompilation environment on Windows. r2di.ps1 — PowerShell installer 📜 View r2di.ps1

r2di (radare2 Decompiler Installer) is a self-contained PowerShell provisioning script designed to make installing r2ghidra and r2dec on native Windows dramatically easier.

The goal is simple:

Turn a clean Windows reverse-engineering workstation into a functional radare2 decompilation environment with one provisioning script.

r2di automatically discovers the local toolchain, builds components where necessary, installs the resulting plugins, configures the Sleigh processor database, fixes Windows-specific configuration issues, and performs an end-to-end verification.

• r2ghidra — Ghidra's Sleigh-based decompiler integration
• r2dec / pdd — radare2's alternative decompiler
• Sleigh processor specifications
• Native Windows plugin DLLs
• Required environment variables
• radare2 configuration
• A Windows-compatible unzip shim for r2pm

r2di doesn't stop after copying files.

It actually tests:

• MSVC compilation
• radare2 execution
• plugin discovery
• r2ghidra loading
• Sleigh configuration
• pdg decompilation
• r2dec / pdd decompilation
• clean radare2 configuration loading

Getting radare2 decompilers working on Windows can involve considerably more work than simply installing radare2 itself.

Common problems include:

• Missing MSVC build tools
• Missing Windows SDK components
• Meson/Ninja configuration issues
• r2pm expecting Unix-style unzip
• Sleigh processor database discovery failures
• Incorrect SLEIGHHOME
• radare2 configuration not being loaded from the expected location
• Plugin ABI/version mismatches
• r2ghidra incorrectly detecting PE architectures
• gcc being selected as a SLEIGH architecture for Windows PE binaries
• Environment variables existing in one shell but not another

Typical failures look like:

Cannot find the sleigh home at ./lib/radare2/6.2.0/r2ghidra_sleigh

or:

No languages available

or:

Architecture string does not look like sleigh id: gcc

r2di is designed around these Windows-specific failure modes rather than assuming that a Linux-oriented installation procedure will translate directly to Windows.

• Windows 11
• PowerShell 5.1+

The recommended installation method is the Visual Studio Installer with the C++ development workload.

The important components are:

• MSVC C++ compiler
• Windows 11 SDK
• C++ build tools

A minimal command-line installation is also possible.

Visual Studio 2026 Community Edition / Windows 11 SDK / Buildtools

curl curl https://aka.ms/vs/18/Stable/vs_community.exe -o vs_community.exe

.\vs_community.exe `
  --add Microsoft.VisualStudio.Component.VC.Tools.x86.x64 `
  --add Microsoft.VisualStudio.Component.Windows11SDK.26100

The Visual Studio Installer is recommended for most users because it handles the complete toolchain installation and registration. Just be sure to check the boxxes It will also look for [+] Visual Studio location ie: C:\Program Files\Microsoft Visual Studio\18\Community if you insist upon using the CLI route for visual studio installation you may need to comment out line 380 - 382

r2dec is compiled natively with Microsoft's C/C++ toolchain.

For example, a Visual Studio Community installation may place the compiler here:

C:\Program Files\Microsoft Visual Studio\18\Community\
VC\Tools\MSVC\14.51.36231\bin\Hostx64\x64

Verify:

cl

If PowerShell cannot find cl.exe, add the appropriate MSVC directory to your environment or launch a Visual Studio Developer PowerShell.

You should see Microsoft's compiler banner rather than:

cl : The term 'cl' is not recognized...

radare2 must already be installed and available from PATH.

Verify:

r2 -v

For this version of r2di:

radare2 6.2.0

is the expected target.

Also verify:

where.exe r2

A typical installation might be:

C:\radare2\

with:

C:\radare2\bin

available through PATH.

One of the interesting parts of this project is that Node.js/NPM is not required for the r2dec build path used by r2di.

The required build tools can be installed directly with WinGet:

winget install Ninja-build.Ninja mesonbuild.meson

Verify:

meson --version
ninja --version

The provisioning process itself is intentionally lightweight.

On a prepared machine, the complete r2di provisioning process takes roughly 30 seconds, depending on network and disk performance.

Download: r2di.ps1 — PowerShell installer 📜 View r2di.ps1

Then run:

powershell -ExecutionPolicy Bypass -File .\r2di.ps1

If your execution policy already permits local scripts:

.\r2di.ps1

After installation, open a new PowerShell session so persisted environment variables are refreshed.

The script searches for:

• radare2
• Visual Studio
• MSVC
• Windows SDK
• Python
• Meson
• Ninja

It then configures the native compilation environment.

Relevant compiler variables include:

PATH
INCLUDE
LIB

r2di verifies the required build tools and prepares the environment needed to compile native radare2 plugins.

It also creates a small PowerShell-based unzip compatibility layer.

This exists because r2pm can expect Unix-style unzip behavior that is not necessarily available on a normal Windows installation.

The shim translates the relevant arguments into Windows-native Expand-Archive operations.

It supports the flags required by the r2pm workflow, including:

-o
-d
-q

No external Unix environment is required.

r2di installs r2ghidra through the radare2 package manager:

r2pm -ci r2ghidra

It then locates the resulting plugin and installs:

core_r2ghidra.dll

into the appropriate radare2 plugin directory.

One of the most important parts of r2di is handling the Sleigh processor specification database.

r2ghidra depends on Sleigh definitions for architecture and processor descriptions.

On Windows, locating these files can be problematic.

r2di searches the available locations and handles both:

1. r2pm-managed data
2. GitHub release data

It also understands the Windows package's flat layout.

Instead of assuming a Ghidra-style hierarchy such as:

Processors/
    x86/
        data/
            languages/

the script recognizes layouts where files such as:

.ldefs
.sla
.pspec
.cspec

are located directly inside the Sleigh directory.

A major source of:

No languages available

is r2ghidra not knowing where the Sleigh database lives.

r2di configures:

e r2ghidra.sleighhome=...

and persists the setting into the appropriate radare2 configuration file.

The script also determines the appropriate configuration location using:

r2 -H

It then starts a clean radare2 process and verifies that the configuration is actually loaded.

This is important because successfully writing an environment variable does not necessarily mean a new radare2 process will consume the expected configuration.

Another Windows-specific problem is incorrect architecture detection.

For some PE binaries, r2ghidra may attempt to interpret the architecture as:

gcc

which results in:

Architecture string does not look like sleigh id: gcc

r2di explicitly configures the default x86-64 SLEIGH language:

e r2ghidra.lang=x86:LE:64:default

This makes the default configuration appropriate for normal 64-bit Windows PE binaries.

r2dec is built directly from source.

The repository is cloned recursively:

git clone --recursive ...

Meson is configured using the native MSVC backend.

Ninja then builds the plugin:

core_pdd.dll

The resulting DLL is installed into the radare2 plugin directory.

This means the final r2dec component is a native Windows DLL, rather than requiring a separate compatibility environment.

r2di performs actual functional testing rather than assuming that successful installation means success.

The verification process includes:

A small C program is compiled with:

cl.exe

r2 -q -c "iI;q"

r2 -q -c "Lc"

The output should contain the installed plugins.

r2 -q -c "pdg @ main" test.exe

r2 -q -c "pdd @ main" test.exe

The script launches clean radare2 processes and verifies that:

r2ghidra.sleighhome

and:

r2ghidra.lang

are actually available.

Open a new PowerShell window and run:

r2 -v

Expected:

radare2 6.2.0

Check loaded plugins:

r2 -q -c "Lc"

Check Sleigh configuration:

r2 -q -c "e r2ghidra.sleighhome"

Check architecture configuration:

r2 -q -c "e r2ghidra.lang"

Expected:

x86:LE:64:default

Then decompile a PE binary:

r2 -q -c "pdg @ main" C:\path\to\binary.exe

And with r2dec:

r2 -q -c "pdd @ main" C:\path\to\binary.exe

The default configuration targets:

x86-64 PE

e r2ghidra.lang=x86:LE:32:default

e r2ghidra.lang=AARCH64:LE:64:v8A

e r2ghidra.lang=ARM:LE:32:v8A

These can be applied for an individual radare2 session or persisted in the radare2 configuration.

r2di configures and persists the following user-level variables:

A typical installation resembles:

C:\Users\%USERNAME%\
│
├── src\
│   ├── r2ghidra\
│   └── r2dec-js\
│
├── bin\
│   ├── unzip.ps1
│   └── unzip.cmd
│
├── .local\
│   └── share\
│       └── radare2\
│           ├── plugins\
│           │   ├── core_r2ghidra.dll
│           │   └── core_pdd.dll
│           │
│           └── r2ghidra_sleigh\
│
└── .radare2rc

The radare2 installation may additionally contain:

C:\radare2\
└── lib\
    └── radare2\
        └── 6.2.0\
            └── r2ghidra_sleigh\

Verify:

where.exe r2

If nothing is returned, add the radare2 bin directory to PATH.

For example:

C:\radare2\bin

Then open a new PowerShell window.

Install Visual Studio or the standalone Build Tools with the C++ workload and Windows SDK.

The script looks for standard Community, Professional, and Enterprise installations.

Verify the compiler:

cl

Install:

winget install mesonbuild.meson

or:

pip install meson

Install:

winget install Ninja-build.Ninja

or:

pip install ninja

Check:

r2 -q -c "e r2ghidra.sleighhome"

Then:

r2 -q -c "e r2ghidra.lang"

The Sleigh path should point to the installed processor database.

If necessary, manually test:

e r2ghidra.sleighhome=C:\radare2\lib\radare2\6.2.0\r2ghidra_sleigh

Set:

e r2ghidra.lang=x86:LE:64:default

This is one of the Windows PE-specific problems r2di is designed to eliminate automatically.

The script intentionally avoids adding a heavyweight Unix compatibility layer simply to satisfy an unzip invocation.

Instead, r2di generates:

unzip.ps1
unzip.cmd

The PowerShell implementation uses Windows-native:

Expand-Archive

The wrapper accepts the flags expected by the r2pm workflow.

This keeps the installation Windows-native while satisfying the assumptions made by the package-management tooling.

During development, the original r2pm workflow attempted to pull in Node.js/NPM as part of the r2dec setup.

For this installation path, that dependency was unnecessary.

r2di instead builds the native r2dec component through:

Meson → MSVC → Ninja

This keeps the provisioning footprint smaller and avoids installing an entire JavaScript runtime when the end result we need is:

core_pdd.dll

r2di is intentionally focused on one problem:

Make native radare2 decompilation on Windows boring.

No WSL requirement.

No Cygwin requirement.

No Linux VM.

No manual Sleigh hunting.

No hand-copying DLLs.

No guessing which radare2 configuration file is actually being loaded.

No fighting unzip.

No unnecessary Node.js installation.

Instead:

Windows 11
    │
    ├── Visual Studio / MSVC
    ├── Windows SDK
    ├── Python
    ├── Meson
    ├── Ninja
    └── radare2
            │
            ▼
          r2di
            │
       ┌────┴────┐
       ▼         ▼
   r2ghidra    r2dec
       │         │
       ▼         ▼
    Sleigh      pdd
       │         │
       └────┬────┘
            ▼
     Native Windows
     Decompilation

The result is a reproducible Windows reverse-engineering environment capable of using both:

pdg

and:

pdd

directly from radare2.

Built for reverse engineers who don't want to spend their afternoon fighting their toolchain.

r2di is an automation layer around the excellent open-source work provided by the radare2, r2ghidra, r2dec, Ghidra, Meson, Ninja, and Microsoft Visual C++ projects.

This project does not replace those projects — it makes their Windows installation path significantly less painful.

r2di is provided as-is.

radare2, r2ghidra, r2dec, Ghidra, and their respective components are distributed under their own licenses. Consult the upstream projects for their licensing terms.

Issues and pull requests are welcome.

Potential future improvements include:

• Additional Visual Studio versions
• More flexible radare2 installation detection
• Automatic architecture detection
• ARM/ARM64 defaults
• Improved r2pm integration
• Additional PE verification tests
• Support for more Windows configurations

If r2di saves you from manually debugging a Windows decompiler installation, consider opening an issue or contributing a fix.

The complete provisioning script is available here:

r2di.ps1 — PowerShell installer 📜 View r2di.ps1

For users who want to inspect the implementation before executing it, the PowerShell source should be reviewed directly from the repository.

Built for reverse engineers who don't want to fight their toolchain.

Live Binary Analysis • Behavioral Signal Scoring • AI-Assisted Forensics
radare2 + Local LLM reasoning inside Google Colab.

• 🔗 LinkedIn: https://www.linkedin.com/in/joseph-erickson-0b4405342/
• 🐦 Twitter
• ✉️ Email: josepherickson135@gmail.com

_{All tooling used for research, education, and defensive analysis.}