Quick start

This walkthrough takes you from a fresh machine to a completed scan in under five minutes.

1. 1

   Install VirtualSpace AppSec

   Download the installer from your order confirmation or the VirtualSpace website. Run the setup and follow the prompts. The application installs to your local machine with all dependencies bundled.

   InstallationCopy

   // Run the installer
   VirtualSpace-AppSec-Setup.exe

2. 2

   Activate your license

   Launch the application. On first run you will be prompted to enter your license key from your order confirmation email. The license is node-locked to your machine.

3. 3

   Run your first scan

   In the Dashboard panel, click Browse to select a target .exe or .dll. Then click Run Analysis in the header bar. The scan modal will show real-time progress as each analysis phase completes.

System requirements

VirtualSpace AppSec runs as a native Windows desktop application. The installer bundles all required runtimes and dependencies.

Operating systems

Hardware

The scan engine is multi-threaded and benefits from additional CPU cores during Deep scans. Memory pressure is the dominant factor when scanning large statically-linked binaries.

Runtime dependencies

The installer ships every runtime it needs. The Visual C++ Redistributable and all other dependencies are bundled into the application. No additional software installation is required.

Installation

VirtualSpace AppSec is distributed as a self-contained Windows installer. The installer bundles all dependencies, registers the application, and creates a desktop shortcut.

Windows installation

Download the installer from the VirtualSpace website or your order confirmation email.

// Run the installer with progress UI
Start-Process 'VirtualSpace-AppSec-Setup.exe' -Wait

// Silent install, no UI, log to file
VirtualSpace-AppSec-Setup.exe /S /D="C:\Program Files\VirtualSpace"

// Extract the portable ZIP and run directly
Expand-Archive VirtualSpace-AppSec-portable.zip -DestinationPath C:\Tools\VirtualSpace
Start-Process C:\Tools\VirtualSpace\VirtualSpaceAppSec.exe

Installation layout

After installation the application is structured as follows. The data directory stores license files, scan cache, and intermediate results.

License activation

VirtualSpace AppSec uses a license-based activation model. Each license is node-locked to a single machine. The client sends a hashed machine fingerprint and the license key over HTTPS during activation. No source code, binary contents, or scan results are transmitted.

Activating your license

On first launch, enter the license key provided with your purchase. The application validates the key against the license server and caches the activation locally. After successful activation, the license file is stored in %PROGRAMDATA%\VirtualSpace\license.dat.

Deactivation

To transfer a license to a different machine, deactivate on the current machine first. If the current machine is no longer accessible, contact support to release the seat manually.

Your first scan

This walkthrough runs a scan through the application GUI and explains the output. If you have not yet installed the application, see Installation first.

Loading a target

Open the application. In the Dashboard panel you will see the target selector at the top. Click Browse and select any compiled .exe or .dll file. The application immediately parses the PE structure and displays the detected file type, architecture, and source language in the status bar.

Running the analysis

With a target loaded, click Run Analysis in the header bar. A modal appears showing real-time progress as the scanner moves through each phase. The progress log displays each analysis step with colour-coded status indicators. Warnings about detected vulnerabilities appear inline as they are found.

Reading the results

When the scan completes, results populate across the application panels:

• Dashboard. Severity counter cards (Critical, High, Medium, Low), a security score circle (0 to 100), and a list of recent scans.
• Binary Analysis. PE file details including file type, architecture, subsystem, entry point, image base, section table, and import table.
• Findings. Aggregated list of all detected issues with severity badges, descriptions, and code locations. Filterable by severity level.
• Insights. Compliance posture, trend analysis across consecutive scans, and a prioritised remediation queue.

Architecture

The VirtualSpace AppSec scanner is a six-stage pipeline. Every stage runs locally on the scan host, including the AI classifier. The only network call in the entire pipeline is the license validation in stage one, and it carries nothing other than a hashed machine fingerprint.

Pipeline stages

Each stage is described in detail below. Stages run sequentially; the output of one stage is the input to the next.

1. PE inspection. Parses the DOS header, the NT headers, the section table, and the import / export tables. Extracts security-relevant flags (DEP, ASLR, SafeSEH, GS).
2. Language detection. Walks the import table, scans for compiler-emitted strings, and matches against a fingerprint database to determine the source language and toolchain.
3. Pattern scan. Applies the active rule pack against the disassembled code. Each rule is a YARA-like pattern annotated with severity, CWE mapping, and a remediation hint.
4. Heuristic flow. Reconstructs a control-flow graph and identifies dangerous patterns that span multiple basic blocks. For example, tainted user input flowing into a sink without sanitisation.
5. AI classifier. Findings from stages three and four are scored by the bundled language model. The model runs locally and is purpose-built for security pattern recognition. Low-confidence findings are dropped; high-confidence findings are ranked.
6. Aggregator. Deduplicates overlapping findings (the same root cause flagged by multiple rules) and emits the final report.

PE file analysis

The Portable Executable (PE) format is the container Windows uses for executables and dynamic libraries. VirtualSpace AppSec parses this container before any other analysis begins. Findings from this stage cover missing exploit-mitigation flags and suspicious import patterns.

DOS and NT headers

The DOS header contains the e_lfanew field at offset 0x3C, which points to the start of the NT headers. VirtualSpace verifies that the offset is within file bounds, that the four-byte signature at that offset is exactly 50 45 00 00 (PE\0\0), and that the file header that follows declares a sane number of sections.

The optional header contains the entry point, the image base, the subsystem, and, critically, the DllCharacteristics field that encodes the exploit-mitigation flags. Missing flags here become findings in the report.

Import table inspection

The import table reveals which Windows APIs the binary calls. This is one of the strongest signals available without executing the binary. A program that imports system, WinExec, or CreateProcessA is doing process spawning. A program that imports VirtualAlloc with EXECUTE_READWRITE permissions is a strong indicator of either a JIT compiler or a packed binary.

kernel32.dll
  GetProcAddress
  LoadLibraryA          // flagged: dynamic resolution
  VirtualAlloc          // inspected: page protection
  CreateProcessA        // flagged: process spawn

advapi32.dll
  RegOpenKeyExA
  CryptAcquireContextA  // inspected: provider type

ws2_32.dll              // flagged: network capability
  socket
  connect
  recv

Exploit mitigation flags

Language detection

Different toolchains produce binaries with different vulnerability profiles. A buffer overflow pattern in MSVC-compiled C++ is very different from a deserialisation gadget in a PyInstaller bundle. VirtualSpace identifies the source language during stage two of the pipeline so subsequent stages can apply the right rule set.

Detection signals

The detector combines four classes of signal. No single signal is sufficient. High-confidence detection requires agreement across at least three.

• Import table fingerprints. Each toolchain links against a recognisable set of runtime libraries: msvcp140.dll indicates MSVC, libstdc++-6.dll indicates MinGW, python311.dll indicates a CPython embed, node.dll indicates a Node bundle.
• Section names. Rust binaries typically include a .rdata$rustcry section. .NET assemblies include a .cormeta directory. Go binaries include a .gopclntab section.
• Embedded strings. Compiler-emitted strings such as "GCC: (...)" or "Microsoft (R) Optimizing Compiler" are extracted from the binary's read-only data section and matched against a dictionary.
• Resource directory structure. .NET assemblies, MFC binaries, and Qt applications all have characteristic resource layouts.

Supported toolchains

Automatic detection

When a target is loaded via the Browse button, the application automatically inspects the import table, scans for compiler-emitted strings, and matches against a fingerprint database. The detected language is displayed in the scan progress log and determines which language-specific vulnerability rules are applied.

The scan engine

The scan engine is the heart of the product. It is implemented as a pipeline of independent analysers that each take the disassembled binary as input and emit a list of candidate findings. The aggregator then deduplicates, ranks, and triages those candidates into the final report.

Analysers

VirtualSpace ships thirty-two analysers, grouped into four families. Custom analysers can be added through the rule pack format described under Custom rules.

Confidence model

Every finding carries a confidence score between 0.0 and 1.0. The score represents the AI classifier's estimate of the probability that the finding is a true positive. By default, only findings with a confidence above 0.6 are surfaced. This threshold can be adjusted in the Scan Settings panel.

Scan depths

VirtualSpace offers three scan depths. Each depth runs a different subset of the analyser pipeline and represents a different trade-off between completeness and elapsed time. Choose the depth that matches your stage in the development lifecycle.

Comparison

Severity model

VirtualSpace assigns one of four severity levels to every finding. Severity is determined by the rule that fired, modulated by the AI classifier's confidence and by environmental context. For example, a finding in an internet-facing binary is upgraded one level versus the same finding in an internal tool.

Security score

The summary panel reports a security score on a 0-100 scale. The score is derived from the number and severity of findings, weighted by confidence. Critical findings have the largest impact on the score.

Dashboard

The Dashboard is the landing panel and primary control surface. It contains the target selector, severity counters, a security score visualisation, and a list of recent scans.

Target selector

The target selector sits at the top of the Dashboard. Click Browse to open a file dialog filtered to .exe and .dll files. Once a file is selected, the application immediately parses the PE headers and populates the Binary Analysis panel with structural data. The status bar updates to confirm the target is loaded.

Severity counters

Four metric cards display the count of findings by severity: Critical, High, Medium, and Info / Low. These update in real time as the scan progresses and reflect the final tally when the scan completes.

Security score

The security score is a value from 0 to 100 displayed as a radial gauge. It is computed from a weighted sum of findings by severity, clamped to the 0-100 range. Higher severity findings have a larger impact on the score.

Recent scans

The recent scans list shows previously scanned binaries with their date, time, and severity badge breakdown. This provides at-a-glance historical context without leaving the Dashboard.

Binary Analysis

The Binary Analysis panel provides a static inspection of the loaded PE file. It populates automatically when a target is loaded via Browse. No scan is required; this data comes from the PE parser alone.

File information

Displays the file type (PE32 or PE32+), architecture (x86 or x64), subsystem (Windows GUI, Console, Native, etc.), entry point RVA, image base address, file size, and compile timestamp extracted from the PE headers.

PE sections

A table listing every section in the PE file with its name, virtual size, virtual address, raw size, and characteristics flags (CODE, IDATA, UDATA, R, W, X). Anomalous characteristics such as a writable and executable section are visually flagged.

Import table

Lists the imported DLLs and their resolved function names. The import table is one of the strongest signals available without executing the binary. Suspicious imports such as VirtualAlloc, CreateProcessA, or WinExec are highlighted for review.

AI Code Review

The AI Code Review panel accepts source code snippets for automated security analysis. The analysis is performed by a purpose-built language model that ships with the installer and runs entirely on your machine. The model is designed exclusively for vulnerability detection, taint analysis, and remediation guidance. Because it is not a general-purpose AI, it has a small footprint and does not require high-end GPU hardware. No code submitted through this panel ever leaves your machine.

Source input

Paste source code into the editor area. Supported languages are indicated by the language badges above the editor: C/C++, Python, .NET, and JS/HTML. The line counter displays current usage against the 250-line limit per submission.

Running analysis

Click Run Analysis to submit the code to the local AI engine. The model processes the snippet and returns structured findings with severity ratings, descriptions, and recommended fixes. Use Clear to reset the editor for a new submission.

Analysis results

Results appear below the editor with the same severity badge format used throughout the application. Each finding includes a title, severity level, detailed description of the vulnerability, and a remediation recommendation.

Detection Modules

The Detection Modules panel controls which detection modules are active during binary and source analysis passes. Each module targets a specific vulnerability class and can be toggled independently.

Detection modules

All modules are enabled by default. Disabling a module excludes its findings from the scan results entirely. This is useful for narrowing the scan scope when auditing a specific vulnerability class.

Findings

The Findings panel aggregates all detected security issues from the most recent scan into a single, filterable list with CWE classification and remediation context.

Severity filters

The filter bar at the top provides buttons for All, Critical, High, Medium, and Low. Clicking a filter shows only findings at that severity level. Each finding card displays a title, severity badge, description, and a code location string identifying the function or offset where the issue was detected.

Security Insights

The Insights panel provides contextual recommendations and prioritised remediation guidance based on scan results. It contains three cards:

• Compliance Posture. Maps scan results against OWASP Top 10 (2025) and CWE/SANS Top 25 to identify coverage gaps and compliance status.
• Trend Analysis. Historical severity distribution and regression tracking populate after consecutive scans of the same target, enabling week-over-week comparisons.
• Priority Remediation. A weighted remediation queue based on exploitability, blast radius, and fix complexity. Critical findings are always listed first.

Scan Settings

The Scan Settings panel controls analysis depth, engine behaviour, and heuristic thresholds.

Scan depth

Three radio options control the scan depth: Quick (header + import table only), Standard (full static analysis pass), and Deep (exhaustive audit with heuristic passes). Standard is selected by default. Scan duration varies with binary size and complexity.

Analysis modules

Toggle individual analysis modules on or off. Available modules include heuristic pattern matching, CVE / NVD correlation matching, experimental detector vectors (beta), and embedded resource extraction. All are enabled by default except the experimental detectors.

Engine

Engine-level settings control resource usage: parallel analysis workers (enabled by default), low-memory mode for machines with less than 512 MB available, and caching of intermediate results to speed up consecutive scans.

Rulesets and Policies

The Rulesets panel manages detection rule sets and compliance mappings. Rule sets can be imported, exported, and toggled between Active and Inactive states.

Built-in rule sets

Custom rules

Click Add Custom Rule to define your own detection policies. Custom rules follow the same YAML format as built-in rules and can target specific CWEs, severity levels, and code patterns. Use Import Ruleset and Export Ruleset to back up or transfer rule configurations.

Memory corruption

The Memory Corruption module covers stack buffer overflows, heap overflows, use-after-free, double-free, and out-of-bounds read/write patterns. These remain the most common source of remote code execution in C and C++ binaries. VirtualSpace detects them through pattern matching on dangerous APIs (strcpy, strcat, sprintf, gets) and heuristic flow analysis that tracks tainted user input into stack and heap buffers.

void handle_request(char* user_input) {
  char buffer[64];
  strcpy(buffer, user_input);  // CWE-120: classic stack overflow
  process(buffer);
}

void handle_request(char* user_input) {
  char buffer[64];
  strncpy(buffer, user_input, sizeof(buffer) - 1);
  buffer[sizeof(buffer) - 1] = '\0';
  process(buffer);
}

Injection flaws

SQL, command, LDAP, XPath, ORM, and template injection are detected by tainting user-input sources and tracking the taint through the control-flow graph until it reaches a sink. A finding is raised when a tainted value reaches a sink without passing through a recognised sanitiser.

XSS / output encoding

The XSS module detects reflected, stored, and DOM-based cross-site scripting patterns. It inspects output encoding mechanisms and analyses web interface components embedded in the binary for unsafe rendering of user-controlled data.

Cryptographic weakness

Covers deprecated ciphers (DES, RC4, MD5, SHA-1), insecure modes (ECB), hardcoded IVs and keys, weak PRNG seeding, insufficient key length, and misuse of high-level cryptographic APIs such as calling CryptAcquireContext with PROV_RSA_FULL when PROV_RSA_AES is required.

Secrets detection

Detects embedded API keys, authentication tokens, database passwords, connection strings, and other hardcoded credentials compiled into the binary. The scanner uses entropy analysis combined with format-specific pattern matching (AWS keys, GitHub tokens, generic high-entropy strings) to distinguish real secrets from false positives.

Dynamic execution

The Dynamic Execution module flags use of eval(), exec(), Runtime.exec(), system(), insecure deserialization sinks (pickle, BinaryFormatter), and runtime code generation patterns. These represent the highest-risk code paths because they can convert data-plane input into control-plane actions.

OWASP Top 10 (2025)

The OWASP rule pack maps every analyser in the memory, crypto, auth, and input-validation families to the relevant OWASP category and reports compliance per category in the summary panel.

CWE/SANS Top 25 (2025)

The CWE pack covers all twenty-five entries on the SANS Top 25 most dangerous software weaknesses list. Each finding reports its CWE ID and a link to the corresponding entry on cwe.mitre.org.

PCI DSS v4.0.1

The PCI DSS pack focuses on requirement 6.2.4 (secure coding) and the cryptographic requirements in section 3 (protect stored cardholder data). Compliance status is displayed in the Security Insights panel.

Custom rules

You can author custom rule packs in YAML. A rule pack is a list of rules, each defining a name, a CWE mapping, a severity, a pattern (regex over disassembly text or YARA rule body), and a remediation hint.

# custom-rules.yaml
pack: acme-internal
version: 1
rules:
  - id: ACME-001
    name: Internal logger leak
    cwe: CWE-532
    severity: medium
    pattern: 'AcmeLog::WriteSensitive'
    recommendation: "Replace with AcmeLog::WriteRedacted."
  - id: ACME-002
    name: Unsanctioned crypto provider
    cwe: CWE-327
    severity: high
    pattern: 'CryptAcquireContext.*PROV_RSA_FULL'
    recommendation: "Use PROV_RSA_AES (provider type 24)."

NIST SP 800-218 (SSDF)

The NIST rule pack maps findings to the Secure Software Development Framework requirements. It covers thirty-one rules aligned with NIST's guidance on secure development practices, vulnerability response, and software integrity verification. Active by default.

OWASP LLM Top 10 (2025)

The LLM rule pack targets vulnerability patterns specific to applications that integrate large language models: prompt injection, insecure output handling, training data poisoning, model denial of service, and supply chain vulnerabilities in AI/ML pipelines. Ships inactive by default; enable it in the Rulesets panel for applications that interact with LLM services.