Skip to content

RESEARCH.md

Latest commit

 

History

History
161 lines (129 loc) · 21.6 KB

RESEARCH.md

File metadata and controls

161 lines (129 loc) · 21.6 KB
Raw

Research: MSStoreHelper

Date: 2026-07-29. Updated 2026-09-05.

Current release status

MSStoreHelper v3.36.1 now has a distinct product identity, four current private-desktop screenshots, a focused README, and a repeatable local Windows release build. The complete suite contains 191 passing tests. The build produces a portable EXE and ZIP, a Python wheel, an artifact manifest, and SHA-256 checksums. A code-signing certificate is still needed to remove the Windows publisher warning.

Confidence labels: Verified means reproduced or directly inspected; Likely means supported by code plus external evidence; Needs live validation means the conclusion depends on a specific Windows SKU, policy, or network.

Executive Summary

Verified: MSStoreHelper v3.35.0 is a Windows Python/CustomTkinter utility for finding, downloading, validating, installing, repairing, caching, mirroring, and exporting Microsoft Store AppX/MSIX packages without relying on the Store UI. Its strongest shape is unusually broad local/offline coverage. 93 tests plus 4 subtests passed on 2026-07-29, and dependency selection, resumable downloads, cache history, CLI automation, repair recipes, diagnostics, and four deployment exports already exist. Its highest-value direction is not more catalog breadth; it is making every untrusted package, privileged command, destructive repair, persisted state transition, and LAN request obey one auditable trust contract.

Top opportunities, in priority order:

  1. Enforce one package-ingress boundary for source URLs, filenames, local paths, staging, and PowerShell arguments.
  2. Turn signature, chain, manifest identity, publisher, requested-product binding, and revocation state into a mandatory pre-promotion trust gate.
  3. Replace best-effort repair scripts with previewable, fail-closed transactions and verified in-app restore.
  4. Replace generic directory mirroring with an allowlisted, privacy-preserving package service.
  5. Make diagnostics recursively redact credentials, URL secrets, and Windows paths before serialization.
  6. Add one operation coordinator, truthful typed outcomes, subprocess deadlines, and atomic versioned state migrations.
  7. Complete downloader protocol validation and refresh expired Store URLs instead of trusting persisted links.
  8. Establish rendered accessibility, supported-runtime, clean-build, and real Windows integration gates before adding parity features.
  9. Then add offline repository consumption, official Store/WinGet handoff, policy profiles, localization, and optional block-map delta downloads.

Product Map

  • Verified: core discovery/download workflow is curated or live Store search → product ID → RG-Adguard resolution → architecture/dependency selection → download, verify, cache, install, update, diff, or rollback.
  • Verified: repair workflow diagnoses sources and runs Store, provisioning, licensing, or cache recipes with backup manifests and generated restore scripts.
  • Verified: deployment workflow exports DISM PowerShell, WinGet import JSON, App Installer XML/package folders, or IntuneWin content and can expose cached packages through local HTTP.
  • Verified: intended personas are LTSC/restricted-image administrators, repair-bench technicians, offline deployment builders, Intune/RMM operators, and power users recovering broken built-in apps.
  • Verified: platform/distribution is MIT-licensed Windows 10/11 including LTSC with a source/wheel entry point as of 2026-07-29; pyproject.toml claims Python 3.8+, although the pinned dependency set cannot satisfy that floor.
  • Verified: data flows are Microsoft Store search/product pages → product ID and notes; RG-Adguard HTML → expiring CDN links; package ZIP manifests and Windows Authenticode → identity/trust; PowerShell/AppX, DISM, WinGet, Store CLI, and IntuneWinAppUtil → local or fleet deployment; %APPDATA%\MSStoreHelper and cache folders → profiles, queue state, repair records, and artifact history.

Competitive Landscape

  • Verified: Raven: does direct Store catalog/search/details, dependency-aware concurrent queues, pause/resume, architecture/OS filtering, block-map deltas, exports, localization, structured logs, and self-contained releases well. Learn its Store-facing source boundary, per-item operations, rich package context, and delta design; avoid its developer-certificate workaround and any trust bypass.
  • Verified: StoreLib / Alt App Installer: isolate Microsoft Store catalog and FE3 delivery protocols, refresh expiring links, and install multi-part dependency sets well. Learn the adapter boundary, market/locale inputs, and URL-refresh lifecycle; avoid treating undocumented Microsoft endpoints as a guaranteed public contract.
  • Verified: WinGet: provides first-party source selection, pinning, import/export, configuration, proxy, download, repair, and machine-readable automation. Learn explicit source/policy/error semantics and declarative configuration; avoid replacing MSStoreHelper’s Store-less/offline path with an App Installer dependency.
  • Verified: UniGetUI: presents multiple package managers through consistent discovery, filters, bulk actions, version ignore/pins, history, import/export, translations, and update notifications. Learn queue grouping, per-package options, and visible operation history; avoid broadening into a general package-manager frontend.
  • Verified: query-store-links / RgAdguardDownloader: expose product/PFN/URL lookup, ring selection, architecture filtering, companion files, streaming results, and self-contained Windows builds. Learn typed streamed results and explicit package filters; avoid proxy-only trust and undocumented-service assumptions.
  • Verified: LTSC-Add-MicrosoftStore family: demonstrates demand for dependency-complete, offline, minimal/full LTSC recovery. Learn capability-specific prerequisites and transparent install ordering; avoid redistributing stale Microsoft binaries, deleting optional components, or promising one recipe across every LTSC build.
  • Verified: Patch My PC / PDQ Deploy / Ninite Pro: commercialize update rings, approvals, detection, retry, cache, audit history, reporting, and bandwidth controls. Learn local policy profiles, deterministic detection, retry evidence, and staged rollout exports; avoid becoming a cloud fleet-management server.
  • Verified: Intune Enterprise App Management: treats architecture/language selection, detection rules, assignments, supersedence, and update review as first-class deployment data. Learn exportable detection/supersedence metadata and explicit update approval; avoid assuming Intune’s paid catalog or 24-hour validation service exists locally.

Security, Privacy, and Reliability

  • Verified: path traversal and privileged command injection boundary: MSStoreHelper.py::StoreAPI.get_packages_with_diagnostics accepts RG-Adguard anchor text and href as FileName/Url; _download_worker, _cli_download_selected, _appinstaller_record, _queue_package_source_path, and prepare_intune_package_source join that name directly under caller-selected folders. A safe 2026-07-29 reproduction resolved ..\..\Users\Public\payload.msix outside C:\Temp\MSStoreHelperDownloads. StoreAPI.install_package then interpolates the path inside a double-quoted elevated PowerShell command, where $() and backticks are active. Central basename canonicalization, real-path containment, URL policy, and argument-safe PowerShell are mandatory.
  • Verified: failed certificate chains are accepted: MSStoreHelper.py::verify_package_signature computes ChainValid and a root thumbprint with revocation forced to NoCheck, but msstore_package_resolution.py::signature_info_is_valid_microsoft ignores ChainValid and accepts a case-insensitive "microsoft" substring. A safe reproduction accepted ChainValid=False with root CN=Not Microsoft Test Root; the v3.35.0 tests/test_package_resolution.py fixture codifies that behavior. Trust must bind a valid Windows chain to the signed manifest publisher/identity and expected Store identity before cache, mirror, export, rollback, or install.
  • Verified: mirror directory disclosure: MSStoreHelper.py::mirror_http_handler subclasses SimpleHTTPRequestHandler(directory=folder). A safe localhost reproduction retrieved an unindexed notes-secret.txt; Python also documents directory listing and symlink-following behavior. The index exposes absolute CacheFolder, stored manifests retain source URLs and paths, non-loopback use has no exposure interlock, and access logging is discarded.
  • Verified: repair can destroy state after backup failure: get_store_repair_steps, get_provisioning_repair_steps, get_licensing_reset_steps, and get_cache_rebuild_steps stop processes, move caches/licensing data, delete registry state, and reset network services. Many commands suppress item errors, registry deletion is not blocked by failed export, process exit zero becomes “success,” repair buttons run without plan review or confirmation, timestamp-only backup names can collide, and generated restore consumes backups without post-restore verification. This needs a transaction model, not additional best-effort commands.
  • Verified: diagnostic redaction is bypassable: StoreAPI.redact_diagnostic_text redacts only the first whitespace-delimited bearer/password fragment. Safe tests left abc.def.ghi from Authorization: Bearer abc.def.ghi and secret from password = spaced secret; raw SourceHealth is serialized twice and URL query credentials are not structurally removed. Redaction must happen recursively before any ZIP member is written, with a user preview.
  • Verified: download validation is incomplete: StoreAPI.get_file_size and download_file follow source-controlled redirects without a scheme/final-host/public-address policy or byte/free-space limit. Resume does not bind .part state to URL, ETag, or Last-Modified, validate the returned Content-Range start, or recover from 416. Persisted queue URLs can expire and are used without re-resolution. RFC 9110 requires validators such as If-Range when continuing a representation that may have changed.
  • Verified: state can corrupt or cross architectures: profile, queue, cache, mirror-index, and repair manifests are directly overwritten without a shared lock or atomic replace; most parse errors silently reset to defaults. Cache history is keyed only by package identity, artifact_metadata omits architecture/type, and rollback/diff do not enforce architecture compatibility. Versioned schemas, migrations, corruption quarantine, and identity+architecture+query keys are required.
  • Verified: runtime and dependency claims conflict: pyproject.toml and README.md advertise Python 3.8+, but requests==2.32.5 requires at least Python 3.9 and Requests 2.34.2 requires Python 3.10+. Python 3.8 and 3.9 are end-of-life. pip-audit flags Requests 2.32.5 for CVE-2026-25645; the advisory says ordinary Requests usage is unaffected and the repository does not call extract_zipped_paths, so direct exploitability here is low, but the stale pin and untested environment remain release defects.
  • Likely: remote metadata can probe local networks: automatic HEAD/GET against arbitrary proxy-provided URLs is an SSRF-like local-network probe surface (StoreAPI.get_file_size, _fetch_sizes_async, download_file). Exploitability depends on the RG-Adguard response path and local network, but CWE-918 controls still fit this privileged desktop client.

Architecture Assessment

  • Verified: MSStoreHelper.py is 5,303 lines and combines dependency checks, Store clients, persistence, download/cache logic, HTTP serving, archive inspection, export generators, PowerShell execution, destructive repair, CustomTkinter views, and CLI dispatch. Preserve the existing pure seams in msstore_package_resolution.py and store_sources.py; extract a typed command runner, trust policy, downloader/cache repository, versioned state store, repair planner, exporters, operation coordinator, and GUI view model. The CLI should not import or initialize CustomTkinter.
  • Verified: no operation coordinator prevents repeated Download, Install, Search, or Repair launches. Daemon workers share .part and JSON files, read Tk variables off the UI thread, have no coherent cancellation/shutdown contract, and most subprocess calls have no timeout. Typed operation results must drive GUI status, CLI exit codes, journals, and diagnostics from one source.
  • Verified: package/install modeling is incomplete. App Installer export treats the first app as main and unrelated queued apps as optional packages; bundle diff reads only the outer bundle manifest; installed-inventory errors become an empty inventory; rollback selection ignores architecture; and separate Add-AppxPackage calls allow partial dependency installs. Build an inspected install plan per main identity and use documented -DependencyPath/optional-package semantics or reject ambiguous exports.
  • Verified: global GUI status reports green completion after partial download/install failures. Search-source errors become “No apps found,” destructive and non-destructive actions share the label “Repair Store,” and cached/offline artifacts can be written but not browsed or imported. Result severity and recovery actions need to be explicit at the surface, not hidden in the collapsed log.
  • Verified: 2026-07-29 rendered dark/light/system checks at 100%, 125%, and 150% found clipped center/queue actions at 1000×600 and 1280×800, near-invisible light-theme outline text, and missing sidebar content. Theme.TEXT_MUTED measures about 3.584:1 on the dark card and 4.437:1 on the light app background, while tests/test_accessibility.py incorrectly applies the 3:1 large-text threshold to 10 to 12 pt text. Selection checkboxes have empty labels; keyboard coverage is effectively Enter-to-search; focus, Escape, High Contrast, Narrator/UIA names, and rendered regression tests are absent.
  • Verified: the 93-test suite is fast and valuable but mocks the riskiest boundaries. Missing gates include malicious name/URL fixtures, invalid-chain/publisher/identity cases, adversarial redaction, concurrent/corrupt state recovery, bundle and multi-app export cases, real PowerShell/AppX/DISM repair-and-restore checks, supported-Python locked installs, clean wheel/entry-point launch, rendered GUI and UI Automation checks, and an unsigned portable artifact smoke test.
  • Verified: no tracked CI/release workflow, transitive hashed lock, SBOM, or supported Python/Windows matrix exists. The generic wheelhouse contains interpreter-specific material, so offline instructions are not portable across the advertised floor. CustomTkinter 6.0 changes button/focus behavior and should be evaluated only after rendered/keyboard baselines exist.
  • Verified: documentation drift remains: README.md overstates the supported Python floor and presents 0.0.0.0 mirror use without a threat warning; CHANGELOG.md contains a malformed v3.2.0 heading; CLAUDE.md understates the repository surface; and no durable trust model or destructive-repair recovery guide exists.

Rejected Ideas

  • Public plugin ecosystem: Rejected: Raven, UniGetUI, and WinGet demonstrate useful internal source/provider boundaries, but MSStoreHelper has no stable permission, trust, compatibility, or migration contract for third-party code. Build internal adapters first; do not execute plugins in this privileged process.
  • Mobile companion: Rejected: all core value depends on local Windows AppX/MSIX, certificate stores, PowerShell, DISM, Store policy, and machine repair state.
  • Multi-user/cloud management server: Rejected: Patch My PC, PDQ, Action1, and Intune show the maintenance, identity, secrets, tenancy, reporting, and agent burden this would add. Keep deterministic local profiles/exports rather than becoming an RMM.
  • Paid/restricted app acquisition through scraped authentication: Rejected: entitlement and licensing cannot be proven by the v3.35.0 RG-Adguard flow; hexadecimal233’s feature claim is not an acceptable trust or licensing basis.
  • Bundled Microsoft binaries or “strip optional components” LTSC mode: Rejected: LTSC-Add repositories prove demand, but pinned Microsoft packages age quickly and Microsoft’s troubleshooting guidance does not support removing the Store. Detect exact prerequisites and download fresh Microsoft-signed packages at execution instead.
  • Automatic wsreset -i fallback: Rejected as a default: the switch appears in community LTSC recipes but lacks a durable Microsoft contract. A future opt-in may be considered only after SKU-specific live validation and a previewable repair plan.
  • Store CLI/WinGet-only replacement: Rejected: Microsoft’s store install/update path is useful when available, but Store policy and App Installer availability are exactly what this project cannot assume.
  • Automatic self-update: Rejected on 2026-07-29: Raven shows the convenience, but this repository has no authenticated update-metadata channel or verified release pipeline. Publish unsigned artifacts with hashes/SBOM and a manual release notice before considering an updater.
  • Windows Update orchestration integration: Under consideration, not roadmap-ready: Microsoft announced the orchestration platform as private preview; there is no public stable API contract to implement against on 2026-07-29.

Sources

Project

Direct and Adjacent OSS

Commercial and Managed Deployment

Microsoft Platform

Standards, Security, Dependencies, and Research

Community Signal

Open Questions

  • Needs live validation: Which exact Windows 10/11 and LTSC releases, editions, servicing baselines, and Server variants must be release-gated? The README’s broad “Windows 10/11 including LTSC” claim is not precise enough to define repair and AppX integration acceptance.
  • Needs live validation: Does the project owner accept the legal and maintenance risk of enabling undocumented StoreEdgeFD/FE3 package-link resolution by default? StoreLib and Raven prove feasibility, but no supported public end-user download API contract was found.