# Security audit — 2026-08-13

## Scope and assurance

The complete C# launcher and MSIX installer were manually reviewed, pattern-scanned, rebuilt with warnings treated as
errors, packaged, signed, installed, repaired at the same version, and launched. The bundled C++ DLL source (754 files)
received a targeted static review of process/memory access, hooks, script filesystem and network APIs, marketplace
installation, local HTTP server, binary loading, build hardening, and security tests.

This is not a formal proof that no vulnerability exists. It does not replace independent review, fuzzing, dependency
SBOM scanning, or game-version-specific runtime testing. The findings below are the issues confirmed in this review.

## Fixed findings

| ID | Severity | Finding | Resolution |
|---|---|---|---|
| LN-01 | High | A PID could be reused between detection and injection, redirecting the operation to another process. | The already-open process handle is now revalidated with `QueryFullProcessImageNameW`, exact path, and executable name before any write. |
| LN-02 | High | On injection timeout, the launcher could free the remote DLL-path buffer while the remote thread was still using it. | Remote memory is freed only after confirmed thread completion; a timed-out path is intentionally leaked rather than creating a remote use-after-free. |
| LN-03 | Medium | Custom DLL hashing and copying used the mutable source twice, leaving a TOCTOU window. | The selected file is copied once into a private, bounded snapshot and the immutable snapshot is hashed and promoted atomically. |
| LN-04 | Medium | Skin and avatar decoders accepted oversized or weakly constrained images, enabling memory/CPU exhaustion. | PNG signatures, dimensions, frame count, decoded size, file size, response size, and 3D texture expansion are bounded. |
| LN-05 | Medium | Discord avatar downloads had no strict origin, redirect, response-size, or timeout policy. | Requests are HTTPS-only to `cdn.discordapp.com`, redirects are disabled, and connection/read/body/image limits are enforced. |
| LN-06 | Medium | The loopback Nova Shop development API accepted browser-originated state-changing requests. | Cross-site browser headers are rejected and POST bodies must use `application/json`; regression tests cover native and hostile-origin requests. |
| LN-07 | Medium | Installer trust checks relied mainly on a certificate thumbprint and package name. | Raw certificate bytes, subject, EKU, non-CA status, package family name, cache path, extension, size, and post-install identity are verified. |
| LN-08 | Medium | Changed MSIX content at the intentionally unchanged `1.0.0.0` version could not be repaired. | The installer handles only the exact same-version deployment conflict, removes that verified package family, and reinstalls it. User data remains outside the package. |
| LN-09 | Low | Logs, settings, support ZIPs, and UI log loading were unbounded or only partially redacted. | Atomic bounded settings, rotating logs, tail-only reads, unique ZIP names, and additional device/e-mail/Discord-ID redaction were added. |
| LN-10 | Low | PE scanning for the skin reader trusted several file-header offsets. | File size, PE offset, section count, section-table range, and raw-section ranges are validated before seeking or scanning. |
| LN-11 | Low | Multiple launcher instances could race on settings, runtime files, and injection. | A per-user single-instance mutex prevents concurrent launcher sessions. |
| LN-12 | Low | Broad recursive discovery could spend excessive time on crafted directory trees. | Minecraft, profile, options, and texture discovery now use explicit candidate limits. |
| LN-13 | High | A loose-version importer could copy user data or follow crafted paths/links. | Removed from the product. Version 1.1.6 uses only Windows-managed MSIXVC deployment and does not import installed game files. |
| LN-14 | High | A registered version could be replaced or a different running Minecraft process could receive the selected DLL. | Windows package deployment is followed by exact Store family, signature, executable, and version checks. The process path is revalidated before injection, and a different running version blocks the operation. |
| LN-15 | Medium | Deep payload paths could cause an incomplete loose import. | Removed with the loose importer; no installed game tree is copied. |
| LN-16 | High | A custom loose-registration switch could lose the user's previous registration. | Removed. All switching is delegated to Windows `PackageManager`; LatiNova does not remove and re-register loose manifests. |
| LN-17 | High | Version removal could delete data outside LatiNova ownership. | Removal is limited to validated package and metadata paths under the LatiNova package store; the currently registered version is refused. |
| LN-18 | Medium | A remote version catalog could redirect downloads, inject malformed metadata, or exhaust memory. | Catalog retrieval is HTTPS-only from one fixed raw GitHub host with redirects disabled and a 2 MiB cap. Schema/version/count, unique release versions, MD5 syntax, `.msixvc` paths, and a narrow Microsoft Xbox Live CDN host allowlist are validated before display; a last-known-good cache is promoted atomically. |
| LN-19 | High | Automatically trusting another launcher's loose folders could import modified executables. | Removed. The release does not discover or import other launchers' game folders. |
| LN-20 | High | A catalog entry could redirect the downloader to attacker-controlled content or an unbounded file. | Catalog redirects are disabled; only fixed Xbox Live CDN hosts and `.msixvc` paths are accepted; remote and local sizes are bounded; downloads stay in a LatiNova staging directory and are promoted atomically after the catalog MD5 matches. |
| LN-21 | Critical | Package-management authority could be used to replace an unrelated application or deploy an untrusted loose package. | The deployment service has no caller-supplied identity or path: it accepts only validated metadata under the LatiNova package store, requires the fixed Minecraft family, Gaming Services, an existing Store-signed Minecraft package, and a stopped game, then verifies the resulting family, Store signature, executable, and version. |
| LN-22 | High | A substituted native downloader or launch helper could execute arbitrary native code. | Both binaries are embedded inside the signed LatiNova MSIX and distributed with corresponding source. The downloader is separately signed and extracted with a content-addressed name. The MIT helper is reproducibly built, has a pinned SHA-256, is written only to the exact current Store-signed Minecraft root, and is re-hashed after writing. |
| LN-23 | Medium | A network or disk fault could leave a partially downloaded package that appears installed. | Partial data remains only as `.part` under the staging directory, is never listed as downloaded, and is resumable. Windows PackageManager performs the final Microsoft package-signature validation before the package can become active. |
| LN-24 | High | Omitting the Microsoft PC Bootstrapper can bypass its forced-update UI, and an untrusted helper filename could be planted in the game root. | The unused `unvirtualizedResources` capability remains removed. Version 1.1.6 intentionally restores only the small MIT helper after exact package-family, Store-signature, executable-path, embedded-hash, conflict, and post-write checks. The helper does not replace the game executable or bypass Xbox entitlement, but Microsoft/Mojang authorization for this consumer workflow remains unresolved in `LEGAL_REVIEW.md`. |
| LN-25 | High | A copied game could be substituted before direct launch. | The fast-launch cache and direct-launch path were removed. Selected versions are activated only through Windows package management and rechecked afterward. |

## Existing controls confirmed in the DLL source

- plugin filesystem paths remain inside each plugin directory and reject traversal and existing reparse points;
- plugin file, directory, marketplace manifest, marketplace file, total install, network response, and WebSocket message
  sizes are bounded;
- marketplace content is fetched from an immutable Git revision over HTTPS;
- optional ChakraCore loading uses an exact accepted SHA-256 and safe DLL search flags;
- C++ release builds enable `/GS`, `/sdl`, `/guard:cf`, `/Qspectre`, ASLR, DEP, CFG, and CET compatibility;
- the skin reader is read-only and opens Minecraft with query/read rights only.

## Residual and design risks

- DLL injection and in-process memory hooks are inherently high-risk operations. A Minecraft update can still cause a
  crash even when identity and version checks pass, and antivirus products may still classify the behavior.
- Custom DLL mode deliberately executes the selected DLL inside Minecraft. Selecting a DLL is equivalent to trusting
  its native code; unsigned and incompatible DLLs are accepted by product requirement.
- The signing certificate is self-signed and is added to the machine Trusted People store on first install. Protect the
  private key. A publicly trusted code-signing service or managed artifact signing is preferred for public release.
- JavaScript plugins are untrusted and retain network/WebSocket capabilities. Their filesystem access is scoped, but
  they do not run in an OS-level process sandbox. Review plugin source before installation.
- The Nova Shop backend is a loopback development service, not a production authentication or payment system. Do not
  expose it on a non-loopback interface without real account authentication, TLS, rate limiting, and deployment review.
- No claim is made that Microsoft, Mojang, Discord, or antivirus vendors endorse the launcher.
- The Windows-managed switch intentionally leaves the selected Minecraft version installed after the game exits,
  matching the referenced launcher design. Selecting another downloaded version replaces it through the same Windows
  API. LatiNova does not maintain a private unpacked registration or decrypt MSIXVC content.
- Downloaded packages can consume several gigabytes. The downloader checks free space plus a 512 MB reserve, but the
  user remains responsible for local storage and for complying with the Minecraft terms applicable to their files.
- Xbox CDN links in the upstream catalog are normalized to HTTPS before use. Catalog MD5 is not treated as the
  authenticity boundary; Windows rejection of an invalid Microsoft package signature remains mandatory.
- `packageManagement` is a restricted Windows capability. Microsoft documents that restricted-capability packages can
  be sideloaded without Store approval, but this build is not prepared or approved for Microsoft Store submission.
- Historical-version CDN download and downgrade are not documented by Microsoft as a supported retail-consumer
  workflow. See `LEGAL_REVIEW.md`; written authorization or qualified legal review is still required before claiming
  the feature is approved or guaranteed compliant.
- The MIT helper intentionally omits the PC Bootstrapper update flow. This fixes old-version startup but may conflict
  with Microsoft service terms or future platform policy even though Store signature and runtime entitlement remain
  intact. Public distribution must not describe the workflow as Microsoft-approved or guaranteed legal.

## Verification performed

- C# launcher and installer: Release x64 rebuild with warning level 4 and warnings as errors.
- Previous 1.0 MSIX: signed package generated with transparent target-size resources and version `1.0.0.0`.
- Installation: same-version repair completed; installed package status `Ok`; launched process remained responsive.
- Signatures: launcher, embedded release DLL, MSIX, and one-file installer validated with the expected signer and RFC
  3161 timestamp.
- C++ targeted security test: `SafePathTests.cpp` compiled with MSVC C++ latest, `/GS`, `/sdl`, CFG, DEP, ASLR, and CET;
  test process exited successfully.
- Python Nova Shop tests: 6 tests passed, including the local-CSRF regression cases.
- Secret scan: no PFX, PEM private key, key file, client secret, API key, or token was included.
- Removed loose-import prototype evaluation: the local 1.26.42.01 release passed Microsoft signature/configuration/layout analysis (37,643
  allowlisted files, 2.03 GiB); traversal was rejected; a 372-character copy path passed; cancelled/failed staging
  data was removed. The full instance was temporarily registered, its exact managed executable was launched, the
  process was stopped, and the previous Levi-managed loose registration was restored with status `Ok`; no recovery
  journal remained.
- Release catalog: 24 release entries from 1.21.120.04 through 1.26.42.01 passed the bounded schema, version, MD5,
  extension, and Microsoft CDN allowlist validation. Historical loose-version discovery was tested read-only and was
  subsequently removed from the product.
- Version Manager 1.1: Release x64 compiled with warnings as errors; 24 catalog entries loaded; the native downloader
  queried `assets1.xboxlive.com` for 1.26.42.01 and received the expected 2,489,954,304-byte content length without
  downloading the package; Gaming Services was detected. The deployment preflight correctly rejected the current
  `SignatureKind=None` Levi loose registration before any package mutation. A full deployment was intentionally not
  run until a Store-signed Minecraft base is restored.
- Version Manager 1.1.2: Release x64 compiled with warnings as errors. UI automation invoked a Download action and
  confirmed that progress began with no confirmation dialog or additional top-level window; cancellation produced no
  new staging file. The final MSIX contains only `runFullTrust` and `packageManagement`, contains no launch-helper or
  Minecraft payload, embeds an exact copy of the complete source archive, and installs as `1.1.2.0`. Installer and MSIX
  signatures and RFC 3161 timestamps validated. The source archive contains the launcher code, legal review, and
  notices, with no Minecraft binary, MSIXVC, private-key file, or secret-key container.
- Version Manager 1.1.3: Release x64 rebuilt with warnings as errors. On the installed Store-signed
  `1.26.42.01` package, the same-version deployment preflight completed in 51.9 ms instead of re-hashing the saved
  2.32 GiB MSIXVC (a separate full MD5 benchmark took 6.56 seconds). Version changes still take the full archive hash
  and Windows signature path. The Windows `IApplicationActivationManager` COM service was available and is now used
  instead of Explorer indirection; process detection polls every 100 ms with a 150 ms readiness delay. The final
  `1.1.3.0` MSIX and installer signatures validated, the MSIX has only `runFullTrust` and `packageManagement`, and its
  41 archive entries contain no Minecraft executable, MSIXVC, or launch-helper payload. The 72-entry source archive
  contains the launcher source, license, and legal review with none of the scanned private-key or Minecraft payload
  types.
- Version Manager 1.1.4: Release x64 launcher and native core compiled with warnings as errors. Rewriting the six
  tested 1.26.30.05 Xbox CDN candidates to HTTPS consistently failed Windows hostname/certificate trust with WinHTTP
  12175; the catalog-provided HTTP endpoint returned status 200 and the expected 2,209,456,128-byte content length.
  The fixed GitHub catalog remains HTTPS-only and redirect-restricted, and the package path still requires both its
  catalog MD5 and final Windows Store signature. The native HTTP HEAD returned the exact expected length; a GET probe
  reached the downloader and cancelled with no final file and a zero-byte partial. The completed-file writer is now
  closed before MD5 verification, eliminating the observed sharing violation and redundant retry. Store process
  discovery now uses `QueryFullProcessImageName` with limited query access; extended (`\\?\`) and ordinary paths
  normalized to the same value in the regression check.
- Version Manager 1.1.5: Windows package staging and registration were separated. On the Store-signed test system,
  staging the saved 1.26.42.01 MSIXVC while 1.26.21.01 remained registered took 58.198 seconds; registering the staged
  full name took 1.677 seconds and retained `SignatureKind=Store`. Staging 1.26.21.01 while 1.26.42.01 remained
  registered took 62.033 seconds, and switching back by full-name registration took 1.087 seconds. Windows removed
  the former version's staged entry after registration, so the launcher does not claim that every catalog version can
  remain ready simultaneously. Packaged-app integration tests showed that cross-user `FindPackages` enumeration and
  on-demand full-name registration are access denied for this sideloaded package, so the release uses neither path.
  Instead, download completion uses `StagePackageByUriAsync`, and selection passes the same URI to the already permitted
  `AddPackageByUriAsync` path. PowerShell's equivalent add operation reused the staged 1.26.42.01 package in 1.135 seconds
  and retained `SignatureKind=Store`. Downloads are staged before completion is reported, and every successful switch
  is followed by Store-signature and exact-version checks.
- Version Manager 1.1.6: the Aetopia MIT helper was rebuilt from the included 2,612-byte C source with a fixed image
  base and zero PE timestamp; two clean builds produced the same SHA-256
  `D527DBD2DDCF6175FD5B1133116135CC193ADA55BA9CC9C8EE58C45735D56A7D`. From the packaged LatiNova capability
  context it was written beside the exact Store-signed 1.26.21.01 package and re-hashed. AUMID activation produced
  the old-version `Minecraft.Windows.exe` process in about 0.3 seconds and a responsive Minecraft window without the
  red forced-update screen. The package remained `SignatureKind=Store` and `Status=Ok`; no Minecraft executable,
  manifest, license token, or user data was modified. A prototype loose-instance launch was also evaluated before that
  feature was removed. The live Store process reported its physical
  `D:\XboxGames\Minecraft for Windows\Content` path while Windows reported the registered package under
  `WindowsApps`; monitoring now accepts that alias only after the process package family, expected Store registration,
  and exact game version all match. The shipped release does not select loose instances.
- Fast-launch vault evaluation: a read-only plan found 37,643 files and 2,182,618,967 bytes, but Gaming Services
  refused access to the protected executable through both the package and physical XboxGames paths. No staging or
  instance data remained after cleanup. The feature and its direct-launch/loose-registration services were then
  removed; the shipped release uses only the Windows-managed package path.
