DEV Community: Keishin Senzaki

Hiding an image in a PNG and decoding it with SVG filters, without CORS pixel access

Keishin Senzaki — Thu, 08 Oct 2026 04:29:28 +0000

I wanted to see whether a browser could reveal an image hidden in another image even when the carrier was hosted on a site that did not allow cross-origin pixel reads. Drawing the carrier to a canvas is easy, but reading the canvas back is not: without the image host's CORS permission, the canvas becomes tainted. A server-side proxy would solve a different problem. I wanted the visitor's browser to fetch and display the original PNG directly.

That experiment became Visual Noise Decoder, a small, dependency-free set of three HTML pages: one to encode images, one to view a decoded image, and one to assemble a gallery. The interesting part is the viewer. It reconstructs the hidden pixels with SVG filters and CSS blending, while JavaScript never reads pixels from the remotely hosted carrier.

Here is an encoded example. It looks like an image of Earth, but its low color bits carry an image of the Moon:

Open the decoded Moon, or open all three example images as a gallery. The example seed is public; this is a demonstration of the rendering technique, not a secret to protect.

Why canvas cannot do the whole job

The encoder runs on images that the user selects locally. It can use canvas normally: scale the secret, center-crop the cover, modify pixel bytes, and export a new PNG.

The viewer has different constraints. A remote <img> or CSS background can be displayed without CORS permission. But if I draw that remote image on a canvas and call getImageData() or toDataURL(), the browser's origin-clean restriction prevents access. Applying an SVG filter first does not make that readback legal. The problem is not getting the image onto the screen; it is obtaining its pixel values in JavaScript.

The solution here is to keep the carrier in the browser's rendering pipeline. The viewer uses it as a CSS background, extracts the required bits with SVG component-transfer filters, combines it with locally generated mask images, and lets the compositor assemble the result. It never exports the filtered carrier to canvas.

This does not bypass CORS or an image host's access controls. If hotlink protection or a content policy prevents the image from loading, there is nothing to decode.

The PNG layout

For a secret of W × H pixels, the output cover is 2W × 2H. Think of the cover as four W × H quadrants. One secret pixel maps to four cover pixels at the same relative position: one in each quadrant. Each secret pixel has eight bits per RGB channel; each of those four cover pixels carries two of those bits in its channel's two least significant bits. The upper six bits of each cover channel stay as they were.

For one channel, the encoder's core operation is:

const secretBits = (secretChannel >> (quadrant * 2)) & 3;
encodedChannel = (coverChannel & 252) | (secretBits ^ maskBits);

maskBits comes from a deterministic AES-CTR stream. The encoder and viewer generate it in the same way:

const material = `${DOMAIN}\0${index}\0${phrase}`;
const digest = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(material));
const key = await crypto.subtle.importKey('raw', digest, { name: 'AES-CTR' }, false, ['encrypt']);
const stream = new Uint8Array(await crypto.subtle.encrypt(
  { name: 'AES-CTR', counter: new Uint8Array(16), length: 128 },
  key,
  new Uint8Array(byteLength)
));

DOMAIN is the fixed string VND-MAIN-HALF-2LSB-MASK-RGB. Encrypting zero bytes with a zero-initialized counter produces the mask stream; it does not decrypt the remote PNG through Web Crypto. The image index matters for galleries: images encoded with the same seed must use different indices so that they do not reuse the same mask stream.

The output must remain an original PNG. Resizing, recompressing, or converting it can change the low bits and destroy the hidden image. A link to the image-hosting page or a thumbnail is not a substitute for a direct link to the encoded PNG.

Reconstructing bits in the browser

The viewer knows the PNG dimensions from an ordinary image load. It reproduces the mask stream locally, and it can safely generate mask PNGs on canvas because those pixels are its own. It creates eight mask planes: two bit planes for each of the four quadrants.

For each plane, an SVG feComponentTransfer with a discrete lookup table turns one selected low bit of a color channel into a binary value. The table is generated from (value >> bit) & 1 for all 256 input values. The remote carrier remains a CSS background behind that filter.

const values = Array.from(
  { length: 256 },
  (_, value) => (value >> planeBit) & 1
).join(' ');

component.setAttribute('type', 'discrete');
component.setAttribute('tableValues', values);

The filtered carrier plane and the corresponding mask plane are blended using CSS difference. For binary values, that implements the required XOR and removes the mask generated above. The rest is bit-plane compositing: extract a bit, XOR it with its mask bit, weight it by its position, then add the eight planes. CSS opacity supplies the weights, from 1/255 to 128/255, and plus-lighter blending combines the planes into an RGB image. The source quadrant and mask position are aligned with CSS background positioning.

.key { mix-blend-mode: difference; }
.plane { mix-blend-mode: plus-lighter; }

plane.style.opacity = String((1 << planeIndex) / 255);

The difference blend is between the carrier and mask inside a plane; opacity weights that result before the planes are added together.

It is an unusual use of the renderer, and it has a cost. The viewer needs eight filtered carrier planes and eight mask layers; it is not a single canvas draw call. Browser rendering and memory use become significant for large images. The gallery therefore mounts its image viewers progressively as they approach the viewport.

There was also a Chromium rasterization problem when a heavily reduced decoded image returned from a hidden tab or a minimized window. The viewer refreshes its raster after visibility and scale changes so that the composited result does not turn into noise. That workaround is about rendering, not about re-decoding the PNG.

Trying the project

You can open the encoder directly through HTMLPreview, or serve the repository directory locally with python -m http.server 8080 and open encode.html.

The encoder accepts multiple secret and cover images, including file drops. Covers cycle in filename order across the secrets. Output can be saved as individual PNGs, into a chosen folder where supported, or as a ZIP archive. The gallery accepts one direct PNG URL per line, extracts PNG URLs from pasted embed code, or loads a ready-made set of URLs and a seed from its URL fragment. image.html can also be placed inside an iframe; a square iframe with border-radius: 100% and pointer-events: none works as a non-interactive circular image.

The repository includes three examples with different dimensions and aspect ratios: Moon inside Earth, Sun inside a hurricane view, and an Antarctic aurora inside cloud imagery. Their source images are credited to NASA Goddard in the README. NASA media are generally not subject to US copyright, though its media guidelines describe conditions and exceptions.

Limits of the idea

This is a research demonstration, not an audited encryption system. Reusing the same seed and image index for two secrets repeats the mask; combining the encoded images can expose a relationship between the secrets. A weak seed phrase is also guessable, since SHA-256 is not a password-hardening function. There is no authentication or integrity check: a wrong seed, wrong index, or damaged PNG can simply produce noise. The visible cover dimensions and the modified low bits may reveal that data is present.

A shared viewer URL includes the seed in its fragment. That fragment is not part of the HTTP request for the page, but it is visible to anyone who receives the full link and to scripts running on the viewer page. In particular, using HTMLPreview means trusting a third-party page with the demonstration seed. Do not put a private seed into a viewer you do not trust.

The source code and examples are available under BSD-2-Clause-Patent. I would be interested in feedback on the SVG/CSS reconstruction, browser compatibility, and whether there is a simpler CORS-independent rendering path that preserves the original PNG's low bits.

Disclosure: This article was drafted with AI assistance. Its technical descriptions were checked against the project's source code and examples.

Booting a VeraCrypt-encrypted Windows VHD through Ventoy

Keishin Senzaki — Sat, 03 Oct 2026 04:47:53 +0000

I often use Ventoy as a multiboot USB drive: installer ISOs, live systems, recovery tools. Discovering its Windows VHD boot plugin suggested another use for it. Instead of giving every Windows installation its own set of partitions, I could put one in a VHD file, set it up in VirtualBox while another OS was running, and later boot that same installation directly on physical hardware through Ventoy. Replacing a system could then mean preparing a new file instead of repartitioning the drive.

I also encrypt the systems and data I use with VeraCrypt. I wanted the flexibility of a VHD file and direct hardware boot without giving up system encryption. My first attempt was to boot an ordinary Windows VHD through Ventoy and turn on VeraCrypt system encryption there. The encryption wizard failed in that native-VHD setup. I then encrypted the Windows installation inside its UEFI VirtualBox VM. It booted in the VM, but Ventoy's VHD boot path could no longer start it.

That led me to build EncryptedVhdBoot, an experimental x64 UEFI bridge. It authenticates the encrypted volume, decrypts the VHD reads needed before Windows starts, and passes VeraCrypt's standard boot state to veracrypt.sys.

The bridge hooks VHD parser callbacks in two Windows boot applications, with a third hook at the point where Boot Manager starts Winload. The VHD and Microsoft's boot files stay unchanged on disk. Below is how those hooks fit into the boot path.

The visible password prompt during a physical x64 UEFI boot. The entered characters are masked.

Why the normal boot paths do not meet

Ventoy's Windows VHD boot image starts a Microsoft Boot Manager that knows how to open VHD files. For an unencrypted Windows VHD, Boot Manager reads the virtual disk, launches winload.efi, and Windows continues.

An encrypted VHD creates two separate obstacles. In the tested configuration, VeraCrypt 1.26.29 reports an error when System > Encrypt System Partition/Drive is opened from Windows already running by native VHD boot, so the system has to be encrypted inside the VM. Once it is encrypted, Ventoy can still open the VHD file, but Boot Manager and Winload receive ciphertext from their VHD parsers before the Windows VeraCrypt driver can take over.

Here is the path the bridge creates:

Ventoy selects a Windows VHD
  -> EncryptedVhdBoot UEFI application
     -> original Windows Boot Manager
        -> VHD1 read callback: read ciphertext, return plaintext
        -> launch winload.efi
           -> its own VHD1 read callback: return plaintext
           -> Windows kernel and boot-start drivers
              -> veracrypt.sys takes over encrypted disk I/O

The word own matters: patching Boot Manager's VHD reader alone is insufficient. winload.efi has a separate VHD1 parser and continues reading the disk after Boot Manager launches it.

Intercepting virtual-disk reads

The supported Ventoy input is the official Win10Based v3.0 ventoy_vhdboot.img. Its UEFI boot image contains a specific 64-bit Windows Boot Manager build, version 10.0.10240.16384. Microsoft public symbols and the PE layout let me identify its Vhd1Parser table. The bridge loads the original Boot Manager, locates the table at RVA 0x2CF8, validates all four original table entries (Open, Close, Read, and Write) against that build, then replaces the relocated read and write pointers in RAM:

mOriginalVhdRead  = (EVB_VHD_IO)mVhd1Parser[EVB_VHD_READ_INDEX];
mOriginalVhdWrite = (EVB_VHD_IO)mVhd1Parser[EVB_VHD_WRITE_INDEX];

mVhd1Parser[EVB_VHD_READ_INDEX]  = (UINTN)EvbVhdReadPassThrough;
mVhd1Parser[EVB_VHD_WRITE_INDEX] = (UINTN)EvbVhdWritePassThrough;
MemoryFence ();

These are the actual callback assignments in EvbPreloader.c. The original callbacks remain available to the bridge; no VHD routine is copied or permanently rewritten.

Why work at this level? The VHD parser has already translated file layout into offsets on the virtual disk. A fixed VHD and a dynamic VHD store their bytes differently in the host file, but the parser presents the same disk-offset view to its callers. That gives the decryption code a useful boundary: it can reason about VeraCrypt sectors without reimplementing Ventoy's VHD file handling.

The Boot Manager wrapper first calls the saved original VhdRead. On its first successful read it authenticates the VeraCrypt header, or takes the plain-VHD path if the password is empty. For an encrypted read, EvbVeraCryptDecryptRead limits the transformation to the encrypted region:

IntersectStart = (ByteOffset > mEncryptedStart) ? ByteOffset : mEncryptedStart;
IntersectEnd   = (ReadEnd < mEncryptedEnd) ? ReadEnd : mEncryptedEnd;
if (IntersectStart >= IntersectEnd) {
  return EFI_SUCCESS;
}

An aligned interior can be decrypted in place, using the virtual-disk sector number as the XTS data-unit number. For an unaligned edge, the code rereads the whole sector through the original callback, decrypts it in a scratch buffer, and copies back only the requested span. This preserves bytes outside the encrypted area. Early writes to an encrypted VHD are rejected as write-protected. The bridge does not attempt to implement encrypted writes during the pre-kernel phase. With an empty password, it leaves the ordinary unencrypted-VHD read and write behavior in place.

Finding the second parser

Boot Manager's parser is tied to one validated binary profile. For winload.efi, a version-only allowlist would be brittle: Windows 10 and 11 ship many builds, and the VHD parser's address moves.

Instead, the bridge patches Boot Manager's ImgArchEfiStartBootApplication entry point at RVA 0x6B468 after validating its expected 15-byte prologue. The patch redirects control to EvbStartBootApplication. A trampoline preserves the overwritten instructions and lets that wrapper call the original function:

CopyMem (
  Trampoline,
  mBootApplicationHookOriginal,
  EVB_BOOT_APP_HOOK_SIZE
);
EvbWriteAbsoluteJump (
  Trampoline + EVB_BOOT_APP_HOOK_SIZE,
  (UINTN)(mBootApplicationHookTarget + EVB_BOOT_APP_HOOK_SIZE)
);

EvbWriteAbsoluteJump (
  mBootApplicationHookTarget,
  (UINTN)EvbStartBootApplication
);

The jump uses an indirect RIP-relative x64 encoding that preserves registers. This boundary is reached after Boot Manager has loaded and authenticated the child boot application, but before it starts running.

At that point, the bridge scans the loaded Winload PE image for a VHD1 parser table. The scanner considers initialized, readable, non-executable sections. Its decisive checks include:

if ((Candidate[EVB_VHD_WRITE_INDEX] !=
     (Candidate[EVB_VHD_READ_INDEX] + EVB_VHD_WRAPPER_SIZE)) ||
    !EvbMatchesVhdWrapperPair (&Image, Candidate[EVB_VHD_READ_INDEX]) ||
    !EvbRangeInSection (&Image, Candidate[EVB_VHD_OPEN_INDEX], 1, TRUE) ||
    !EvbRangeInSection (&Image, Candidate[EVB_VHD_CLOSE_INDEX], 1, TRUE))
{
  continue;
}

if (Match != NULL) {
  return NULL;
}
Match = Candidate;

The read and write wrappers must have the validated instruction shapes and sit 48 bytes apart; the Open and Close targets must be executable. A second candidate makes the result ambiguous, so the scan returns no match.

Only after finding that unique table does the bridge replace Winload's own callbacks:

mOriginalWinloadVhdRead   = (EVB_VHD_IO)Parser[EVB_VHD_READ_INDEX];
mOriginalWinloadVhdWrite  = (EVB_VHD_IO)Parser[EVB_VHD_WRITE_INDEX];
Parser[EVB_VHD_READ_INDEX]  = (UINTN)EvbWinloadVhdRead;
Parser[EVB_VHD_WRITE_INDEX] = (UINTN)EvbWinloadVhdWrite;
MemoryFence ();

The Winload read wrapper calls its original callback and decrypts the returned sectors. If the encrypted path is active and a suitable parser cannot be identified unambiguously, the child launch is aborted. The bridge does not guess an address or let Winload continue reading ciphertext.

This is still a compatibility technique, not a promise that every future Windows build will match. The project records the tested versions and the structural checks in its architecture notes.

From password to Windows driver

On the first Boot Manager VHD read, the bridge can use the saved original callback to read the virtual disk's MBR and VeraCrypt system header. It asks for a password and an optional system PIM, then uses VeraCrypt-compatible header and crypto code to authenticate the volume. After header authentication, it checks that decrypting the first encrypted sector produces the expected NTFS signature before allowing the boot to proceed.

The bridge also prepares VeraCrypt's standard BootArguments and BOOT_CRYPTO_HEADER handoff. The relevant part of EvbPrepareBootParams shows what goes into that handoff:

Args->CryptoInfoOffset = (UINT16)OFFSET_OF (EVB_BOOT_PARAMS, BootCryptoInfo);
CopyMem (&Args->BootPassword, VcPassword, sizeof (Args->BootPassword));
Args->Flags = (UINT32)Pim << 16;
CopyMem (&Args->BootDriveSignature,
         Mbr + EVB_MBR_SIGNATURE_OFFSET,
         sizeof (Args->BootDriveSignature));

The PIM uses the upper 16 bits of BootArguments.Flags, matching VeraCrypt-DCS and the Windows driver. The full handoff includes lengths, CRCs, and crypto-header fields; the excerpt highlights the password, disk signature, and PIM. The boot-start veracrypt.sys driver receives the state it needs when firmware services are gone.

At ExitBootServices, the bridge wipes its private expanded-key workspace and partial-sector buffer. It retains the handoff block needed by veracrypt.sys; the driver later validates, consumes, and burns that block. Once Windows is running, normal encrypted-disk operation belongs to the VeraCrypt driver, not the UEFI bridge.

Building and using the image

The project builds a replacement ventoy_vhdboot.img from the verified upstream Win10Based v3.0 image. The original Boot Manager remains in the image; the new UEFI entry point loads it, installs the in-memory hooks, and starts it. The builder also preserves an easy-to-miss detail of the original ISO: its BIOS and UEFI BCD paths share one physical extent. Ventoy patches one path in memory, and the UEFI path must see the same bytes. Making independent BCD copies breaks boot.

For an encrypted system disk, the tested preparation path is:

Install Windows in an x64 UEFI VirtualBox machine whose system disk is a fixed or dynamic VHD1.
Complete VeraCrypt system encryption and its pretest inside the VM. On Windows 11, fully remove BitLocker or device encryption first.
Shut down the VM, keep a recoverable copy of the VHD, and put the VHD on the Ventoy data partition.
Install the derived vhdboot image and select the VHD from Ventoy in x64 UEFI mode.

For Windows 11, open an elevated Command Prompt inside the VM before enabling VeraCrypt system encryption:

manage-bde -off C:
manage-bde -status C:

Wait until manage-bde -status shows Conversion Status: Fully Decrypted and Percentage Encrypted: 0.0%. Protection Status: Protection Off alone does not mean decryption has finished.

The repository's README has the exact build, install, restore, and preparation commands. An empty password takes the original unencrypted-VHD path, so the same image can still boot ordinary VHDs.

There is also an optional /ventoy/ventoy_vhdboot.silent marker file. When it is present beside ventoy_vhdboot.img, the bridge clears its screen and accepts password and PIM input without showing its own prompts, characters, masking symbols, or status text. This affects only output from the bridge; Ventoy, firmware, and Windows can still display their own interfaces. It is a display option, not a claim of stronger encryption.

What has been tested, and what has not

End-to-end boot and driver handoff have been tested with VeraCrypt 1.26.29 on Windows 10 LTSC 2019, 1909, 21H2, and 22H2, and Windows 11 25H2. The tests include fixed and dynamic VHD1 files, default and custom PIM values, and several cipher and PRF combinations. The compatibility matrix gives the exact Winload versions and results.

The current release requires x64 UEFI with Secure Boot disabled and the specified Ventoy vhdboot image. VHDX, differencing VHDs, Legacy BIOS, arbitrary Boot Manager builds, hidden systems, and rescue workflows are outside the supported scope. The project has not received an independent security audit. Boot tests demonstrate compatibility in the listed setups; they do not certify the security of the bridge.

The code and detailed design are available in the repository. I would especially welcome review of the VeraCrypt driver handoff, the Winload parser validation, and the lifetime of sensitive boot state. This is an independent project and is not affiliated with or endorsed by Ventoy, VeraCrypt, or Microsoft.

Disclosure: This article was drafted with AI assistance. Its technical descriptions were checked against the project's source code and documentation.