DEV Community: Stefor07

Nested Virtualization on Windows 11: The VBS Conflict Explained

Stefor07 — Thu, 12 Feb 2026 20:50:11 +0000

Introduction

After upgrading to a modern system with full virtualization support — including VT-x, EPT, IOMMU, TPM 2.0, and Secure Boot — I expected everything to work flawlessly. Instead, I encountered crashes and instability when running nested virtualization scenarios, particularly when attempting to run VMware inside VMware Workstation Pro.

At first, I suspected hardware instability, BIOS misconfiguration, or a VMware bug. However, after extensive testing, I discovered the real culprit: Windows Virtualization-Based Security (VBS).

This article covers:

How VBS affects desktop hypervisors on modern Windows 11 (24H2/25H2)
Why nested virtualization fails under certain configurations
Practical solutions for advanced lab environments requiring full VT-x access

The Problem: VMware Nested Virtualization Failures

The issue surfaced when I upgraded to a 14th generation Intel CPU with hybrid cores (P-cores and E-cores). While VMware Workstation Pro ran perfectly on the host, problems arose when I tried running VMware inside a Windows 11 24H2 VM.

Attempting to boot a Windows 11 ISO inside the nested VM resulted in an immediate crash: VMware reported that an exception had caused a breakpoint, and the VM shut down.

Understanding the Root Cause: VBS

Virtualization-Based Security (VBS) is fully integrated into Windows 11's kernel and takes exclusive control of VT-x/AMD-V. This prevents desktop hypervisors from accessing hardware virtualization directly, causing conflicts with nested virtualization.

Initial Troubleshooting Attempts

I tried several manual approaches to disable VBS:

Disabling Core Isolation (Windows Security → Device Security)
Disabling hypervisor launch:

   bcdedit /set hypervisorlaunchtype off

Disabling HypervisorIOMMUPolicy:

   bcdedit /set HypervisorIOMMUPolicy off

Group Policy and Registry edits

None of these methods worked completely. The hypervisors continued to crash or remained unstable.

The Only Working Solution: Microsoft's DG_Readiness_Tool

After extensive testing, I discovered that the only reliable solution is using Microsoft's official script for disabling VBS:

Download: DG_Readiness_Tool

Usage:

DG_Readiness_Tool_v3.6.ps1 -Disable

After running the script and rebooting, VBS is successfully disabled and nested virtualization works correctly.

Important: This change is temporary — Windows re-enables VBS after subsequent reboots, so the script must be rerun when needed.

Why Other Approaches Don't Work

HypervisorIOMMUPolicy Alone Is Not Enough

Initially, I believed that disabling HypervisorIOMMUPolicy would solve issues for lightweight hypervisors and Android emulators while keeping VBS active. This turned out to be incorrect.

Even with HypervisorIOMMUPolicy disabled, hypervisors running inside VMware VMs remain unstable or fail to launch because:

VBS maintains VT-x/AMD-V control: As long as VBS is active, Windows Hypervisor Platform retains exclusive access to hardware virtualization extensions
Nested hypervisors require direct hardware access: VMware, VirtualBox, and even lightweight emulators need unmediated access to VT-x/AMD-V
Security layer interference: VBS creates a security boundary that conflicts with nested virtualization regardless of IOMMU settings

The Real Solution

Complete VBS disabling via the DG_Readiness_Tool is the only reliable approach for running any hypervisor inside VMware virtual machines, including:

VMware Workstation Pro
VirtualBox
Android emulators (AVD, Genymotion)
KVM (on Linux guests)
Other lightweight hypervisors

Complete Solutions

Since VBS cannot be permanently removed from Windows 11 24H2/25H2, here are your options:

Solution 1: Temporary VBS Disable (Recommended for Testing)

Run DG_Readiness_Tool_v3.6.ps1 -Disable before each session requiring nested virtualization
Provides full VT-x access temporarily
Limitation: Must be rerun after each reboot

Solution 2: Downgrade or Dual-Boot (Recommended for Permanent Use)

Use Windows 11 22H2 (doesn't enforce VBS)
Install as dual-boot alongside 24H2/25H2
Provides permanent, stable hardware virtualization without workarounds

Solution 3: Switch to Linux (Best for Advanced Labs)

No VBS restrictions whatsoever
Superior virtualization performance
Native KVM support with full hardware access
Popular options: Ubuntu, Fedora, Debian, Arch-based distributions

Compatibility Matrix

The table below shows hypervisor compatibility when running inside VMware VMs on Windows 11 24H2/25H2:

Hypervisor / Software	VBS Enabled	VBS Disabled (DG_Readiness_Tool)	Notes
VMware Workstation Pro	❌ Crash	✅ Works	Requires full VBS disable
VirtualBox	❌ Crash/Unstable	✅ Works	Requires full VBS disable
Android Emulators (AVD)	❌ Crash/Unstable	✅ Works	Requires full VBS disable
KVM (Linux VM)	❌ Cannot run	✅ Works	Requires full VBS disable
Hyper-V (Windows VM)	❌ Not supported	❌ Limited	Nested Hyper-V not functional on VMware
Other lightweight hypervisors	❌ Unstable	✅ Works	Requires full VBS disable

Legend: ✅ Works reliably | ❌ Fails or unstable

Key Finding: All hypervisors running inside VMware VMs require VBS to be completely disabled. Partial solutions like disabling only HypervisorIOMMUPolicy or hypervisorlaunchtype do not provide stable nested virtualization.

Key Takeaways

VBS must be fully disabled for any nested virtualization scenario on Windows 11 24H2/25H2:

   DG_Readiness_Tool_v3.6.ps1 -Disable

Partial solutions don't work: Disabling only HypervisorIOMMUPolicy or hypervisorlaunchtype is insufficient
Hardware requirements:
- Enable VT-x/AMD-V in BIOS/UEFI
- Expose virtualization to guest VM in VMware settings
- Use multi-core CPU allocation for better stability
Long-term solutions:
- For frequent nested virtualization use: Switch to Windows 11 22H2 or Linux
- For occasional testing: Use the DG_Readiness_Tool and accept the need to rerun it after reboots
- For production lab environments: Linux hosts provide the most stable and performant solution

Conclusion

Modern Windows 11's VBS creates fundamental incompatibilities with nested virtualization. While VBS enhances system security, it takes exclusive control of hardware virtualization extensions, making it impossible for hypervisors running inside VMs to function properly.

The critical discovery: Unlike what initial testing suggested, there is no partial workaround. Complete VBS disabling via Microsoft's DG_Readiness_Tool is mandatory for any nested hypervisor scenario, regardless of whether you're running VMware, VirtualBox, or lightweight Android emulators.

For users requiring frequent nested virtualization:

Windows 11 22H2 in dual-boot configuration offers a permanent VBS-free environment
Linux hosts eliminate VBS restrictions entirely and provide superior performance
Temporary VBS disabling works but requires re-running the script after every reboot

Understanding this limitation helps set realistic expectations and choose the right platform for advanced virtualization labs and development environments.

🔎 Possible Silent Fix in Recent Updates

After installing recent cumulative updates on Windows 11 25H2 (notably build 26200.7840), I noticed a significant behavioral change:
VBS remained enabled as a feature, but the hypervisor was no longer forced into execution at boot.

Previously, even after explicitly disabling Hyper-V launch via BCD and policy settings, the system would re-enable the hypervisor at startup. This required manual intervention on every reboot.

Following recent updates, the system now correctly respects hypervisorlaunchtype off, and VBS remains configured but not running unless explicitly required.

Although Microsoft has not documented a specific fix related to VBS policy enforcement, this suggests that changes were made to how Windows handles hypervisor auto-launch behavior.

Decompression in C/C++: Virtual Files and Memory I/O Principles and Techniques

Stefor07 — Mon, 27 Oct 2025 19:40:55 +0000

In this article, we will analyze techniques for managing buffers and virtual files during decompression operations in C/C++, with practical examples showing how to work with both high-level and low-level libraries.

Why Decompress Directly in Memory?

Decompressing archives directly in memory instead of using temporary files offers several advantages:

Performance: Avoiding disk I/O significantly reduces latency, especially for repeated reads or streaming scenarios.
Security: Sensitive data never touches the disk, reducing the risk of exposure or leaving traces.
Single-File Deployment: Combined with techniques like embedding binary data in executables, you can load and unpack archives without deploying external files.
Flexible Data Sources: Works with network streams, embedded resources, or any custom buffer—not bound by the file system.
Cleaner Resource Management: No temporary files means less cleanup, fewer permissions issues, and simpler code.

Memory vs Disk Decompression: Understanding the Landscape

Decompression libraries fall into two categories based on how they handle data sources:

High-level libraries provide native APIs for extracting data directly into memory buffers. These abstract away the complexity of I/O operations, making memory-based decompression straightforward.

Low-level, file-centric libraries assume data comes from disk files. They expect standard file operations (read, write, seek) and require developers to implement custom I/O callbacks to work with memory buffers.

Understanding this distinction helps you choose the right tool and integration approach for your use case.

High-Level Libraries with Native Memory Support

Several modern libraries provide built-in memory extraction without requiring custom callbacks:

libzip

zip_fread(): Reads files directly into memory buffers
zip_source_buffer_create(): Creates a ZIP source from existing memory
zip_open_from_source(): Opens archives using in-memory sources

libarchive

archive_read_data(): Extracts entries into memory buffers
archive_write_data(): Writes from memory into archives
Supports multiple formats (ZIP, TAR, etc.)

zlib

uncompress(): Single-call buffer decompression
inflateInit(), inflate(): Stream-based API for progressive decompression

miniz

mz_zip_reader_init_mem(): Open ZIP from a RAM buffer
mz_zip_reader_extract_file_to_heap(): Extract a file into an allocated buffer
mz_zip_reader_extract_file_to_mem(): Extract into a provided buffer

Iterative API (extract_iter) → Read stream from memory

These libraries handle all the complexity internally—reading compressed chunks, decompressing them, and writing output—while exposing simple, memory-friendly APIs.

Low-Level Libraries: The Custom Callback Approach

Unlike high-level libraries, some decompression tools are designed exclusively for file-based I/O:

LZMA SDK (7-Zip)
Windows Cabinet APIs (FCICreate, FDICopy, etc.)
Minizip (part of zlib) (pzlib_filefunc_def)

These libraries don't provide memory extraction APIs. Instead, they expect standard file operations and process data through internal buffers that aren't exposed to developers.

To work with memory buffers, you must implement custom I/O callbacks that simulate file behavior. The library requests data—thinking it's reading from a file—while your callbacks feed it data from memory instead.

How Custom Callbacks Work

The process is conceptually simple:

Your compressed archive is loaded into a memory buffer
The library performs read, seek, or write operations
Your callbacks intercept these operations and provide data from your buffer
The library processes this data through its internal buffers, decompressing as if reading from a real file

This approach requires more boilerplate but provides full control over memory usage and enables working with non-disk data sources.

Implementing Memory Callbacks

To make file-centric libraries work with memory, we encapsulate the buffer in a structure that tracks position:

#include <stdint.h>
#include <string.h>
#include <stdbool.h>

typedef struct
{
    const uint8_t* data;      // pointer to memory buffer
    size_t size;           // total size of buffer
    size_t pos;            // current position
} MemoryStream;

Core Callback Implementations

Read Callback
Reads up to bytes from the stream into dst.
Returns the number of bytes actually read.

size_t Read(MemoryStream* ms, void* dst, size_t bytes) 
{
    if (!ms || !dst || ms->pos >= ms->size)
    {
        return 0;
    }

    size_t remainingBytes = ms->size - ms->pos;

    if (bytes > remainingBytes)
    {
        bytes = remainingBytes;
    }

    memcpy(dst, ms->data + ms->pos, bytes);

    ms->pos += bytes;
    return bytes;
}

Seek Callback
Moves the current position relative to the beginning, current position, or end of the stream.

typedef enum SeekOrigin { SEEK_SET, SEEK_CUR, SEEK_END };

bool Seek(MemoryStream* ms, long offset, SeekOrigin origin) 
{
    if (!ms)
    {
        return false;
    }

    uint64_t newPos = 0;

    switch (origin) 
    {
        case SEEK_SET: 
        {
            newPos = (uint64_t)offset; 
            break;
        }
        case SEEK_CUR:
        {
            newPos = (uint64_t)ms->pos + offset; 
            break;
        } 
        case SEEK_END: 
        {
            newPos = (uint64_t)ms->size + offset; 
            break;
        }

        default:
        {
            return false;
        }
    }

    if (newPos < 0)
    {
        newPos = 0;
    }
    else if (newPos > (uint64_t)ms->size)
    {
        newPos = (uint64_t)ms->size;
    }

    ms->pos = (size_t)newPos;
    return true;
}

⚠️ Warning: Inside this callback, the newPos variable is declared as an uint64_t. This is done for safety, to avoid overflows when adding or subtracting long values with the current position or the stream size (size_t). In particular, since ms->size and ms->pos are of type size_t (typically unsigned), converting to uint64_t allows for correct handling of negative offsets and prevents undefined behavior resulting from operations between signed and unsigned types. Additionally, using int64_t provides extra safety when working with very large archives, ensuring that file positions larger than 4 GB or 2^32 bytes are handled correctly. This choice does not affect behavior on 32-bit processes.

Look Callback
Provides a direct pointer to the unread portion of the buffer (for “peek” access).

bool Look(MemoryStream* ms, const void** buf, size_t* size)
{
    if (!ms || !buf || !size)
    {
        return false;
    }

    if (ms->pos >= ms->size)
    {
        *buf = NULL;
        *size = 0;
        return false;
    }

    *buf = ms->data + ms->pos;
    *size = ms->size - ms->pos;

    return true;
}

Skip Callback
Advances the current position by offset bytes (without reading).

bool Skip(MemoryStream* ms, size_t offset) 
{
    if (!ms)
    {
        return false;
    }

    if (offset > SIZE_MAX - ms->pos)
    {
        return false;
    }

    if (ms->pos + offset > ms->size)
    {
        ms->pos = ms->size;
    }
    else
    {
        ms->pos += offset;
    }

    return true;
}

Write Callback
Writes up to bytes from src into the buffer.
Returns the number of bytes successfully written.

bool Write(MemoryStream* ms, const void* src, size_t size)
{
    size_t remainingBytes = ms->size - ms->pos;

    if (size > remainingBytes)
    {
        size = remainingBytes;
    }

    uint8_t* dest = (uint8_t*)ms->data + ms->pos;
    memcpy(dest, src, size);

    ms->pos += size;
    return true;
}

Tell Callback
Returns the current position within the buffer.

size_t Tell(const MemoryStream* ms)
{
    return (ms && ms->pos <= ms->size) ? ms->pos : 0;
}

Callback Purpose and Usage

Each callback serves a specific role when simulating file access in memory:

Read: Provides the next chunk of data from the memory buffer. Essential for decompression, parsing, or streaming input.
Seek: Moves the current position relative to the beginning, current position, or end of the buffer. Required for random-access libraries.
Look: Provides a pointer to the unread portion of the buffer for “peek” operations without changing the current position. Optional but useful for inspection.
Skip: Advances the current position by a given number of bytes without copying data. Useful for efficiently ignoring unwanted sections.
Write: Stores processed or decompressed output back into memory. Not required for read-only operations.
Tell: Returns the current position within the buffer. Needed for offset tracking or progress reporting.

Usage Notes

Sequential operations (e.g., streaming decompression) may only require Read and Write.
Random-access archives or seeking operations require Seek, Skip, and Tell.
Inspection-only operations might only need Read and Look, skipping Write entirely.

Adapting Callbacks to Specific Libraries

The callbacks above are a starting template. Each library has different requirements for function signatures, parameters, or behavior. Some might pass opaque pointers instead of MemoryStream*, or require additional flags.

The key principle is adapting memory buffers to behave like files. From this foundation, customize the callbacks to match your library's API.

Library-Specific Requirements

LZMA SDK
Requires ILookInStream interface with 4 callbacks:

Look → peek at upcoming bytes without advancing
Skip → skip bytes forward
Read → read and advance cursor
Seek → move to specific position

Windows Cabinet (CAB) SDK
Requires 2 main callbacks:

File operations (CabRead, CabWrite, CabSeek)
Notify callback (CabNotify) for operation events

minizip (part of zlib)
Requires 7 main callbacks:

File open: ZipOpen – opens the archive (or memory stream)
File read: ZipRead – reads data from the archive
File write: ZipWrite – writes data to the archive
File tell: ZipTell – returns the current position in the archive
File seek: ZipSeek – moves the read/write position
File close: ZipClose – closes the archive or stream
File error: ZipError – reports I/O errors

This comparison shows how different libraries require varying levels of manual I/O adaptation.

Library Comparison

Library	Memory Support	Custom Callbacks	Complexity	Key Features
libzip	✅ Native	❌ Not needed	Low	`zip_fread()`, `zip_source_buffer_create()`, `zip_open_from_source()`
libarchive	✅ Native	❌ Not needed	Low	Multi-format support, `archive_read_data()`, `archive_write_data()`
zlib	⚠️ Partial	❌ Not needed	Low/Medium	`uncompress()` and streaming APIs, efficient for simple compression
miniz	✅ Native	❌ Not needed	Low	Provides dedicated in-memory ZIP APIs (`mz_zip_reader_init_mem()`, `mz_zip_reader_extract_file_to_heap()`, `mz_zip_reader_extract_file_to_mem()`)
minizip (part of zlib)	❌ Manual	✅ Required	Medium	Requires implementing 7 callbacks for the `zlib_filefunc_def` structure.
LZMA SDK (7-Zip)	❌ Manual	✅ Required	High	Requires `ISeqInStream` (1 callback) or `ILookInStream` (4 callbacks), granular control
Windows Cabinet (CAB) APIs	❌ Manual	✅ Required	Medium	Core callbacks: `Read`, `Write`, `Seek`, plus `CabNotify`, simpler than LZMA

Conclusion

Memory-based decompression in C/C++ requires understanding two distinct approaches: high-level libraries with native memory APIs, and low-level file-centric libraries requiring custom callbacks.

High-level libraries like libzip, libarchive, zlib, and miniz provide straightforward, efficient APIs for working directly with memory buffers. For most use cases, these should be your first choice.

When working with specialized formats or legacy libraries like LZMA SDK or Windows Cabinet APIs, Minizip , custom callbacks bridge the gap. By implementing virtual file operations on memory buffers, you gain the same flexibility while maintaining full control over data flow.

Whether you're embedding archives in executables, processing network streams, or avoiding disk I/O for security reasons, these techniques enable efficient, flexible decompression workflows entirely in memory.

Apply these patterns in your projects: start with high-level APIs when available, and implement custom callbacks when necessary. With this foundation, you're equipped to build secure, performant decompression solutions in C++.

The Perfect Illusion: When VirtualBox Pretends to Be Parallels

Stefor07 — Tue, 15 Jul 2025 16:10:04 +0000

A visual and technical experiment to reinvent the Parallels experience on Windows, starting with VirtualBox and pushing it beyond its limits.

"Parallels Desktop on Windows doesn't exist. Or so they say. But looking at this window—clean, immersive, devoid of any recognizable hypervisor signature—makes you wonder: what if it actually existed?
A virtual machine that doesn't feel virtual. No intrusive UI, no detail that betrays its technical heart. Just a parallel operating system, living alongside my real world.
If Parallels never came to Windows, then I decided to bring it to you.
This isn't emulation. It's not cloning. It's illusion—perfect, intentional, ingeniously constructed.
Welcome to my visual experiment: when VirtualBox pretends to be Parallels and perception surpasses reality".

How the idea was born – from boredom to vision 💡

ℹ️ 1. What happened to Parallels?

I was bored. And not just any boredom—the digital kind, made up of identical windows, monotonous virtual systems, and gray interfaces. So I asked myself: what would happen if I could have Parallels Desktop… on Windows? A software that doesn't exist, but one I've always imagined for its elegance and its unique way of bringing two systems together.

ℹ️ As many know, Parallels is a company we could call VMware’s younger sister — once dedicated to developing desktop virtualization software for Windows, Linux, and macOS alike.
But over time, as attention to the Windows and Linux platforms faded, Parallels felt neglected. A bit heartbroken

“...Parallels felt neglected. A bit heartbroken, it quietly stepped away from Windows and Linux, turning its full attention to macOS — the platform where it found not just support, but a sense of identity.”

❗ 2. But do Windows and Linux really have to give up?

Why should Windows and Linux users be denied the fully parallel experience that Parallels Desktop once offered? It’s simply not fair. So, driven by a mix of frustration and curiosity, I decided to recreate the illusion myself.

With a bit of cunning and the help of tools like AutoHotkey and Resource Hacker, I started to disguise and camouflage VirtualBox — reshaping icons, tweaking window titles, and crafting a Parallels-like look and feel.
For now, the experiment runs only on Windows. But even there, the illusion is surprisingly convincing.

"...If the software doesn’t exist, sometimes you just have to simulate it into existence."

This wasn’t just about visual tweaks — it was about reimagining the virtualization experience entirely.
Every icon, every title bar, every missing menu had a purpose: to dissolve the border between host and guest, making the virtual system feel native, invisible, seamlessly embedded.

🎯 3. Why VirtualBox?

Some might ask: why not use VMware instead?

Well, VirtualBox gave me the flexibility I needed — it's open-source, scriptable, and wonderfully customizable.

Sure, it's not the most powerful hypervisor out there, but when it comes to crafting illusions, it’s the perfect canvas.
And let’s be honest: if a hypothetical Parallels Desktop for Windows had ever existed, it likely wouldn’t have matched VMware’s virtualization performance.

VMware focuses heavily on Windows, making it almost the opposite of Parallels, which is developed exclusively for macOS.
In that sense, choosing VirtualBox wasn’t about chasing raw power — it was about bending reality to fit a vision

🧰 How I created the illusion!

Even though I wasn’t able to fully modify VirtualBox’s entire UI, that didn’t stop me from reshaping the experience at the VM window level.
Using a mix of clever tools and command-line magic, I customized the virtual machine’s appearance to mimic Parallels Desktop’s minimal aesthetic:

I removed all default menu bars to keep the window clean and immersive.
With VBoxManage, I changed the VM icon directly from the CLI.
Thanks to AutoHotkey, I ran scripts that dynamically updated window titles and replaced icons in real time.
I downloaded the Parallels Desktop icon, converted it, and swapped it into the interface using Resource Hacker.
I changed the VirtualBox shortcuts names to Parallels Desktop, and created another AutoHotkey script to start VirtualBox with the window title changed to Parallels.

The result? A VirtualBox VM that looks and behaves like something Parallels might have built for Windows — a visual and perceptual transformation that breaks the barrier between host and guest.

To make everything even more convincing, I added one last touch.
I downloaded the classic two red bands from Parallels Desktop — a visual signature that anyone familiar with the software would instantly recognize.

Using GIMP, I carefully placed those bands over the system's OS icon, creating a layered image that visually mimics the official Parallels branding.
Once re-exported, the final result made the illusion even more real and immersive — as if the VM were part of an actual Parallels build for Windows.

🎨 A touch of personality or motivation

It wasn't just about making things look cool, it was about creating something that felt real. Something that could live in a world where Parallels would re-embrace Windows. The red stripes weren't a decoration; they were the signature of a dream I wanted to resurrect, something to please Windows and Linux users, to console them for the absence of Parallels Desktop on Windows/Linux.

🔍 A reflection on perception vs. reality

Did the illusion work? Those seeing the VM for the first time weren't asking "Is this VirtualBox?", but "How did you get Parallels on Windows?" And that question alone meant I'd succeeded: the line between simulation and reality had been blurred just enough to make it believable, this is all camouflage up to a certain point.

🧠 Philosophical angle (if you like deeper tones

Software isn't just function: it's emotion, memory, branding, aspiration. By visually rebuilding Parallels, I wasn't simply modifying a window... I was restoring an experience that had never been offered to Windows users — until now.

We should be grateful for it, even if the underlying virtualization engine remains VirtualBox.

And let’s face it: expectations weren’t high to begin with… but perhaps that made the illusion all the more satisfying.

Even I sometimes forgot I was using VirtualBox. That, to me, was proof that the illusion wasn't just visual — it changed how I experienced virtualization.

🧾 Introduction to screenshots

Enough talk. Let’s look at it.
Here’s what my Parallels-inspired illusion looks like — built entirely with VirtualBox, scripts, icon edits, and a little creative defiance

The actual VirtualBox UI with some customizations, changed icon and window text

No virtual machine has ever felt so integrated. When even the most experienced users pause and ask, "Wait, is this Parallels on Windows?", you know the trick has worked—it's all done correctly and believably!

⚠️ This article does not aim to clone or impersonate any commercial software.
It simply explores how open tools like VirtualBox can be visually reimagined to mimic the aesthetic of other environments.

I didn't set out to create a clone. I set out to create a possibility, a possibility that never officially existed, but now lives on through perception. This experiment reminded me that creativity isn't bound by platforms or limitations. Sometimes, the best features are the ones we imagine. Since I've always imagined Parallels Desktop on Windows, my dream has now come true, to a certain extent.

🔚 Bonus insight: when illusion isn’t enough

This experiment was about perception, reinterpreting what virtualization could look like on Windows. But if your goal is raw power, advanced features, and enterprise-level performance, it's worth mentioning:
💼 VMware Workstation Pro remains the benchmark for professional virtualization on Windows and Linux.

It's robust, well-maintained, and often surpasses both VirtualBox and Parallels in terms of stability and functionality. If there were a version of Parallels Desktop for Windows, it would certainly have beaten it straight away.
So, if illusion has its charm, performance has its champions.

In the end, it’s not about replacing Parallels, or replicating VMware’s precision.
It’s about imagining — reshaping a tool, bending its form, and remembering that sometimes, a small illusion can spark a bigger idea.
Whether you choose performance or perception… at least now, there’s a choice.

🏁 Final thoughts: not just a VM, but a vision

What started with boredom became a form of digital expression.
A simple VirtualBox window, stripped and reshaped, turned into a parallel experience — one that never existed officially, but now feels strangely real.

This project wasn’t about replacing Parallels. It was about reclaiming possibility.
Windows users deserve elegant virtualization too — and if the industry won’t deliver it, sometimes curiosity and ingenuity can.

I know it’s still VirtualBox under the hood. And that’s okay.
Because sometimes, the engine isn’t what matters most — the illusion is.
Imagination is the real hypervisor.

Imagination is the real hypervisor.

Did this illusion spark something in you? Ever tried transforming a tool just for the fun of it — or the aesthetics?
Share your thoughts below — I'd love to hear how you've reimagined software experiences, or even built your own digital illusions.

I'm open and happy to hear your opinion and other ideas! 😊

How to Easily Distinguish Multiple Binary Files Appended to a Win32 Executable

Stefor07 — Mon, 23 Jun 2025 13:22:13 +0000

In this article, you'll learn how to reliably identify and extract multiple binary files appended to the end of an executable file using only offsets and size calculations.

While experimenting with binary file concatenation on Windows executables, I discovered a simple and practical method to distinguish and load multiple appended files — without relying on any extra markers, headers, or metadata.

Unlike the technique shown in the fourth method How to Embed Binary Data into a Win32 Executable File in 4 Methods, which supports only a single appended file, this approach scales naturally to multiple appended files, with a clean and straightforward logic.

Step 1: Declaring Helper Functions in Code

Add these helper functions in your code:

1. Determine the real size of the executable (excluding any appended binary data).
2. Load the appended binary data into memory using the new memory mapping helper function which:

Accepts a struct argument to store all necessary handles for proper cleanup;
Takes a DWORD argument to specify how many bytes to skip at the beginning (the executable + any previously handled appended files);
Ensures safe and efficient resource management by allowing explicit freeing of memory-mapped views and handles.

Gets the actual size of the EXE excluding appended binary data

DWORD GetRealExeSize(const TCHAR* exePath)
{
    HANDLE hFile = CreateFile(exePath, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hFile == INVALID_HANDLE_VALUE) return 0;

    HANDLE hMapping = CreateFileMapping(hFile, NULL, PAGE_READONLY, 0, 0, NULL);
    if (!hMapping) { CloseHandle(hFile); return 0; }

    LPBYTE pBase = (LPBYTE)MapViewOfFile(hMapping, FILE_MAP_READ, 0, 0, 0);
    if (!pBase) { CloseHandle(hMapping); CloseHandle(hFile); return 0; }

    IMAGE_DOS_HEADER* pDosHeader = (IMAGE_DOS_HEADER*)pBase;
    if (pDosHeader->e_magic != IMAGE_DOS_SIGNATURE)
    {
        UnmapViewOfFile(pBase);
        CloseHandle(hMapping);
        CloseHandle(hFile);
        return 0;
    }

    IMAGE_NT_HEADERS* pNtHeaders = (IMAGE_NT_HEADERS*)(pBase + pDosHeader->e_lfanew);
    if (pNtHeaders->Signature != IMAGE_NT_SIGNATURE)
    {
        UnmapViewOfFile(pBase);
        CloseHandle(hMapping);
        CloseHandle(hFile);
        return 0;
    };

    DWORD maxEnd = 0;
    IMAGE_SECTION_HEADER* pSection = IMAGE_FIRST_SECTION(pNtHeaders);
    for (int i = 0; i < pNtHeaders->FileHeader.NumberOfSections; ++i)
    {
        DWORD sectionEnd = pSection[i].PointerToRawData + pSection[i].SizeOfRawData;
        if (sectionEnd > maxEnd) maxEnd = sectionEnd;
    }


    UnmapViewOfFile(pBase);
    CloseHandle(hMapping);
    CloseHandle(hFile);
    return maxEnd;
}

Version 1: Heap allocation (for small/medium data)

BYTE* LoadAppendedData(DWORD& outSize, DWORD32 skippedSize)
{
    TCHAR exePath[MAX_PATH] = { 0 };
    GetModuleFileName(NULL, exePath, MAX_PATH);

    DWORD exeSize = GetRealExeSize(exePath);

    DWORD totalSkippedSize = exeSize + skippedSize;

    HANDLE hFile = CreateFile(exePath, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hFile == INVALID_HANDLE_VALUE) return nullptr;

    LARGE_INTEGER fileSize;
    if (!GetFileSizeEx(hFile, &fileSize)) { CloseHandle(hFile); return nullptr; }

    if (fileSize.QuadPart <= totalIgnoredSize) { CloseHandle(hFile); return nullptr; }

    DWORD appendedSize = (DWORD)(fileSize.QuadPart - skippedSize);
    BYTE* data = new BYTE[appendedSize];

    SetFilePointer(hFile, totalSkippedSize , NULL, FILE_BEGIN);
    DWORD bytesRead = 0;
    ReadFile(hFile, data, appendedSize, &bytesRead, NULL);
    CloseHandle(hFile);

    if (bytesRead != appendedSize) { delete[] data; return nullptr; }

    outSize = appendedSize;
    return data;
}

Version 2: Memory-mapped (recommended for large files)

Before declaring the helper function, you should define a structure to store the necessary handles for releasing memory-mapped resources safely:

struct MappedAppendedData
{
    BYTE* mappedView = nullptr;   // Pointer to the full mapped view (used in UnmapViewOfFile)
    BYTE* basePtr = nullptr;      // Offset to where the appended data starts
    size_t totalSize = 0;
    HANDLE hFile = NULL;
    HANDLE hMapping = NULL;
};

// Declare an instance of the structure (ideally as extern if used across multiple files)
MappedAppendedData g_mappedAppendedData;

Now, declare the helper function as follows:

BYTE* LoadAppendedData(MappedAppendedData& mappedDataStruct, DWORD& outSize, DWORD skippedSize)
{
    TCHAR exePath[MAX_PATH] = { 0 };
    GetModuleFileName(NULL, exePath, MAX_PATH);

    DWORD exeSize = GetRealExeSize(exePath);

    DWORD totalSkippedSize = exeSize + skippedSize;

    HANDLE hFile = CreateFile(exePath, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hFile == INVALID_HANDLE_VALUE) return nullptr;

    HANDLE hMapping = CreateFileMapping(hFile, NULL, PAGE_READONLY, 0, 0, NULL);
    if (!hMapping) { CloseHandle(hFile); return nullptr; }

    LPBYTE pBase = (LPBYTE)MapViewOfFile(hMapping, FILE_MAP_READ, 0, 0, 0);
    if (!pBase) { CloseHandle(hMapping); CloseHandle(hFile); return nullptr; }

    LARGE_INTEGER fileSize;
    if (!GetFileSizeEx(hFile, &fileSize)) {
        UnmapViewOfFile(pBase);
        CloseHandle(hMapping);
        CloseHandle(hFile);
        return nullptr;
    }

    DWORD appendedSize = (DWORD)(fileSize.QuadPart - totalSkippedSize);

    if (appendedSize == 0) {
        UnmapViewOfFile(pBase);
        CloseHandle(hMapping);
        CloseHandle(hFile);
        return nullptr;
    }

    mappedDataStruct.mappedView = pBase;
    mappedDataStruct.basePtr = (pBase + totalSkippedSize);
    mappedDataStruct.hFile = hFile;
    mappedDataStruct.hMapping = hMapping;
    mappedDataStruct.totalSize = appendedSize;

    outSize = appendedSize;
    return pBase + totalSkippedSize;
}

Then you will need another function to clean up the mapped memory:

Clean Mapped Memory

void FreeMappedAppendedData(MappedAppendedData& data)
{
    if (data.mappedView)
    {
        UnmapViewOfFile(data.mappedView);
        data.mappedView = nullptr;
        data.basePtr = nullptr;
    }

    if (data.hMapping)
    {
        CloseHandle(data.hMapping);
        data.hMapping = NULL;
    }

    if (data.hFile)
    {
        CloseHandle(data.hFile);
        data.hFile = NULL;
    }

    data.totalSize = 0;
}

⚠️ Deprecated Variant (Simplified)

This is an older, simplified version of the memory mapping function.
It works for quick testing, but does not store or release the file and mapping handles, which can result in serious memory issues.

BYTE* LoadAppendedData(DWORD& outSize, DWORD skippedSize)
{
    TCHAR exePath[MAX_PATH] = { 0 };
    GetModuleFileName(NULL, exePath, MAX_PATH);

    DWORD exeSize = GetRealExeSize(exePath);

    DWORD totalSkippedSize = exeSize + skippedSize;

    HANDLE hFile = CreateFile(exePath, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hFile == INVALID_HANDLE_VALUE) return nullptr;

    HANDLE hMapping = CreateFileMapping(hFile, NULL, PAGE_READONLY, 0, 0, NULL);
    if (!hMapping) { CloseHandle(hFile); return nullptr; }

    LPBYTE pBase = (LPBYTE)MapViewOfFile(hMapping, FILE_MAP_READ, 0, 0, 0);
    if (!pBase) { CloseHandle(hMapping); CloseHandle(hFile); return nullptr; }

    LARGE_INTEGER fileSize;
    if (!GetFileSizeEx(hFile, &fileSize)) {
        UnmapViewOfFile(pBase);
        CloseHandle(hMapping);
        CloseHandle(hFile);
        return nullptr;
    }

    DWORD appendedSize = (DWORD)(fileSize.QuadPart - totalIgnoredSize);
    if (appendedSize == 0) {
        UnmapViewOfFile(pBase);
        CloseHandle(hMapping);
        CloseHandle(hFile);
        return nullptr;
    }

    outSize = appendedSize;
    return pBase + totalSkippedSize;
}

⚠️ Note:

This version does not track or release system handles (HANDLE, MapViewOfFile).

Mapping multiple files with this function can quickly exhaust system resources, leading to ERROR_NOT_ENOUGH_MEMORY (8) or even application instability.

Do not use in production environments.

Later in this guide, I’ll explain how to map all the appended data in memory at once, and how to access each segment by declaring pointers and calculating their respective sizes.

Step 2: Files Size Retrieving

Suppose we now want to embed multiple files into our application—for example, three files appended at the end of the executable.

Let's imagine that the various files have different sizes:

The first file is 153 MB with a size in 160432128 bytes
The second file is 51 MB with a size in 53477376 bytes
The third file is 79 MB with a size in 82837504 bytes

The best way to determine the exact size of the files you want to embed is as follows:

1. Compile the application with the minimal executable (without any appended data).
2. Copy or move the files to be appended to the executable in the build folder (Debug or Release)
3. Open PowerShell in the current folder and run this command: dir

The output will look like this:

    Directory: [Build Directory Path]

Mode     Length       Name
----     ------       ----
-a----   160432128    file1.bin
-a----    53477376    file2.bin
-a----    82837504    file3.bin
-a----    12345678    your_application.exe
-a----    12345678    your_application.pdb

In this way we can note the size of all the various files, copy them or keep the Powershell window open

Step 3: Accessing Embedded Files at Runtime

Once we know the sizes and order of the files to append on the executable, we can access them at runtime by calculating the correct offset and expected size.

The process depends on whether the target file is the first, intermediate, or last in the concatenated bundle.

Example: Appended Files Overview

/*
    Appended files (in order):

    File 1 size: 160,432,128 bytes
    File 2 size:  53,477,376 bytes
    File 3 size:  82,837,504 bytes
*/

Accessing the First Appended File (Simplest Case)

Offset is zero. If LoadAppendedData gives you the full remaining data, you must subtract the sizes of the files that come after.

DWORD embedded_data_size = 0;
BYTE* embedded_data = LoadAppendedData(embedded_data_size, 0);

// Adjust to only include the first file
embedded_data_size -= (fileSize2 + fileSize3);

Accessing the Last Appended File (Simplest Case)

Only sum the sizes of the files that come before it to calculate the offset. You don't need to subtract anything.

DWORD embedded_data_size = 0;
DWORD offset = (fileSize1 + fileSize2);

BYTE* embedded_data = LoadAppendedData(embedded_data_size, offset);

// embedded_data_size is automatically the size of File 3 (last file)

Accessing a File in the Middle

To access a file that has others before and after it, you need to:

1. Add the sizes of the files that come before it → this gives you the correct offset
2. Subtract the sizes of the files that come after it

→ This is required to determine the correct size, unless LoadAppendedData handles the size internally

DWORD embedded_data_size = 0;
DWORD offset = fileSize1;

BYTE* embedded_data = LoadAppendedData(embedded_data_size, offset);

// Remove trailing files to isolate only File 2
embedded_data_size -= fileSize3;

⚠️ Important: ALWAYS remember to call delete whenever the pointer pointing to the added data is no longer needed to avoid memory leaks if you are using the heap

⚠️ Tip: To be better and to avoid confusion, enter the size of each file in the order in which they will be appended.

ℹ️ Tip: Obviously replace fileSize1, fileSize2 and fileSize3 with the various sizes of our files that will be appended, there can be even more than three

✅ General Rule

To access a specific file from a concatenated bundle, you need to know:

"How much to skip (offset = sum of previous files)"

"How much to read (size = total size − sum of following files)"

Then pass these to LoadAppendedData.

🔁 This logic doesn't change, no matter how many files are appended.

💡 Optional Tip

To make this robust, define constants or an array of sizes:

const DWORD fileSizes[] = { fileSize1, fileSize2, fileSize3 };

DWORD GetOffset(int fileIndex) {
    DWORD offset = 0;
    for (int i = 0; i < fileIndex; ++i)
        offset += fileSizes[i];
    return offset;
}

DWORD GetSize(int fileIndex) {
    DWORD size = 0;
    for (int i = fileIndex + 1; i < std::size(fileSizes); ++i)
        size += fileSizes[i];
    return fileSizes[fileIndex]; // or subtract from total if needed
}

Improved method for memory mapping

The updated LoadAppendedData() now uses a MappedAppendedData struct to manage system resources safely.

This allows cleanup of all mapped appended data at once using FreeMappedAppendedData().

The offset and size logic remains the same as previously described (see Step 3).

📌 Alternative Access Strategy

Instead of calculating each appended file’s size by subtracting the sizes of subsequent files, you can:

Manually specify file sizes, if already known.
Use pointer arithmetic to locate each file by summing the sizes of the previous ones.

This method is cleaner and more efficient when all appended file sizes are known in advance.

✅ Example

// Global or extern pointer to the full appended data block
DWORD fullAppendedDataSize = 0;
BYTE* dataPtr = nullptr;

// Map the entire appended section once (after the executable)
dataPtr = LoadAppendedData(g_mappedAppendedData, fullAppendedDataSize, 0);

// Known file sizes (in bytes)
const DWORD fileSize1 = 160432128;
const DWORD fileSize2 = 53477376;
const DWORD fileSize3 = 82837504;

// Access each file using pointer arithmetic
const BYTE* file1 = dataPtr;                          // First file
const BYTE* file2 = dataPtr + fileSize1;              // Second file
const BYTE* file3 = dataPtr + (fileSize1 + fileSize2);  // Third file

// Clean up mapped memory and handles when done
// FreeMappedAppendedData(g_mappedAppendedData);

This approach eliminates the need for runtime size calculations and is most effective when the sizes of the appended files are known or fixed.

You can also expose global pointers using extern declarations in a dedicated header file, allowing both the appended data and the helper functions to be accessed throughout the application.

In both scenarios, resource handling is centralized through the MappedAppendedData structure, which can be cleanly released at any time with a single call to FreeMappedAppendedData().

💡 Bonus: Check the integrity of appended files

Verify the integrity of the added files by adding their sizes and comparing the total to the size returned by the LoadAppendedData function. If they don't match, tampering may have occurred.

Here is a practical example:

const DWORD expectedAppendedDataSize = (fileSize1 + fileSize2 + fileSize3); // sum of all appended files

if (expectedAppendedDataSize != fullAppendedDataSize)
{
    // Possible tampering detected — take appropriate action or close the application
}

Additionally, you can check the validity of pointers that reference the added data by updating the condition to also check for null pointers:

if (!file1 || !file2 || !file3 || expectedAppendedDataSize != fullAppendedDataSize)
{
    // Possible tampering detected — take appropriate action or close the application
}

If the application is also protected with an Authenticode signature, include its size in the total:

 DWORD signSize = GetAuthenticodeSignatureSize();

 const DWORD expectedAppendedDataSize = (fileSize1 + fileSize2 + fileSize3) + signSize; // Also add the size of the signature

The GetAuthenticodeSignatureSize function below returns the size of the Authenticode signature, if present, and can be used to avoid false positives.

⚠️ Note: This technique only detects coarse tampering, such as deleting, truncating, or adding files. It does not verify the integrity of the file content itself. For more effective protection, I recommend using cryptographic hashes or digital signature integrity checks.

Step 4: Binary File Concatenation

Once the application has been compiled, open a Command Prompt in the build directory and run the following command to append the binary files expected by the application:

copy /b stub.exe + file1.bin + file2.bin + file3.bin final_stub.exe

This command creates a new executable (final_stub.exe) that contains the original application followed by the three binary files appended in order.

At this point, the files have been embedded into the executable, and the application is ready to be tested.

Comparison of Memory Mapping Access Strategies

Aspect	Version 1 (single offset)	Version 2 (full mapping)
Data loaded	Only the required portion	Entire appended section
Handling multiple files	Need to calculate offset for each file	Pointer arithmetic allows direct access
Complexity	Flexible for single-file access	Efficient for accessing all files
Resources	Lower memory usage	Uses more memory but avoids multiple mappings
Updating `embedded_data_size`	Requires trimming	Not needed, file sizes are known

Key Differences

Version 1: maps one file at a time. Flexible for single-file access, but impractical for multiple files due to increased mappings, memory leaks risk, and virtual address fragmentation.
Version 2: maps all appended data at once. Allows pointer arithmetic to access any file, centralized cleanup via FreeMappedAppendedData(), and is simpler to manage. Slightly higher memory usage is the trade-off.

Recommendation for 32-bit Applications

Prefer Version 2 to avoid virtual address fragmentation and ensure stable access to all files.
Ensure total appended data stays under 4 GB, or compile with the LARGEADDRESSAWARE flag to increase the virtual address space from 2 GB to 4 GB.

⚠️ Memory Mapping Pitfalls in 32-bit Applications

I found that repeatedly calling LoadAppendedData (using the deprecated helper function) and declaring multiple BYTE* pointers to map different sections eventually caused a system error after loading approximately 600 MB of data.

As mentioned earlier, this led to an ERROR_NOT_ENOUGH_MEMORY (8) due to unreleased memory-mapped handles.

⚠️ While this issue typically doesn’t occur in 64-bit processes, it can become a serious limitation in 32-bit applications, where virtual address space is constrained.

✅ Why a Single Memory Mapping is Better

One key advantage of using a single memory-mapped block (via MappedAppendedData) is that it is more efficient and manageable in both design and cleanup.

Without this approach, you would need to:

Declare one instance of MappedAppendedData for each appended file;
Manually call FreeMappedAppendedData() on each instance to release its resources (mapped view, handles, memory).

This adds complexity and increases the risk of resource leaks — especially when working with multiple files.

In contrast, with a single memory-mapped block, you can:

Map all appended data at once;
Simply declare BYTE* pointers and calculate offsets to access each embedded file;
Call FreeMappedAppendedData() just once, making memory management significantly easier and safer.

✅ Using a single MappedAppendedData structure for all appended content is not only more efficient — it also results in cleaner, more maintainable code.

Otherwise, you'd need one struct per file and call FreeMappedAppendedData() on each, increasing the risk of memory/resource leaks.

🧠 Summary

❌ Avoid repeated memory mappings without freeing them — especially in 32-bit applications.
✅ Prefer a single, centralized memory-mapped block.
✅ Always free resources using FreeMappedAppendedData() once done.

⚠️ Warning: Authenticode Signature and Appended Data

If you add binary data to the executable after compilation and before signing, be aware that applying an Authenticode signature (e.g., with signtool.exe) will slightly bloat the final executable. This may corrupt the binary files appended after the executable, or shift their offsets, making them unreadable at runtime.

To ensure correct offset calculation and avoid accidental inclusion of the Authenticode signature in your embedded data:

Before reading all the appended binary content, subtract the size of the Authenticode signature.

Here is a helper function to obtain the size of the embedded Authenticode signature:

DWORD GetAuthenticodeSignatureSize()
{
    HMODULE hModule = GetModuleHandle(nullptr);
    if (!hModule)
        return 0;

    PIMAGE_DOS_HEADER pDosHeader = reinterpret_cast<PIMAGE_DOS_HEADER>(hModule);

    if (pDosHeader->e_magic != IMAGE_DOS_SIGNATURE)
        return 0;

    PIMAGE_NT_HEADERS pNtHeaders = reinterpret_cast<PIMAGE_NT_HEADERS>(
        reinterpret_cast<BYTE*>(hModule) + pDosHeader->e_lfanew);

    if (pNtHeaders->Signature != IMAGE_NT_SIGNATURE)
        return 0;

    const IMAGE_DATA_DIRECTORY& certDir =
        pNtHeaders->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_SECURITY];

    return certDir.Size;
}

Use the returned size to adjust your file offset before extracting or reading embedded binary data:

DWORD embedded_data_size = 0;
DWORD offset = fileSize1 + fileSize2;
DWORD signSize = GetAuthenticodeSignatureSize(); // Returns the Authenticode signature size from the helper function

BYTE* embedded_data = LoadAppendedData(embedded_data_size, offset);

embedded_data_size -= signSize; // Exclude signature from the tail

⚠️ Warning : When calculating the size of previous files to access a specific file in memory, you must always subtract the size of the Authenticode signature. This is true even if, technically, the Authenticode signature is located immediately after the last file appended.

🔄 Tip : If you use pointer arithmetic on the added files and define the size of each file in a dedicated variable, you will not need to subtract the length of the Authenticode digital signature unless you perform runtime tampering checks.

This step is not mandatory but it is recommended if you want to keep everything clean and avoid working with extra useless signature, it is however advisable to subtract the size of the signature always to exclude it from the actual total size of the appended files to avoid discrepancies

✅ Why This Matters

Authenticode signatures live outside the PE sections, in a structure called WIN_CERTIFICATE, appended at the file's end.
If you read embedded content from the end of the file without accounting for the signature, you'll include that signature garbage, corrupting your parsing logic.
This issue is especially relevant when:
- Using copy /b stub.exe + file.bin final_stub.exe
- Loading or mapping data from the tail of a signed executable

How does this method work?

The core idea is to first determine the size of the clean executable, meaning the actual size defined by the PE structure (i.e. the end of the last section). For this, we use a function that parses the PE header and finds where the real executable content ends.

Once we know the original executable size:

The first appended file starts exactly after this point.
To retrieve a file in the middle, we calculate its offset by summing the sizes of all files before it.
To determine its size, we subtract the sizes of all the files appended after it (unless the function handles this internally).

This logic is simple, scalable, and does not require any metadata or markers inside the executable — just plain math using file sizes.

⚖️ Pros and Cons of This Approach

✔️ Advantages

Simple: No need for custom file formats, headers, or metadata
Clean: No need to modify the PE structure or embed resources
Scalable: Works with any number of appended files
Self-contained: All files are bundled into a single executable
Portable: No dependencies or external tools required at runtime

❌ Disadvantages

Fragile: Any mismatch in size or order breaks data access
No autodetection: You must hardcode or externally manage offsets and sizes
No security: Appended data can be easily extracted or modified
No integrity checks: Corruption or tampering is not detectable by default
Sensitive to signing: Authenticode signatures alter the file size and must be accounted for

✅ When to Use This

This method is ideal for:

Internal tools or portable utilities
Controlled environments
Self-extracting utilities or installers
Situations where simplicity and size matter more than security

It is not recommended for:

Untrusted or public distribution scenarios
Applications that require data integrity or confidentiality
Systems needing runtime discoverability or flexibility

🛡️ How to Make It More Robust

To mitigate the risks and improve reliability, consider:

Adding a small metadata block (e.g. magic number, count, size table)
Using hashes or checksums for each embedded file
Encrypting sensitive data before appending
Signing the executable after appending data, and adjusting for signature size in the reader

🔐 Further Reading

If you want to enhance this method by adding integrity checks and validation, check out the follow-up article:

🔗 How to Protect Binary Data Appended into an Executable and Validate it with a Digital Signature

It explains how to prevent tampering by using digital signatures, providing a much stronger foundation for production use.

In summary, this technique offers a clean, zero-overhead way to append and load multiple binary resources directly from your executable. It shines in simplicity and flexibility — but like all minimalist solutions, it comes with trade-offs in safety and robustness.

🔁 Important: Using markers may seem convenient for a few files, but it quickly becomes unmanageable as the number of files grows. Each file would require its own marker, resulting in increased complexity and error potential.

🧠 Unlike other approaches that use metadata structures to describe embedded files (e.g., names, offsets, sizes), this method relies only on a priori known offsets and sizes, making it simpler, more robust, and free of parsing or complex logic.

This method, on the other hand, is scalable, deterministic, and cleaner, making it ideal even for dozens of embedded files.

Adapt it wisely to your context!

Conclusion

In this article we've explored a straightforward and reliable method to embed and access multiple binary files appended sequentially to a Windows executable — all without relying on additional markers, headers, or metadata.

By understanding the real size of the executable (based on PE section data) and applying simple arithmetic with the sizes of the appended files, you can calculate offsets and sizes to correctly extract each embedded file at runtime.

How to Protect Binary Data Appended into an Executable and Validate it with a Digital Signature

Stefor07 — Thu, 19 Jun 2025 15:42:45 +0000

In this article, we'll walk through a method to append arbitrary binary data to a .exe file and protect it with a digital signature, ensuring that any tampering with the file (including the appended data) invalidates the signature.

This technique is an enhancement of the fourth method detailed in our previous article:

Previous Article: How to Embed Binary Data into a Win32 Executable File in 4 Methods

We’ll also implement a runtime integrity check within the application to verify that the executable hasn't been altered after signing.

⚠️ This guide is more effective in the fourth method explained in the last article, useful to better protect the data appended at the end of the executables

Step 1: Creating Authenticode Signature Certificate

Open PowerShell for Visual Studio Developer Command Prompt and run the following command to create a self-signed certificate for local testing:

$cert = New-SelfSignedCertificate -DnsName "certName" -CertStoreLocation "cert:\CurrentUser\My" -Type CodeSigning -KeyUsageProperty Sign -KeyUsage CertSign -KeySpec Signature -KeyExportPolicy Exportable

This command will create a certificate in your user area, valid only for local testing

💡 Replace certName with a name of your choice to easily identify the certificate.

Exporting the `.pfx` certificate (Recommended)

Now declare a password to export the certificate securely:

$password = ConvertTo-SecureString "yourPW" -AsPlainText -Force

🔒 Replace yourPW with your actual password.

Retrieve the existing certificate from the CurrentUser store based on its Common Name (CN)

$cert = Get-ChildItem -Path Cert:\CurrentUser\My | Where-Object { $_.Subject -like "*CN=certName*" }

Export the certificate to a .pfx file:

Export-PfxCertificate -Cert $cert.PSPath -FilePath "C:\Path\of\Your\Cert.pfx" -Password $password

ℹ️ Notify: Exporting the .pfx certificate is not absolutely mandatory, but it is a safe way to always have a backup copy since it contains the private key to sign the executables.

Step 2: Retrieve Certificate Thumbprint

To get the thumbprint of your certificate, run:

Get-ChildItem -Path Cert:\CurrentUser\My | Format-List Subject, Thumbprint

Example output:

Subject    : CN=certName
Thumbprint : A1B2C3D4E5F67890ABCDEF1234567890ABCDEF12

Copy the Thumbprint, as you’ll use it later in your C++ code for validation.

Step 3: Implement Runtime Signature Verification in Visual C++

Now in our application code we should import two libraries in the source file that handles the startup and declare a helper functions that will allow us to get the signature thumbprint

Add the following to your main application source file:

Standard Win32 APIs Version:

#include "windows.h"
#include <wintrust.h>
#include <softpub.h>

// Link the necessary libraries
#pragma comment(lib, "crypt32.lib")
#pragma comment(lib, "wintrust.lib")

bool VerifyAuthenticodeSHA1Signature(LPCWSTR filePath)
{
    WINTRUST_FILE_INFO fileInfo = {};
    fileInfo.cbStruct = sizeof(WINTRUST_FILE_INFO);
    fileInfo.pcwszFilePath = filePath;

    GUID policyGUID = WINTRUST_ACTION_GENERIC_VERIFY_V2;

    WINTRUST_DATA winTrustData = {};
    winTrustData.cbStruct = sizeof(WINTRUST_DATA);
    winTrustData.dwUIChoice = WTD_UI_NONE;
    winTrustData.fdwRevocationChecks = WTD_REVOKE_NONE;
    winTrustData.dwUnionChoice = WTD_CHOICE_FILE;
    winTrustData.pFile = &fileInfo;
    winTrustData.dwStateAction = WTD_STATEACTION_IGNORE;
    winTrustData.dwProvFlags = WTD_REVOCATION_CHECK_NONE;
    winTrustData.dwUIContext = 0;

    LONG status = WinVerifyTrust(NULL, &policyGUID, &winTrustData);

    if (status == ERROR_SUCCESS)
        return true;

    if (status == TRUST_E_BAD_DIGEST || status == TRUST_E_PROVIDER_UNKNOWN)
        return false;

    if (status == CERT_E_UNTRUSTEDROOT)
        return true;

    return false;
}

bool VerifySignatureThumbprint(LPCWSTR filePath, const LPCWSTR& expectedThumbprint)
{
    DWORD contentType = 0;
    DWORD formatType = 0;
    HCERTSTORE hStore = NULL;
    HCRYPTMSG hMsg = NULL;

    BOOL res = CryptQueryObject(
        CERT_QUERY_OBJECT_FILE,
        filePath,
        CERT_QUERY_CONTENT_FLAG_PKCS7_SIGNED_EMBED,
        CERT_QUERY_FORMAT_FLAG_BINARY,
        0,
        nullptr,
        &contentType,
        &formatType,
        &hStore,
        &hMsg,
        nullptr
    );

    if (!res || !hStore) {
        if (hStore) CertCloseStore(hStore, 0);
        if (hMsg) CryptMsgClose(hMsg);
        return false;
    }

    PCCERT_CONTEXT pCert = CertEnumCertificatesInStore(hStore, nullptr);
    if (!pCert) {
        CertCloseStore(hStore, 0);
        CryptMsgClose(hMsg);
        return false;
    }

    BYTE hash[20]; // SHA1 produces 20-byte hash
    DWORD hashSize = sizeof(hash);

    if (!CryptHashCertificate(
        NULL,
        CALG_SHA1,
        0,
        pCert->pbCertEncoded,
        pCert->cbCertEncoded,
        hash,
        &hashSize))
    {
        CertFreeCertificateContext(pCert);
        CertCloseStore(hStore, 0);
        CryptMsgClose(hMsg);
        return false;
    }

    // Convert hash to hex string (ANSI)
    LPCWSTR computedThumbprint;
    for (DWORD i = 0; i < hashSize; ++i) {
        char szHex[5];
        sprintf_s(szHex, "%02X", hash[i]);
        computedThumbprint += szHex;
    }

    CertFreeCertificateContext(pCert);
    CertCloseStore(hStore, 0);
    CryptMsgClose(hMsg);

    return (computedThumbprint.compare(expectedThumbprint) == 0);
}

If you are currently using the MFC Framework, this is the same function adapted

MFC Version:

#include "afxwin.h"
#include <wintrust.h>
#include <softpub.h>

// Link the necessary libraries
#pragma comment(lib, "crypt32.lib")
#pragma comment(lib, "wintrust.lib")

bool VerifyAuthenticodeSHA1Signature(const CStringW& filePath)
{
    WINTRUST_FILE_INFO fileInfo = {};
    fileInfo.cbStruct = sizeof(WINTRUST_FILE_INFO);
    fileInfo.pcwszFilePath = filePath;

    GUID policyGUID = WINTRUST_ACTION_GENERIC_VERIFY_V2;

    WINTRUST_DATA winTrustData = {};
    winTrustData.cbStruct = sizeof(WINTRUST_DATA);
    winTrustData.dwUIChoice = WTD_UI_NONE;
    winTrustData.fdwRevocationChecks = WTD_REVOKE_NONE;
    winTrustData.dwUnionChoice = WTD_CHOICE_FILE;
    winTrustData.pFile = &fileInfo;
    winTrustData.dwStateAction = WTD_STATEACTION_IGNORE;
    winTrustData.dwProvFlags = WTD_REVOCATION_CHECK_NONE;
    winTrustData.dwUIContext = 0;

    LONG status = WinVerifyTrust(NULL, &policyGUID, &winTrustData);

    if (status == ERROR_SUCCESS)
        return true;

    if (status == TRUST_E_BAD_DIGEST || status == TRUST_E_PROVIDER_UNKNOWN)
        return false;

    if (status == CERT_E_UNTRUSTEDROOT)
        return true;

    return false;
}

bool VerifySignatureThumbprint(CStringW filePath, const CStringW& expectedThumbprint)
{
    DWORD contentType = 0;
    DWORD formatType = 0;
    HCERTSTORE hStore = NULL;
    HCRYPTMSG hMsg = NULL;

    BOOL res = CryptQueryObject(
        CERT_QUERY_OBJECT_FILE,
        filePath.GetString(),
        CERT_QUERY_CONTENT_FLAG_PKCS7_SIGNED_EMBED,
        CERT_QUERY_FORMAT_FLAG_BINARY,
        0,
        NULL,
        &contentType,
        &formatType,
        &hStore,
        &hMsg,
        NULL
    );

    if (!res) {
        return false;
    }

    PCCERT_CONTEXT pCert = CertEnumCertificatesInStore(hStore, NULL);
    if (!pCert) {
        CertCloseStore(hStore, 0);
        CryptMsgClose(hMsg);
        return false;
    }

    BYTE hash[20];
    DWORD hashSize = sizeof(hash);

    if (!CryptHashCertificate(
        NULL,
        CALG_SHA1,
        0,
        pCert->pbCertEncoded,
        pCert->cbCertEncoded,
        hash,
        &hashSize))
    {
        CertFreeCertificateContext(pCert);
        CertCloseStore(hStore, 0);
        CryptMsgClose(hMsg);
        return false;
    }

    CStringW computedThumbprint;
    for (DWORD i = 0; i < hashSize; i++) {
        CString hexByte;
        hexByte.Format(_T("%02X"), hash[i]);
        computedThumbprint += hexByte;
    }

    CertFreeCertificateContext(pCert);
    CertCloseStore(hStore, 0);
    CryptMsgClose(hMsg);

    return (computedThumbprint.CompareNoCase(expectedThumbprint) == 0);
}

Now, in the body of your application's entry point, add this to check if at least one condition is false

main.cpp

int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hInstPrev, LPSTR cmdline, int cmdshow)
{
   wchar_t wExePath[MAX_PATH];

   GetModuleFileNameW(NULL, wExePath, MAX_PATH);

   // Now using the helper functions we check if the signature has been invalidated

   if (!VerifySignatureThumbprint(wExePath, L"A1B2C3D4E5F67890ABCDEF1234567890ABCDEF12") || !VerifyAuthenticodeSHA1Signature(wExePath))
   {
      // Invalidated signature, show error message and prevent execution for security
      MessageBoxA(0, "Unable to verify application integrity, click OK to terminate the application now", "Error", MB_ICONERROR | MB_OK);
      return 1;
   }

   // The rest of your code here...
}

⚠️ Replace A1B2C3D4E5F67890ABCDEF1234567890ABCDEF12 with the Thumbprint founded previously

At this point, we have implemented a runtime integrity check in our application. If even a single byte is tampered with, the application will refuse to run.

Step 4: Append Binary Data to the Executable

Open Command Prompt (not PowerShell) in your build folder and run:

copy /b original.exe + file.bin final.exe

original.exe: your compiled executable
file.bin: binary data to append
final.exe: final executable with appended data

✅ The added data does not interfere with the PE format, and execution is unaffected.

Step 5: Sign the Final Executable

Once ready, run the following command from Powershell Developer for VS and sign the final.exe using the certificate:

signtool sign /n certName /fd SHA1 .\final.exe

ℹ️ certName should match the name used when generating the certificate.

⚠️ Note on signtool:

The signtool utility is part of the Windows SDK and is not available by default in standard PowerShell or CMD. To use it:

Open a Developer Command Prompt for Visual Studio (like x64 Native Tools Command Prompt)

Or manually add the path to signtool.exe in your system's PATH environment variable

Now, if any part of the file is modified—including the appended data—the signature becomes invalid, and the application will reject execution.

Optional: Automate via Visual Studio Post-Build Events

Save time by automating the append and signing steps after each build.

Steps:

1. In Visual Studio, go to Project > Properties
2. Navigate to Build Events > Post-Build Event
3. Add the following to the Command Line field:

Add these two command lines:

copy /b /y "$(TargetPath)" + "$(TargetDir)file.bin" "$(TargetDir)final.exe"
signtool sign /n certName /fd SHA1 "$(TargetDir)final.exe"

Then after you will have to insert in the compilation folder, whether Debug or Release, the binary file that we will have to concatenate to the end of the executable

Click Apply and OK to apply the changes

Each time you compile, the binary data will be automatically appended and the resulting executable signed.

🔐 Security Note: The Role of the `.pfx` File

Even though it’s possible to export the public part of a certificate (as a .cer file), this is not sufficient to re-sign the executable.

✅ The .pfx file contains the private key, which is mandatory to sign executables.

Without the .pfx:

You cannot apply a valid signature, even if you have the .cer.
An attacker cannot re-sign a tampered executable unless they have access to the original .pfx.

This guarantees that the appended data, once signed, is secure against external modifications. If someone tries to alter the executable—even with the correct .cer—they won’t be able to restore a valid signature.

And even if someone manages to obtain the .pfx file, they would still need to know the associated password in order to import and use it—making the certificate even more secure.

🧷 For production, the .pfx should be securely stored and access to it strictly limited.

⚠️ About .CER Exports

⚠️ Important Note: If you export a .CER file from a signed .exe using Windows UI, it contains only the public certificate.
It cannot be used to re-sign files, export a .pfx, or recover the private key.
Signing requires access to the original .pfx file created with the private key.

Summary Table

Format	Contains Private Key?	Can Be Used to Sign?	Exportable from `.exe`?
`.cer`	❌ No	❌ No	✅ Yes
`.pfx`	✅ Yes	✅ Yes	❌ No

Final Notes

This method ensures data appended to an executable is tamper-proof via Authenticode.
- The application checks its own integrity at runtime, stopping execution if the signature is invalid.
- Ideal for embedding secure files or configuration data that must not be altered after distribution.

Conclusion

In this article, we demonstrated how to append binary data, such as ZIP archives, to a Windows executable and protect it using an Authenticode digital signature. This method ensures that any modification to the file—whether to the executable code or the appended data—invalidates the digital signature, allowing the application to detect tampering at runtime.

A key point concerns attached ZIP files: before signing, tools like 7-Zip can freely read and modify the embedded ZIP archive. However, once the executable is signed, any modification to the file, including the attached ZIP, will invalidate the signature and prevent 7-Zip or similar tools from accessing or modifying the archive. (Once the executable is signed, 7-Zip will not be able to let us modify the attached ZIP)

The only way to modify the appended ZIP is to manually extract the executable and the appended ZIP separately, make changes, and then recombine them manually (for example, using copy /b). But this process breaks the signature and causes the application’s integrity check to fail, rendering it unusable.

This protection guarantees that the data appended to the executable remains intact and secure, providing an effective barrier against unauthorized tampering.

To maintain this security, it’s critical to carefully store the .pfx file containing the private key used for signing, restricting its access strictly.

How to develop a basic MFC Application in Visual C++ using a Dialog Box

Stefor07 — Fri, 16 May 2025 19:44:27 +0000

This guide walks you through creating a basic MFC desktop application using Visual C++, starting from scratch and using a dialog box as the main interface.

📦 Step 1: Create a New Project in Visual Studio

Open Visual Studio.
Go to File > New > Project....
In the template list, select Windows Desktop Wizard.

Name the project and click OK.
In the next screen:
- Application type: select Desktop application
- Check Empty Project to start from scratch.

⚙️ Step 2: Enable MFC Support

To use MFC (Microsoft Foundation Classes):

Right-click the project in Solution Explorer and select Properties.
Navigate to:

   Project Properties > Configuration Properties > General

Set Use of MFC to:
- Use MFC in a Static Library.
Click Apply, then OK.

🧱 Step 3: Create the Main Application Class (`Main`)

This class represents the entry point for the application.

➤ Add the Header File

Right-click on Header Files > Add > New Item
Choose Header File (.h) and name it Main.h.

   #pragma once
   #include "afxwin.h"

   class Main : public CWinApp {
   public:
       BOOL InitInstance();
   };

➤ Add the Source File

Right-click on Source Files > Add > New Item.
Select C++ File (.cpp) and name it Main.cpp.

   #include "afxwin.h"
   #include "Main.h"
   #include "CMainDlg.h"  // To be created later

   Main app;

   BOOL Main::InitInstance() {
       CMainDlg dlg;
       m_pMainWnd = &dlg;
       dlg.DoModal();
       return TRUE;
   }

🧩 Step 4: Add a Dialog Box Resource

Right-click Resource Files > Add > Resource.
Select Dialog and click New.
A dialog template named IDD_DIALOG1 will appear in the editor.

You can customize the dialog using the toolbox, adding buttons, labels, etc.

🧾 Step 5: Create the Dialog Class

Right-click on the dialog template and select Add Class....
Name the class CMainDlg.
This will generate two files:
- CMainDlg.h
- CMainDlg.cpp

➤ Edit `CMainDlg.h`

Make sure it includes the necessary header:

#pragma once
#include "afxdialogex.h"

class CMainDlg : public CDialogEx {
public:
    CMainDlg(CWnd* pParent = nullptr); // Constructor

#ifdef AFX_DESIGN_TIME
    enum { IDD = IDD_DIALOG1 };
#endif

protected:
    virtual void DoDataExchange(CDataExchange* pDX);

    DECLARE_MESSAGE_MAP()
};

➤ Edit `CMainDlg.cpp`

Ensure this file includes the resources header and links to the dialog ID:

#include "resource.h"
#include "CMainDlg.h"

IMPLEMENT_DYNAMIC(CMainDlg, CDialogEx)

CMainDlg::CMainDlg(CWnd* pParent /*=nullptr*/)
    : CDialogEx(IDD_DIALOG1, pParent) {}

void CMainDlg::DoDataExchange(CDataExchange* pDX) {
    CDialogEx::DoDataExchange(pDX);
}

BEGIN_MESSAGE_MAP(CMainDlg, CDialogEx)
END_MESSAGE_MAP()

🎨 Step 6: (Optional) Enable Windows Visual Styles

To make your application use modern Windows controls:

Right-click the project and select Add > New Item.
Choose XML File, name it app.manifest.
Paste the following into the file:

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
     <dependency>
       <dependentAssembly>
         <assemblyIdentity 
           type="win32" 
           name="Microsoft.Windows.Common-Controls" 
           version="6.0.0.0" 
           processorArchitecture="*" 
           publicKeyToken="6595b64144ccf1df" 
           language="*" />
       </dependentAssembly>
     </dependency>
     <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
       <security>
         <requestedPrivileges>
           <requestedExecutionLevel level="asInvoker" uiAccess="false"/>
         </requestedPrivileges>
       </security>
     </trustInfo>
   </assembly>

This enables high-DPI support and modern UI styles for controls like buttons.

▶️ Step 7: Run the Application

Build the project (Ctrl + Shift + B).
Run the application with Ctrl + F5.
The dialog box should appear as the main window.

✅ What's Next?

Now that you have a basic MFC app running with a dialog, you can:

Add buttons, text boxes, combo boxes, etc.
Handle events like button clicks with ON_BN_CLICKED macros.
Store user input using UpdateData(TRUE/FALSE).

📺 Related Video

💬 Questions or improvements? Fork this guide or leave a comment in your repo!

VirtualBox Web Installer

Stefor07 — Fri, 09 May 2025 09:37:15 +0000

Install VirtualBox the easy way — fully automated, zero hassle.

VirtualBox Web Installer is a lightweight and automated alternative installer for Oracle VirtualBox, designed for Windows users who want a quick and error-free setup with no manual steps.

🚀 What is VirtualBox Web Installer?

VirtualBox Web Installer is a custom-made utility that automates the process of downloading and installing the latest version of Oracle VirtualBox.

It uses a passive user interface, meaning you simply run the installer, and it takes care of the rest — no dialogs, no choices, no interruptions.

✨ Key Features

✅ Fully Automated Installation

No manual steps, configuration dialogs, or clicks required — it just works.
🎯 Clean and Minimal UI

Designed to be straightforward and error-resistant for all user levels.
🧠 Smart Compatibility Checks

Automatically verifies system requirements and compatibility before proceeding.
🔄 Auto-Update Support

Detects if a newer version of VirtualBox is available and updates it automatically.
🔐 Secure

Downloads the official installer directly from ufficial VirtualBox servers, ensuring safety.
💡 Windows Compatibility

Supported on Windows Server 2016 and later, including Windows 10 and 11.

📥 How to Install

Download the installer from the link below.
Run it as administrator (right-click > "Run as administrator").
It will automatically check your system, download the latest VirtualBox version, and install it.
Once finished, VirtualBox will be ready to use.

🛠️ No user interaction required — just launch and let it do the work.

📌 Changelog

✔️ Added update functionality

Automatically installs new versions of VirtualBox when available.
🛑 Cancel confirmation prompt

A confirmation dialog now appears to prevent accidental cancellation during setup.
🧩 MSI Extraction: The MSI is correctly extracted by the official VirtualBox installer and its integrity is always verified
❌ Removed: Removed personal FTP download to comply with Oracle redistribution policies.
✔️ Improved message window: The message window has been improved by adding an extra field at the bottom that specifies the precise information of a message and adding colors for the message type.

⬇️ Download

Latest version: VirtualBox 7.2.6

👉 Download VirtualBox Web Installer

⚠️ Make sure to run the installer with administrator privileges for a successful installation.

The installer now fetches VirtualBox exclusively from official Oracle servers. The software is not redistributed, but simply installed automatically, in compliance with the PUEL license.

📬 Feedback and Support

Have a suggestion, found a bug, or want to request a new feature? Leave a comment below.

Don't hesitate to contact us or file a bug report.

Thanks for choosing VirtualBox Web Installer!

Making VirtualBox installation easier, faster, and more reliable.

Visual C++ MFC Dialog Application Templates for Visual Studio

Stefor07 — Wed, 30 Apr 2025 19:14:59 +0000

Visual C++ MFC Dialog Application Templates are simple ZIP archives that are a project template to start efficiently developing an application in MFC with a dialog window already pre-configured as the main window.

The templates are available for Visual Studio versions 2019 and 2022

Template Installation

Installing these templates is very simple, first of all you need to download one of the two ZIP files for the corresponding version of Visual Studio

Download Links:

After downloading it, you simply need to copy the ZIP file into the following directory:

If you are using Visual Studio 2019:

C:\Users\<Username>\Documents\Visual Studio 2019\Templates\ProjectTemplates\Visual C++

If you are using Visual Studio 2022:

C:\Users\<Username>\Documents\Visual Studio 2022\Templates\ProjectTemplates\Visual C++

OK, now you can open Visual Studio and see if the new project template is shown (to see it you will have to search for it in the search bar)

⚠️ Troubleshooting – Can’t find the template ⚠️

If the template doesn’t appear in the list, follow these steps:

Open the Developer Command Prompt for your version of Visual Studio (2019 or 2022).
Run the following command to update Visual Studio’s configuration:

devenv /updateconfiguration

Restart Visual Studio.

After this step you should be able to find the project template when you reopen Visual Studio

Template Project Preview

When creating a new project using the template, Visual Studio will load a source file for the main application dialog:

To design the dialog interface, open the resource named IDD_Main:

From here you can add controls to create your own application

How to Force Enable 3D Acceleration in VMware Workstation/Fusion

Stefor07 — Sat, 19 Apr 2025 11:01:10 +0000

Sometimes, when installing VMware Workstation Pro/Player on slightly dated or medium-low range PCs, you may encounter an annoying warning message during installation. This message informs you that your host does not support 3D acceleration, and proceeding with the installation will result in the same warning every time a virtual machine (VM) is started, with 3D effects being disabled.

This guide will show you how to resolve this issue by modifying the configuration file.

Problem Resolution

Step 1: Shut Down All VMs and Close VMware

Ensure that no virtual machines are running and that VMware Workstation/Fusion is completely closed. Modifying the configuration file while the application is running may result in changes being overwritten.

Step 2: Locate the `preferences.ini`

Windows:

C:\Users\USERNAME\AppData\Roaming\VMware

Replace <USERNAME> with your actual Windows username.

Linux:

~/.config/vmware

MacOS:

~/Library/Preferences/VMware

Step 3: Edit the `preferences.ini` file

Open the preferences.ini file using a text editor (e.g., Notepad on Windows, nano or vim on Linux/macOS). Add the following lines at the end of the file:

Entering this directory you will find the preferences.ini file, which will be the VMware Workstation/Fusion configuration

Now open the file with a text editor and paste these three lines:

mks.enableMTLRenderer = "0"
mks.enableGLRenderer = "1"
mks.gl.allowBlacklistedDrivers = "TRUE"

Explanation of Settings:

mks.enableMTLRenderer = "0": Disables the Metal renderer (used on macOS) and forces OpenGL rendering.
mks.enableGLRenderer = "1": Enables OpenGL-based rendering for 3D acceleration.
mks.gl.allowBlacklistedDrivers = "TRUE": Allows the use of blacklisted graphics drivers, which are typically unsupported or known to cause issues.

Step 4: Save and Restart VMware

Save the changes to the preferences.ini file and restart VMware Workstation/Fusion. When you start a VM again, the warning "3D acceleration not supported by host" should no longer appear.

Final Notes

1. Verify 3D Acceleration

To ensure that 3D acceleration is working correctly:

Start a VM and test graphical applications or games that rely on 3D rendering.
Check for any visual artifacts, crashes, or performance issues.
In some cases, you may need to enable 3D acceleration explicitly in the VM's .vmx file by adding or ensuring the following line exists:

mks.enable3d = "TRUE"

2. Potential Risks

Graphical Glitches: You may experience screen tearing, flickering, or other rendering issues.
Performance Issues: Poorly supported hardware/drivers may degrade VM performance.
System Crashes: In extreme cases, forcing unsupported settings can cause VMware or the host system to crash.

3. Recommendations

Update Graphics Drivers: Ensure your GPU drivers are up-to-date to minimize compatibility issues.
Check Host Hardware: Verify that your CPU and GPU support hardware virtualization (Intel VT-x/AMD-V) and GPU passthrough features.
Backup Configuration Files: Always create a backup of the preferences.ini file before making changes, so you can revert if needed.
Test Incrementally: If you encounter issues, try enabling one setting at a time to identify the root cause.

4. Alternative Solutions

If forcing 3D acceleration does not work or causes too many issues, consider the following alternatives:

Upgrade Hardware: Use a more powerful host machine with better GPU support.
Switch Hypervisors: Try alternative virtualization software like VirtualBox, which may have different hardware compatibility.
Use Remote Desktop Tools: For lightweight graphical tasks, remote desktop solutions might suffice without requiring 3D acceleration.

Conclusion

The steps provided in this guide should help you force-enable 3D acceleration in VMware Workstation/Fusion. However, proceed with caution, as unsupported configurations can lead to instability. If the problem persists or causes significant issues, upgrading your hardware or exploring alternative solutions may be necessary.
The steps provided in this guide should help you force-enable 3D acceleration in VMware Workstation/Fusion. However, proceed with caution, as unsupported configurations can lead to instability. If the problem persists or causes significant issues, upgrading your hardware or exploring alternative solutions may be necessary.

If you encounter specific errors or need further assistance, feel free to provide details for troubleshooting!

This version includes comprehensive final notes to guide users on verifying the solution, understanding potential risks, and exploring alternative approaches if needed. Let me know if you'd like further refinements!

⚠️ Change in Behavior with VMware 25H2

With the 25H2 update of VMware Workstation / Fusion, VMware introduced a new command‑line utility called dictTool to inspect and edit VMware configuration files (such as .vmx or preferences).

This suggests that forcing “legacy” or otherwise unsupported driver settings via global configuration has been made more restrictive.

⚠️ In practice: many settings that previously could be applied globally are now often ignored unless explicitly placed in the .vmx file of each VM.

Example — Settings to Insert in Each VM’s `.vmx`

Below is an illustrative example of settings you might force (e.g. to allow blacklisted drivers).

Important: use the exact option names relevant to your scenario.

# Allow a blacklisted graphics driver
mks.gl.allowBlacklistedDrivers = "TRUE"

# Disable automatic detection
svga.autodetect = "FALSE"
svga.noDrivers = "TRUE"

# Other legacy or custom preferences
pref.someLegacyOption = "TRUE"

What Has Changed in 25H2

In earlier VMware versions, many of these lines could be placed in a global .ini or preferences file and would apply to all virtual machines. Beginning with version 25H2, VMware’s internal validation is stricter: such settings must be declared inside each VM’s .vmx file for them to take effect — otherwise they may be ignored or rejected.

Unfortunately, as newer versions of VMware Workstation / Fusion increasingly drop support for older hardware, if you aim to maximize 3D performance it may be better, where possible, to remain on version 17.6.4, which VMware is expected to support until December 2025.

In summary, while staying on VMware 17.6.4 may yield the best possible 3D performance on legacy hardware, this choice comes with increasing risk: missing future fixes, accumulating incompatibilities, and exposure to vulnerabilities. Upgrading to 25H2 or a future release offers new capabilities, tighter security, and broader hardware support — but also demands more careful per‑VM configuration and thorough testing. The optimal path depends on your hardware, performance priorities, and tolerance for risk, so adopt a hybrid strategy, test rigorously, and keep backups in hand.

How to Embed Binary Data into a Win32 Executable File in 4 Methods

Stefor07 — Sat, 19 Apr 2025 09:40:43 +0000

This guide presents 4 methods to embed arbitrary binary files (images, data, etc.) inside a Win32 executable. From standard approaches like byte arrays to low-level techniques such as binary appending (copy /b), each method includes ready-to-use examples in Visual C++ and highlights their specific advantages and disadvantages. It is aimed at C/C++ developers who want to incorporate binary data (e.g., images, configuration files, resources) within their executables.

Use cases:

Single-file deployment (no external resources).
Hiding data inside .exe/.elf (no encryption).
Quick prototyping or educational purposes.

⚠️ Note:

Methods 1 and 3 are clean but platform-specific (Windows only).
Method 2 (embedding as a C array) is both clean and portable across platforms.
Method 4 relies on PE overlay data: simple and effective, but may invalidate signatures or trigger AV heuristics.
All examples assume an x86_64 context (they can be adapted for other architectures).

Method 1: Win32 Resource Files (.rc)

Best for: Native Windows executables where you want integrated resource handling

Step 1: Add resource files in Visual Studio

Right-click project → Add → Resource...
Choose "Import..." and select your binary file (e.g., data.bin)
Set resource type as RCDATA and assign an ID (e.g., IDR_MY_DATA)

Visual Studio will automatically:

Generate/modify resource.h with your ID
Create/update the .rc file with:

  IDR_MY_DATA RCDATA "file.bin"

Step 2: Access the resource from code

Here’s an example demonstrating how to load and access the embedded data in memory:

main.cpp

#include <windows.h>
#include "resource.h"  // Auto-generated by Visual Studio

void LoadEmbeddedData()
{
    // Find the resource handle
    HRSRC hRes = FindResource(nullptr, MAKEINTRESOURCE(IDR_MY_DATA), RT_RCDATA);
    if (!hRes)
    {
        // Handle error: resource not found
        return;
    }

    // Get the size of the resource
    DWORD hResSize = SizeofResource(nullptr, hRes);
    if (hResSize == 0)
    {
        // Handle error: resource size invalid
        return;
    }

    // Load the resource into memory
    HGLOBAL hData = LoadResource(nullptr, hRes);
    if (!hData)
    {
        // Handle error: failed to load resource
        return;
    }

    // Lock the resource to get a pointer to the data
    const BYTE* pData = static_cast(LockResource(hData));
    if (!pData)
    {
        // Handle error: failed to lock resource
        return;
    }

    // At this point, pData points to the embedded binary data
    // You can process the data here, e.g., write to disk, parse, etc.
}

Key Notes:

🔧 No manual compilation – VS handles .rc → .res conversion during build
🔒 Data is read-only in memory (safe from modification)
📦 Supports any binary format (use RT_RCDATA or custom names for raw data)
❌ Possible external changes - Resources can be replaced by external tools
⚠️ Large resources warning - Binary resources are memory-mapped on demand and do not consume RAM until accessed. However, reading very large resources entirely at once can significantly increase physical RAM usage. Consider streaming or partial access methods to efficiently handle large data.

Method 2: Manual Hex Offset Array

Best for: Precise binary embedding without compiler dependencies

Required Tools

HxD Editor - A utility to export the binary file array offset as a C/C++ source file

Step 1: Export binary to C++ offset array

Open your binary file (.bin, .dat, etc.) in HxD Editor
Go to File → Export → C and choose a path to save the source .cpp file
Move the source .cpp file into your project folder and include it

The source file should look like:

/* [FILENAME] ([DATE])
   StartOffset(h): 00000000, EndOffset(h): 000003FF, Length(h): 00000400 */

unsigned char rawData[1024] = 
{
    0x7F, 0x45, 0x4C, 0x46, 0x02, 0x01, 0x01, 0x00, // ELF magic bytes
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x03, 0x00, 0x3E, 0x00, 0x01, 0x00, 0x00, 0x00,
    // ... (truncated for brevity) ...
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
};

Step 2: Accessing the offset from the code

Now create a new H header file from Visual Studio and insert the following declarations:

embedded_data.h

#pragma once

extern const size_t embedded_data_size;
extern unsigned char embedded_data[];

After remember to move the size of the bytes array into a const variable and assign it to the size of the array, do not forget to include the header with the declarations

embedded_data.cpp

#pragma once
#include "embedded_data.h" // include the header

const size_t embedded_data_size = 1024; // this is the value of the array size offset below

unsigned char embedded_data[embedded_data_size] = 
{
    0x7F, 0x45, 0x4C, 0x46, 0x02, 0x01, 0x01, 0x00, // ELF magic bytes
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x03, 0x00, 0x3E, 0x00, 0x01, 0x00, 0x00, 0x00,
    // ... (truncated for brevity) ...
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
};

At this point from any part of our application code we include the header that declares our offset and declare a pointer of the binary data in the code to be able to use it in memory

main.cpp

#include "windows.h"
#include "embedded_data.h"

void LoadEmbeddedData()
{
  const BYTE* embedded_data_ptr = embedded_data;
  const size_t embedded_data_size = embedded_data_size;

  if (embedded_data_ptr)
  {
     // At this point, embedded_data_ptr pointer points the embedded data
     // You can do anything with the buffer and size
     // Example: processing or writing to disk
  }
}

Key Notes:

✅ Manual binary precision – It allows direct embedding of binary data into source code, eliminating dependencies on automated tools.
🔒 Data is read-only in memory (safe from modification)
📦 Immutable data Embedded data is read-only, ensuring safety and integrity during execution.
❌ Manual updates required - To change or update embedded data, you need to regenerate the offset and recompile the source code.
❌ Avoid too large files - Embedding large files can increase the size of the source code, reduce readability, and cause compilation slowdowns or even errors.

Method 3: COFF Object Binary Linking

Best for: Windows applications (MSVC or MinGW) that need tightly integrated, read-only binary data.

Required Tools

bin2obj - Includes a preconfigured portable MinGW (ucrt64) setup with objcopy and a small utility GUI tool to simplify conversion.

Step 1: Convert Binary to COFF Object File

Option A: Manual objcopy Command

To manually convert a binary file to a COFF object, open a terminal (CMD or Git Bash) inside the ucrt64 folder and run one of the following commands depending on your target architecture:

For 32-bit COFF:

objcopy -I binary -O pe-i386 -B i386 binary.bin binary.obj

For 64-bit COFF:

objcopy -I binary -O pe-x86-64 -B i386:x86-64 binary.bin binary.obj

binary.bin is your input file (raw binary).
binary.obj is the output object file that you'll link into your project.

Option B: Use the `bin2obj` Utility (Recommended)

The GUI tool allows for quick conversion:

1. Select your binary file.
2. Choose a destination .obj file.
3. Click "Convert to COFF".

Be sure to leave the "Export C++ header file" checkbox enabled to automatically generate a header file with symbol declarations.

Generated Header Example

The tool will generate a binary_data.h like the following:

For 32-bit:

#pragma once
#include <cstdint>

// include this header in your application and link the COFF as additional dependencies

extern "C"
{
   extern uint8_t binary_filename_start[];

   extern uint8_t binary_filename_end[];

   const size_t binary_filename_size = binary_filename_end - binary_filename_start;
}

For 64-bit:

#pragma once
#include <cstdint>

// include this header in your application and link the COFF as additional dependencies

extern "C"
{
   extern uint8_t _binary_filename_start[];

   extern uint8_t _binary_filename_end[];

   const size_t binary_filename_size = _binary_filename_end - _binary_filename_start;
}

Step 2 (Optional): Manually Create Header Using `dumpbin`

If you didn’t use the utility and created the .obj manually, you’ll need to retrieve symbol names:

1. Open Developer Command Prompt for Visual Studio
2. Navigate to the folder with the .obj file
3. Run:

dumpbin /symbols binary.obj

You’ll see output like:

000 00000000 SECT1  notype       External     | _binary_filename_start
001 000069DD SECT1  notype       External     | _binary_filename_end

Header Template:

For 32-bit (remove underscores):

#pragma once
#include <cstdint>

extern "C"
{
   extern uint8_t binary_filename_start[];
   extern uint8_t binary_filename_end[];

   const size_t binary_filename_size = binary_filename_end - binary_filename_start;
}

For 64-bit (keep underscores):

#pragma once
#include <cstdint>

extern "C"
{
   extern uint8_t _binary_filename_start[];
   extern uint8_t _binary_filename_end[];

   const size_t binary_filename_size = _binary_filename_end - _binary_filename_start;
}

ℹ️ Tip: Symbol names always reflect the original file name, so using consistent filenames helps with version control and updates.

ℹ️ Tip: You can rename the .obj symbols always with the GUI utility bin2obj without having too much difficulty with the command lines

Step 3: Linking and Accessing Embedded Data

Now that we have all the necessary COFF symbols declared we can declare from anywhere in our application code the pointer that points to the embedded data.

Move the .obj file into your project.
Add it to your linker input (Additional Dependencies in Visual Studio).
Include the generated .h header in your source code.

Usage Example:

main.cpp

#include "windows.h"
#include "binary_data.h"

void LoadEmbeddedData()
{
    const BYTE* buffer = binary_filename_start;
    const size_t bufferSize = binary_filename_size;

    if (buffer)
    {
        // the buffer pointer points the embedded binary data
        // You can process it in memory, decompress, write to disk, etc.
    }
}

For 64-bit:

const BYTE* binary_filename_ptr = _binary_filename_start;

⚠️Remember to compile your application in 32 bit / 64 bit depending on your COFF architecture

Key Notes:

✅ Efficient binary embedding – Converts binary data into a COFF object, allowing direct linking in Windows executables (ideal for MSVC/MinGW).
🔒 Data is read-only in memory (safe from modification)
📦 Immutable data Embedded data is read-only, ensuring safety and integrity during execution.
❌ Manual updates required - To change or update embedded data, you need to regenerate the COFF and recompile the source code.
✅ Symbol consistency - If the binary file has the same name, the generated symbols (e.g. binary_filename_start) will be identical, allowing easy updates without changes to the source code.
⚙️ Custom section alignment possible - You can specify additional options with objcopy to control the alignment of the section, which is useful for certain data types or alignment-sensitive binary structures.

Method 4: Binary concatenation into the executable (`copy /b`)

Best for: self-extracting archives and standalone installers

This technique appends arbitrary binary data (e.g., ZIPs, DLLs, images) to the end of a Windows executable using the copy /b command. Because Windows PE executables support overlay data — i.e., data beyond all mapped sections — the appended bytes do not interfere with execution and can be accessed at runtime via file I/O or memory mapping.

This approach is especially useful for self-extracting archives or installers where the payload may be large, and you want to avoid embedding it in the PE resources or sections.

✅ Simple and effective using only the Windows command line and Win32 APIs

⚠️ Not suitable for most small assets; for GIFs, BMPs, or simple settings files, PE resources or embedding as arrays is simpler and more maintainable.

Step 1: Declaring helper functions

Add the following helper functions to your C++ application to:

1. Determine the real size of the executable (excluding any appended binary data).
2. Load the appended binary data into memory. (both with improved heap allocation and memory mapping)

Gets the actual size of the EXE excluding appended binary data

DWORD GetRealExeSize(const TCHAR* exePath)
{
    HANDLE hFile = CreateFile(exePath, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hFile == INVALID_HANDLE_VALUE) return 0;

    HANDLE hMapping = CreateFileMapping(hFile, NULL, PAGE_READONLY, 0, 0, NULL);
    if (!hMapping) { CloseHandle(hFile); return 0; }

    LPBYTE pBase = (LPBYTE)MapViewOfFile(hMapping, FILE_MAP_READ, 0, 0, 0);
    if (!pBase) { CloseHandle(hMapping); CloseHandle(hFile); return 0; }

    IMAGE_DOS_HEADER* pDosHeader = (IMAGE_DOS_HEADER*)pBase;
    if (pDosHeader->e_magic != IMAGE_DOS_SIGNATURE)
    {
        UnmapViewOfFile(pBase);
        CloseHandle(hMapping);
        CloseHandle(hFile);
        return 0;
    }

    IMAGE_NT_HEADERS* pNtHeaders = (IMAGE_NT_HEADERS*)(pBase + pDosHeader->e_lfanew);
    if (pNtHeaders->Signature != IMAGE_NT_SIGNATURE)
    {
        UnmapViewOfFile(pBase);
        CloseHandle(hMapping);
        CloseHandle(hFile);
        return 0;
    };

    DWORD maxEnd = 0;
    IMAGE_SECTION_HEADER* pSection = IMAGE_FIRST_SECTION(pNtHeaders);
    for (int i = 0; i < pNtHeaders->FileHeader.NumberOfSections; ++i)
    {
        DWORD sectionEnd = pSection[i].PointerToRawData + pSection[i].SizeOfRawData;
        if (sectionEnd > maxEnd) maxEnd = sectionEnd;
    }


    UnmapViewOfFile(pBase);
    CloseHandle(hMapping);
    CloseHandle(hFile);
    return maxEnd;
}

Version 1: Heap allocation (for small/medium data)

BYTE* LoadAppendedData(DWORD& outSize)
{
    TCHAR exePath[MAX_PATH] = { 0 };
    GetModuleFileName(NULL, exePath, MAX_PATH);

    DWORD exeSize = GetRealExeSize(exePath);
    HANDLE hFile = CreateFile(exePath, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hFile == INVALID_HANDLE_VALUE) return nullptr;

    LARGE_INTEGER fileSize;
    if (!GetFileSizeEx(hFile, &fileSize)) { CloseHandle(hFile); return nullptr; }

    if (fileSize.QuadPart <= exeSize) { CloseHandle(hFile); return nullptr; }

    DWORD appendedSize = (DWORD)(fileSize.QuadPart - exeSize);
    BYTE* data = new BYTE[appendedSize];

    SetFilePointer(hFile, exeSize, NULL, FILE_BEGIN);
    DWORD bytesRead = 0;
    ReadFile(hFile, data, appendedSize, &bytesRead, NULL);
    CloseHandle(hFile);

    if (bytesRead != appendedSize) { delete[] data; return nullptr; }

    outSize = appendedSize;
    return data;
}

Version 2: Memory-mapped (recommended for large files)

Before declaring the helper function, you should define a structure to store the necessary handles for releasing memory-mapped resources safely:

struct MappedAppendedData
{
    BYTE* mappedView = nullptr;   // Pointer to the full mapped view (used in UnmapViewOfFile)
    BYTE* basePtr = nullptr;      // Offset to where the appended data starts
    size_t totalSize = 0;
    HANDLE hFile = NULL;
    HANDLE hMapping = NULL;
};

// Declare an instance of the structure locally
MappedAppendedData g_mappedAppendedData;

Now, declare the helper function as follows:

BYTE* LoadAppendedData(MappedAppendedData& mappedDataStruct, DWORD& outSize)
{
    TCHAR exePath[MAX_PATH] = { 0 };
    GetModuleFileName(NULL, exePath, MAX_PATH);

    DWORD exeSize = GetRealExeSize(exePath);

    HANDLE hFile = CreateFile(exePath, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hFile == INVALID_HANDLE_VALUE) return nullptr;

    HANDLE hMapping = CreateFileMapping(hFile, NULL, PAGE_READONLY, 0, 0, NULL);
    if (!hMapping) { CloseHandle(hFile); return nullptr; }

    LPBYTE pBase = (LPBYTE)MapViewOfFile(hMapping, FILE_MAP_READ, 0, 0, 0);
    if (!pBase) { CloseHandle(hMapping); CloseHandle(hFile); return nullptr; }

    LARGE_INTEGER fileSize;
    if (!GetFileSizeEx(hFile, &fileSize)) {
        UnmapViewOfFile(pBase);
        CloseHandle(hMapping);
        CloseHandle(hFile);
        return nullptr;
    }

    DWORD appendedSize = (DWORD)(fileSize.QuadPart - exeSize);
    if (appendedSize == 0) {
        UnmapViewOfFile(pBase);
        CloseHandle(hMapping);
        CloseHandle(hFile);
        return nullptr;
    }

    mappedDataStruct.mappedView = pBase;
    mappedDataStruct.basePtr = (pBase + exeSize);
    mappedDataStruct.hFile = hFile;
    mappedDataStruct.hMapping = hMapping;
    mappedDataStruct.totalSize = appendedSize;

    outSize = appendedSize;
    return pBase + exeSize;
}

Then you will need another function to clean up the mapped memory:

Clean Mapped Memory

void FreeMappedAppendedData(MappedAppendedData& data)
{
    if (data.mappedView)
    {
        UnmapViewOfFile(data.mappedView);
        data.mappedView = nullptr;
        data.basePtr = nullptr;
    }

    if (data.hMapping)
    {
        CloseHandle(data.hMapping);
        data.hMapping = NULL;
    }

    if (data.hFile)
    {
        CloseHandle(data.hFile);
        data.hFile = NULL;
    }

    data.totalSize = 0;
}

Step 2: Accessing appended data from code

Now you can declare a pointer to the appended file from anywhere in your code and use it in memory

main.cpp

#include "windows.h"

void LoadEmbeddedData()
{
    DWORD dataSize = 0;
    const BYTE* data = LoadAppendedData(dataSize);

    if (data)
    {
        // Use the embedded binary data here
        // e.g., save to disk, decompress, process, etc.

        // When finished, call delete[] to avoid memory leaks
        // delete[] data;
    }
}

If you are using the helper function for memory mapping you will need to specify the instance of the MappedAppendedData structure to keep track of the system handles and free them later.

main.cpp

#include "windows.h"

void LoadEmbeddedData()
{
    DWORD dataSize = 0;
    const BYTE* data = LoadAppendedData(g_mappedAppendedData, dataSize);

    if (data)
    {
        // Use the embedded binary data here
        // e.g., save to disk, decompress, process, etc.

        // Free up resources when needed with: FreeMappedAppendedData(g_mappedAppendedData);
    }
}

Step 3: Appending binary data to executable

After completing the application compilation, open the command prompt in the build folder (Debug/Release).

Use this command to append any binary file to the application in a command prompt (inside the build output folder):

copy /b stub.exe + file.bin final.exe

⚠️ Important: It is recommended that you do not overwrite the original .exe. Always create a copy (final.exe) with the added data.

Key Notes

✅ Easy loading of concatenated data – It uses the Windows API to read data added to an executable, allowing you to manipulate combined files without additional dependencies like MFC.
✅ No dependencies — all code uses pure WinAPI.
📦 Works best with a single binary file.
⚠️ Dirty method – May break file integrity checks or trigger alerts in security software.
❌ Does not support multiple files unless structured properly:
- Use a container format (e.g., ZIP) to store multiple files.
- Alternatively, insert unique markers (magic bytes) between files to identify boundaries.
⚠️ Appended data must be reattached after each rebuild using copy /b.
🔁 Appended data is not part of the PE format — it is placed after the last section of the executable and is ignored by the Windows loader. This is the only method where embedded data is not stored within the PE structure.

If you're interested, feel free to check out my other articles where I explore several enhancements and advanced techniques based on this method:

🔐 Advanced: Protect the embedded data with digital signature

You can enhance this method by validating the appended data through the executable’s digital signature. This ensures integrity and authenticity of both the executable and the binary file.👉Read: How to Protect Binary Data Appended into an Executable and Validate it with a Digital Signature

📦 Concatenate and manage multiple appended files in Win32 executable

I have discovered a fairly simple method to distinguish the various files concatenated together and access them separately. 👉Read: How to Easily Distinguish Multiple Binary Data Files Concatenated to a Win32 Executable

Methods Summary

Both methods have their pros and cons, below is the summary table for everything

Method	Best For	Pros	Cons	Example Use Cases
Method 1: Win32 Resource Files (.rc)	Native Windows executables where integrated resource handling is preferred	✅ No manual compilation – VS handles `.rc` → `.res` conversion ✅ Data is read-only (safe from modification) ✅ Supports any binary format	❌ Possible external changes – Resources can be replaced by external tools ⚠️ Large resources warning - Binary resources are memory‑mapped on demand and do not consume RAM until accessed. However, reading very large resources entirely at once can significantly increase physical RAM usage. Consider streaming or partial access methods to efficiently handle large data.	Embedding configuration files, certificates, or game assets; Storing default data for single-file apps
Method 2: Manual Hex Offset Array	Precise binary embedding without compiler dependencies	✅ Manual binary precision – Directly embeds binary data into source code ✅ Data is read-only ✅ Immutable data ✅ No additional dependencies ✅ Custom section alignment possible	❌ Manual updates required – Must regenerate offsets and recompile ❌ Avoid too large files – Large files reduce readability and cause compilation slowdowns	Embedding small binary data (e.g., logos, icons, or small assets) for small projects
Method 3: COFF Object Binary Linking	Windows executables (MSVC/MinGW) requiring direct binary embedding	✅ Efficient binary embedding – Converts binary into a COFF object for direct linking ✅ Symbol consistency – Same file name results in identical symbols ✅ Custom section alignment possible	❌ Manual updates required – Regenerate the COFF and recompile for updates ❌ External tool dependency – Requires `bin2obj` utility or manual symbol creation	Embedding large binary files in executables, such as libraries or other large assets
Method 4: Binary Concatenation with `copy /b`	Self-extracting programs, or when no external files are allowed	✅ Easy loading of concatenated data – No dependencies like MFC ✅ Portable – Doesn’t need additional external libraries ✅ Fast to implement – Simple concatenation command	❌ Manual updates may be required – Every time you change the binary data you will need to re-run the `copy /b` command every time after compilation ⚠️ Dirty method – May break file integrity checks or trigger alerts in security software.	Embedding data like ZIP files, DLLs, or other large data into executables for self-extraction

Performance Comparison

Here’s a comprehensive performance and usability comparison of the four binary embedding methods. This will help you determine the most suitable approach based on your project’s specific needs (e.g. platform, file size, performance, deployment constraints):

Method	Binary Size Impact	Load Time	Memory Usage	Compilation Time	Best Use Case	Advantages	Disadvantages
Resource (.rc)	≈ +100%	Fast	Medium (memory‑mapped; OS lazy loads)	Medium	Native Windows applications with small/medium assets	Automatic lazy loading; no manual load code required	Windows-specific tooling required; limited portability
Hex Array	+200–300%	Fastest	High (full static allocation in `.data`)	Slow (especially for large arrays)	Very small files when portability is key	Highly portable; no external dependencies	Large RAM usage; huge increase in binary size
COFF Linking	≈ +100%	Fast	Medium (data in `.rdata`/`.data`; OS may memory‑map)	Fast	Medium to large assets; professional development builds	Clean separation of data and code; efficient loading	Less automatic than resources; requires linker support
Binary Concatenation	≈ +100%	Medium	Low (supports streaming / partial reads)	Instant (post-build step)	Large files, self‑extracting apps, installers	Scales to very large assets; simple build step; streaming-friendly	Requires runtime code to parse/pop out data; less seamless than linker-based methods

🔍 In-Depth: Memory Usage of the Four Methods

Memory usage varies significantly between these four methods, especially in terms of when and how the binary data is loaded into memory.

The Resource (.rc) and Hex Array methods are generally the least memory-efficient. With .rc files, binary resources are embedded into the .rsrc section of the executable. Although the OS technically loads resources on demand, the entire resource is usually mapped into memory when accessed. This becomes problematic with medium or large files, as the whole content must be held in RAM to be usable.

The Hex Array method is even more memory-hungry. Here, the binary data is hardcoded into the source as a static byte array, which is then stored in the .data section of the executable. This data is always loaded into memory when the program starts — even if it’s never used at runtime. This leads to unnecessary memory consumption and should be avoided unless the binary file is very small (e.g. under 50–100KB).

In contrast, COFF linking is significantly more efficient.
Binary data is linked into the executable as an object file (.obj or .o), and, thanks to the operating system’s demand paging, only the portions of the data that are actually accessed are mapped into physical memory.
This provides a practical form of lazy loading at the OS level, making COFF linking an excellent option for applications that handle large or multiple binary assets but don’t need them all resident in memory at once.

Finally, Binary Concatenation is by far the most memory-efficient method. In this approach, the binary data is appended directly to the end of the executable file. The program can read this data at runtime using standard file I/O (e.g. via argv[0] or offset reads). Nothing is loaded into memory by default — it’s entirely under your control. This makes it ideal for working with large files or streamed content, especially in scenarios where memory constraints are critical.

Summary: If minimizing memory usage is a top priority, Binary Concatenation offers the best control and lowest footprint, followed by COFF Linking. The Hex Array and .rc approaches should be reserved for small binary files or cases where convenience outweighs efficiency.

🧠 Detailed Performance Analysis

Each embedding method comes with trade-offs in terms of performance, memory, and developer experience.

Windows resource files (.rc) (via .rc → .res) Resources loaded via LoadResource and LockResourceare usually mapped entirely into the process's virtual memory space. While this generally works well for small assets such as icons and strings, large binary resources (fonts, images, audio, video) can lead to increased memory usage and potential startup delays, since the entire resource is accessible in memory at once. For very large assets, dynamic or streaming loading approaches may be more memory-efficient.

Hex Array is the fastest at runtime because the binary data is already part of the process image — statically embedded into the .data segment of the executable. Access is instantaneous and requires no file I/O. However, this convenience comes at a heavy cost: the source code size balloons due to the conversion of binary data into hexadecimal (text-based) representation. This can dramatically increase compilation time — especially when embedding files over 1MB — and also leads to large executable sizes, often 2–3× the original binary. It's best used for very small and frequently accessed assets, where portability and startup speed are more important than scalability.

COFF linking is widely regarded as a professional approach in C/C++ projects. Binary data is compiled into object files, which are then linked into the application like any other static symbol. This method results in much smaller size overhead compared to hex arrays and allows for clean, symbol-based access to the data.

Because the binary data resides in a proper section of the executable, it benefits from the operating system’s normal demand paging and memory mapping mechanisms, meaning pages are loaded only when accessed. This makes it well-suited for large files or multi-resource applications.

It does require additional build configuration (e.g., using ld, objcopy, or llvm-objcopy), but offers excellent runtime performance and efficient memory use.

Binary Concatenation, the most flexible and lightweight method, deserves special attention. Unlike other approaches, it has zero impact on compilation time because the binary data is not embedded during the build process; instead, it is appended to the executable as a post-build step (for example via a script or simple cat/copy operations). At runtime, the application can open its own executable file and access the appended data using standard file I/O, giving full control over how much data is loaded and when. This enables efficient streaming, chunked reads, or even memory-mapped access, resulting in minimal RAM usage. The approach is particularly well suited for bundling large files such as compressed archives, installation data, language packs, or media resources, without increasing the executable’s memory footprint or requiring recompilation when the files change. The main trade-off is increased deployment complexity, as the application must manage file offsets and maintain a dedicated post-build integration step. Nevertheless, for installer executables, self-extracting archives, and other memory-sensitive or large-scale deployment tools, Binary Concatenation offers an excellent balance of flexibility, performance, and resource efficiency.

✅ Final Thoughts

Choosing the right embedding method depends on your priorities: ease of integration, memory efficiency, build complexity, or runtime performance. For small, native Windows applications, .rc resources are quick and familiar. For cross-platform use with tiny binaries, Hex Arrays offer simplicity and speed. If you're embedding large assets and care about memory usage and maintainability, COFF Linking is the most professional choice. But if you want complete control with minimal memory overhead — and can manage a simple post-build step — Binary Concatenation is the most flexible and scalable solution. There's no one-size-fits-all answer, but understanding these trade-offs will help you pick the method that best fits your specific use case.

Conclusion

In this article, we've covered four distinct methods for embedding binary data into a Win32 executable, each offering its own strengths and trade-offs:

Method 1: Win32 Resource Files (.rc): Ideal for straightforward integration with Windows resource handling. Best for applications where the embedded data does not change often and is part of the resource management system.
Method 2: Manual Hex Offset Array: Provides precise control over the embedded data but requires manual management of offsets. Best suited for small to medium binary data embedded directly within the source code.
Method 3: COFF Object Binary Linking: A more sophisticated method for embedding large binary objects, ideal for developers using MSVC or MinGW who need to efficiently manage binary assets.
Method 4: Binary Concatenation with copy /b: A "dirty" but quick solution for appending data directly to an executable. This method is great for self-extracting applications but requires careful handling of offsets and file sizes.

Best Practices & Recommendations

Keep Your Executable Small: While embedding binary data can make your application self-contained, avoid adding too much data to prevent bloating the executable and affecting performance.
Use Proper Memory Management: Always ensure to free any allocated memory once you're done using the embedded data to prevent memory leaks.
Consider Security: If you're planning to hide sensitive data (e.g., encryption keys), be mindful that these methods are not inherently secure and can be easily extracted by someone with access to the executable. You may want to consider additional security measures, like encryption.
Avoid loading very large files entirely into memory: For large binaries (e.g. ZIP archives, videos, DLLs), consider block processing (streaming) or memory mapping (CreateFileMapping + MapViewOfFile) instead of allocating a huge buffer, this can reduce RAM usage and make everything more performant

Final Thoughts

Each of these methods is suitable for different scenarios, and the best choice depends on your specific needs: portability, ease of use, and how frequently the embedded data needs to be updated. For quick prototyping or simple use cases, copy /b might be the easiest choice, but for more robust applications, using Win32 resource files or manual hex offsets could be more effective.

Feel free to experiment with these methods and choose the one that fits best with your project goals!

Contributions & Questions

If you have any suggestions, improvements, or questions, feel free to contribute or reach out! I'm open to discussing different techniques and ways to enhance the methods presented here.

Happy coding and stay creative! 🎉

DEV Community: Stefor07

Nested Virtualization on Windows 11: The VBS Conflict Explained

Introduction

The Problem: VMware Nested Virtualization Failures

Understanding the Root Cause: VBS

Initial Troubleshooting Attempts

The Only Working Solution: Microsoft's DG_Readiness_Tool

Why Other Approaches Don't Work

HypervisorIOMMUPolicy Alone Is Not Enough

The Real Solution

Complete Solutions

Solution 1: Temporary VBS Disable (Recommended for Testing)

Solution 2: Downgrade or Dual-Boot (Recommended for Permanent Use)

Solution 3: Switch to Linux (Best for Advanced Labs)

Compatibility Matrix

Key Takeaways

Conclusion

🔎 Possible Silent Fix in Recent Updates

Decompression in C/C++: Virtual Files and Memory I/O Principles and Techniques

Why Decompress Directly in Memory?

Memory vs Disk Decompression: Understanding the Landscape

High-Level Libraries with Native Memory Support

Low-Level Libraries: The Custom Callback Approach

How Custom Callbacks Work

Implementing Memory Callbacks

Core Callback Implementations

Callback Purpose and Usage

Usage Notes

Adapting Callbacks to Specific Libraries

Library-Specific Requirements

Library Comparison

Conclusion

The Perfect Illusion: When VirtualBox Pretends to Be Parallels

How the idea was born – from boredom to vision 💡

ℹ️ 1. What happened to Parallels?

❗ 2. But do Windows and Linux really have to give up?

🎯 3. Why VirtualBox?

🧰 How I created the illusion!

🎨 A touch of personality or motivation

🔍 A reflection on perception vs. reality

🧠 Philosophical angle (if you like deeper tones

🧾 Introduction to screenshots

🔚 Bonus insight: when illusion isn’t enough

🏁 Final thoughts: not just a VM, but a vision

How to Easily Distinguish Multiple Binary Files Appended to a Win32 Executable

Step 1: Declaring Helper Functions in Code

Step 2: Files Size Retrieving

Step 3: Accessing Embedded Files at Runtime

Accessing the First Appended File (Simplest Case)

Accessing the Last Appended File (Simplest Case)

Accessing a File in the Middle

✅ General Rule

💡 Optional Tip

Improved method for memory mapping

📌 Alternative Access Strategy

💡 Bonus: Check the integrity of appended files

Step 4: Binary File Concatenation

Comparison of Memory Mapping Access Strategies

Key Differences

Recommendation for 32-bit Applications

⚠️ Memory Mapping Pitfalls in 32-bit Applications

✅ Why a Single Memory Mapping is Better

🧠 Summary

⚠️ Warning: Authenticode Signature and Appended Data

✅ Why This Matters

How does this method work?

⚖️ Pros and Cons of This Approach

✅ When to Use This

🛡️ How to Make It More Robust

🔐 Further Reading

Conclusion

How to Protect Binary Data Appended into an Executable and Validate it with a Digital Signature

Step 1: Creating Authenticode Signature Certificate

Exporting the .pfx certificate (Recommended)

Step 2: Retrieve Certificate Thumbprint

Step 3: Implement Runtime Signature Verification in Visual C++

Step 4: Append Binary Data to the Executable

Step 5: Sign the Final Executable

⚠️ Note on signtool:

Optional: Automate via Visual Studio Post-Build Events

Exporting the `.pfx` certificate (Recommended)

🔐 Security Note: The Role of the `.pfx` File

🧱 Step 3: Create the Main Application Class (`Main`)

➤ Edit `CMainDlg.h`

➤ Edit `CMainDlg.cpp`

Step 2: Locate the `preferences.ini`

Step 3: Edit the `preferences.ini` file

Example — Settings to Insert in Each VM’s `.vmx`

Option B: Use the `bin2obj` Utility (Recommended)

Step 2 (Optional): Manually Create Header Using `dumpbin`

Method 4: Binary concatenation into the executable (`copy /b`)