Skip to content

fix: protect IFEO debugger and confirm privacy registry writes#813

Merged
laurentiu021 merged 1 commit into
mainfrom
feat/2c-registry-ifeo-confirm-reversibility
Jun 8, 2026
Merged

fix: protect IFEO debugger and confirm privacy registry writes#813
laurentiu021 merged 1 commit into
mainfrom
feat/2c-registry-ifeo-confirm-reversibility

Conversation

@laurentiu021

Copy link
Copy Markdown
Owner

Round 2c of the audit — registry-mutating surfaces made safer and confirmed.

App Blocker no longer clobbers an existing debugger (P1)

AppBlockerService.BlockApp wrote its IFEO Debugger value unconditionally. If the target already had a Debugger set (e.g. a legitimately-debugged app), it was overwritten — breaking that setup, and unrecoverable since UnblockApp only removes SysManager's own value. BlockApp now refuses when an external Debugger is already present, leaving it intact.

Privacy changes now confirm before writing the registry

PrivacyViewModel.ApplyChanges wrote toggles to the registry with no prompt. It now calls DialogService.Confirm first (stating the change count and how to revert); declining keeps the changes pending and writes nothing.

Scope note

ServicesViewModel (start/stop/disable) and AppBlockerViewModel already confirmed; ContextMenu toggles are instantly reversible — all left as-is to avoid redundant prompts.

Test & regression

  • PrivacyViewModelTests: a declined confirm writes nothing and keeps the change pending (injected IDialogService).
  • Full-solution regression build (main + Tests + IntegrationTests + UITests): 0 warnings, 0 errors.
  • Version 1.20.1.

Round 2c of the audit — registry-mutating surfaces made safer/confirmed:

- AppBlockerService.BlockApp wrote its IFEO Debugger value unconditionally,
  clobbering any existing one. If that value belonged to a legitimately-debugged
  app it was both broken and unrecoverable (UnblockApp only removes SysManager's
  own value). BlockApp now refuses when an external Debugger is already present.
- PrivacyViewModel.ApplyChanges wrote registry toggles with no confirmation.
  It now prompts via DialogService.Confirm (stating the change count and how to
  revert); declining keeps changes pending and writes nothing.

ServicesViewModel (start/stop/disable) and AppBlockerViewModel already confirmed,
and ContextMenu toggles are instantly reversible, so they were left as-is.

Test: PrivacyViewModelTests asserts a declined confirm writes nothing and keeps
the change pending.
@laurentiu021 laurentiu021 merged commit 2c2a579 into main Jun 8, 2026
4 checks passed
@laurentiu021 laurentiu021 deleted the feat/2c-registry-ifeo-confirm-reversibility branch June 8, 2026 11:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant