AI-assisted security review of GTweak: high-risk modules and trust-improvement suggestions

[wannabexaker]

GTweak Security and Behavior Scan Report

Report date: 2026-05-12
Workspace reviewed: C:\Projects\GTweak-main
Observed executable: local release executable copy, anonymized as <UserProfile>\Desktop\GTweak.exe
Executable SHA256: 29AC8269EBFBCF468590757690E3B688D6EDBE1233A13D3451E73605E520A68E
Executable signature status: Not digitally signed
Assessment stance: This report does not assume Microsoft is trustworthy because it is a large vendor, and it does not assume GTweak is malicious because it is unsigned. The assessment is based on observable source code behavior, UI structure visible in the repository, and limited local host evidence.

Assessment scope: Expanded static source audit plus limited live-host checks. This is not a full forensic malware-lab analysis.

Executive Summary

GTweak is a high-privilege Windows debloating, privacy, maintenance, activation, and system modification utility. The reviewed source and UI structure show an application whose main workflow is interactive: it detects the current Windows state, displays many controls, and lets the user choose specific actions through toggles, buttons, import profiles, addon scripts, and download buttons.

The UI/source structure materially changes the interpretation of several findings. Most heavy actions are not shown as silent automatic behavior. Defender disabling, UAC changes, Windows Update pause/disable behavior, service changes, app removal, restore point changes, script execution, and tool downloads are exposed as user-controlled UI actions. The application can perform those actions, but the evidence does not support saying that it automatically disables Defender, disables UAC, removes apps, or stops services just because it is launched.

I did not find source-code evidence of classic spyware behavior such as credential theft, browser profile theft, wallet theft, keylogging, screen/audio capture for exfiltration, hidden remote command execution, or automatic upload of personal files. I also did not observe active GTweak network connections or GTweak persistence entries on the live system during the audit.

However, GTweak still contains behavior that is legitimately suspicious from a security-tooling perspective:

• It requires administrator execution.
• During startup, it starts the TrustedInstaller service and attempts to add the running GTweak executable/path to Microsoft Defender exclusions.
• It includes mechanisms to run commands as TrustedInstaller and, in some flows, through NSudo-like elevated execution.
• It embeds compressed helper executables/resources, including NSudoLC.gz and DisablingWD.gz, which are decompressed to disk when needed.
• It exposes user-triggered controls that can disable Defender, SmartScreen, VBS, UAC, Windows Update behavior, firewall behavior, and many Windows services.
• It can take ownership of protected Windows files/directories and remove WindowsApps/Edge/WebView-related components when the user chooses app removal.
• Its Defender-disable flow can modify Winlogon\Shell, set Safe Mode boot with bcdedit, reboot the system, and run a helper during Safe Mode unlock/recovery.
• It can execute user-selected .ps1, .bat, .cmd, and .reg files, optionally as TrustedInstaller.
• It includes Windows activation logic using HWID/KMS mechanisms and a third-party KMS host.

These behaviors are enough to explain antivirus detections such as "Disabler", "HackTool", or "Trojan-like" without proving malicious intent. The strongest conclusion is:

GTweak does not look like a conventional backdoor or data stealer from the reviewed evidence. It is better described as a powerful local system-control tool that intentionally gives the user access to security-sensitive Windows changes. Its main risk is local system integrity, not observed spying.

Evidence Weighting

Not every suspicious-looking behavior deserves the same weight.

Highest-weight findings:

• Startup Defender exclusion attempt.
• TrustedInstaller/NSudo-level execution.
• Embedded helper executables used for Defender/security-control modification.
• Defender/Safe Mode/Winlogon Shell modification path.
• Windows activation module with HWID/KMS behavior and third-party KMS host.
• Addons execution with optional TrustedInstaller privileges.
• Unsigned release binary combined with high-privilege system modification capability.

These are high-impact because they affect security boundaries, boot/login behavior, licensing state, or arbitrary code execution.

Medium-weight findings:

• Update checks and self-update behavior.
• Toolset downloader.
• Hosts/firewall domain blocking.
• Import profiles that can apply many changes at once.
• UAC, Windows Update, and service toggles when user-triggered.

These are security-relevant, but their risk depends strongly on user action, configuration, and source trust.

Lower-weight findings:

• UI settings persistence under HKCU\Software\GTweak.
• Hardware/system inventory displayed in the System Information page.
• Public IP display feature, when understood as an explicit UI feature.
• Keyboard hook used by the overlay to suppress specific system key combinations.

These should be documented, but they are not strong malware indicators by themselves based on the reviewed code.

Scope and Methodology

This report now covers a broader static audit than the initial targeted review.

What was reviewed:

• 273 files under .Source\GTweak.
• Application startup and manifest behavior.
• Network call sites and hard-coded endpoints.
• Command execution helpers and TrustedInstaller execution paths.
• Registry, service, scheduled task, firewall, hosts, AppX, Defender, UAC, Windows Update, and activation code paths.
• Embedded resource usage, including compressed executable resources and activation tickets.
• Addons/script execution and Toolset download flows.
• UI XAML/source structure showing how controls are exposed to users.
• Limited live-host checks for active GTweak network sockets, startup persistence, scheduled-task persistence, Defender/UAC/firewall state, helper folders, hosts state, and signature/hash.

What was not performed:

• Full binary reverse engineering of the compiled .exe.
• Dynamic malware sandbox tracing with Procmon/ETW/Sysmon packet capture from a clean VM.
• Memory dump analysis.
• Diffing every release binary against a reproducible local build.
• Long-term network monitoring after interacting with every toggle.
• Testing every destructive option, because that would intentionally alter or damage the current Windows installation.

Therefore, this is an expanded static source/security audit with limited live validation, not an absolute proof of safety.

Automatic vs User-Triggered Behavior

This distinction matters.

Automatic behavior observed in source startup flow:

• Enforces single-instance behavior.
• Checks administrator privileges and supported Windows version.
• Loads settings, theme, language, hardware/system information, installed package data, service/process counts, memory/CPU status.
• Starts the TrustedInstaller service.
• Attempts to add the GTweak executable/path to Defender exclusions.
• Performs public IP lookup for the system information view.
• Performs update/version checks when update checking is enabled.

User-triggered behavior exposed by UI:

• Defender/SmartScreen/VBS toggle.
• UAC toggle.
• Windows Update pause/disable-related toggles.
• Firewall-related toggles.
• Service enable/disable toggles.
• Privacy/telemetry/hosts blocking toggles.
• App removal actions.
• Restore point creation/recovery and restore status enable/disable.
• Memory cleanup, NTFS compression, registry backup.
• Addons script execution, including the optional "Run as TrustedInstaller" checkbox.
• Toolset downloads.
• Windows activation button.
• Self-delete button.
• Importing a configuration profile that can apply selected tweaks in bulk.

The security report therefore uses "can" or "capability" for most invasive actions. The exception is the startup Defender exclusion attempt and startup checks, which are automatic according to source code.

UI Evidence

The repository UI files and reviewed local UI context show the application as an interactive control panel:

• Services page: many individual service-related toggles. It presents service changes as selectable tweaks.
• Utilities page: explicit buttons for Windows Activation, Recovery Point, Restore Status, memory cleanup, NTFS compression, and registry backup. These are not silent background actions.
• Confidentiality page: telemetry/privacy toggles. These are visible user choices.
• Interface page: UI/Windows shell behavior toggles, including Copilot/Recall-related and ad/suggestion-related settings.
• Applications page: app selection/removal UI with warnings for permanent deletion. This supports app deletion being a user action.
• System page: toggles for Defender, UAC, Microsoft Store app updates, firewall, background apps, Windows Update pause, and other system behavior.
• System information page: OS, hardware, devices, adapters, process/service counts, and public IP display. This explains the system inventory and public IP lookup behavior.
• Addons page: requires the user to select a directory before scripts can be run and exposes a "Run as TrustedInstaller" checkbox.
• Toolset page: searchable list of third-party tools with explicit download actions.

Local Live-System Findings

The following was observed after GTweak had been run on the current PC. Personal account details have been anonymized.

Area	Finding
Running process	GTweak.exe was running from <UserProfile>\Desktop\GTweak.exe.
Release copy	The local release copy had the same SHA256 as the observed desktop executable.
External GTweak network	No active TCP/UDP endpoint was observed for the GTweak process during the live check.
Startup persistence	No GTweak startup entry was found in user or machine Run locations.
Scheduled persistence	No GTweak scheduled task was found.
Defender state	Defender appeared active: realtime, behavior, IOAV, on-access protection, and Tamper Protection were enabled.
UAC state	UAC appeared enabled: EnableLUA=1, ConsentPromptBehaviorAdmin=5, PromptOnSecureDesktop=1.
Firewall service	Windows Firewall service mpssvc was running and automatic.
TrustedInstaller	TrustedInstaller was stopped/manual at audit time.
GTweak helper folders	C:\ProgramData\GTweak and C:\Windows\System32\Config\WDBackup_GTweak were not present at audit time.
Hosts file	C:\Windows\System32\drivers\etc\hosts contained 1396 0.0.0.0 blocking entries.
Hosts backup	C:\Windows\System32\drivers\etc\hosts (Default GTweak) existed.
Defender exclusions	Direct registry/cmdlet visibility for Defender exclusions returned access restrictions, so exclusion success could not be fully proven or disproven.

Interpretation: the live system did not show evidence that GTweak had disabled Defender, disabled UAC, installed persistence, or maintained active outbound connections at the time checked. The confirmed local change was the hosts-file blocklist and GTweak hosts backup, which is consistent with the Confidentiality page's Microsoft/telemetry domain-blocking feature.

Build and Release Workflow

The repository includes .github/workflows/build.yaml, which:

1. Checks out the repository.
2. Sets up MSBuild.
3. Restores NuGet packages.
4. Builds GTweak.sln in Release.
5. Uploads .Source/GTweak/bin/Release/ as a build artifact.

This improves transparency because the project can be built from source. It does not fully prove that the public release .exe is reproducibly identical to the source tree unless release signing, reproducible build hashes, or artifact provenance are provided.

The reviewed executable is unsigned. Unsigned software is not automatically malware, but it means Windows cannot verify publisher identity through Authenticode. For a tool that requests administrator rights and can alter Defender/UAC/services, the lack of a signature increases supply-chain trust risk.

License Clarification

There are two separate "license" topics in this project.

GTweak Project License

The repository itself is licensed under the BSD 3-Clause License in LICENSE.

Meaning: the author permits redistribution and modification in source or binary form as long as the copyright notice, conditions, and disclaimer are preserved, and the author's/contributors' names are not used for endorsement without permission.

Security relevance: this is a permissive open-source license. It does not prove safety, authenticity, or release-binary integrity. It only describes legal permission to use/redistribute the GTweak code.

Windows License / Activation Module

GTweak also has a "Windows Activation" card in the Utilities page. This is unrelated to the BSD license of the GTweak code.

Trigger: activation is user-triggered by pressing the "Activate" button. On startup, GTweak only checks activation status through WinLicenseHandler.LicenseStatus().

Startup check behavior: LicenseStatus() first queries WMI:

SoftwareLicensingProduct WHERE ApplicationID = '55c92734-d682-4d71-983e-d6ec3f16059f' and LicenseStatus = 1

If that WMI query throws a COMException, the fallback command runs slmgr.vbs /ato and checks the result. That means the normal startup path is a license-status check, but the error fallback can attempt standard Windows activation against Microsoft's normal activation mechanism.

Activation button behavior: WinLicenseHandler.StartActivation():

• Selects a key from embedded HWID/KMS key dictionaries based on the detected Windows edition.
• Installs the selected key with slmgr.vbs /ipk.
• Deletes ClipSVC GenuineTicket/Migration XML files.
• Temporarily changes the current user's Windows region value to US.
• Starts licensing-related services such as ClipSVC, wlidsvc, sppsvc, KeyIso, LicenseManager, and Winmgmt.
• Writes an embedded GenuineTicket.xml from Resources\Tickets.xml.
• Runs clipup -v -o.
• Runs slmgr.vbs /ato.
• If activation still fails, installs a KMS key, sets kms.digiboy.ir as the KMS host, and runs activation again.

Why it exists: the feature is intended to activate Windows through HWID-style ticket activation first, then KMS fallback.

Why it is high risk: this is outside the normal retail/OEM/Microsoft licensing flow, contacts a third-party KMS host if fallback is used, and modifies licensing artifacts/services. It is not needed for privacy, debloating, telemetry blocking, app removal, or system UI control.

Security interpretation: I do not see this module stealing license keys or exfiltrating data. The concern is legal/trust/operational risk, not observed spying.

Application Workflow

Startup Flow

Source evidence:

• App.xaml.cs
• Windows\LoadingWindow.xaml.cs
• Utilities\Controls\RunGuard.cs
• Utilities\Helpers\TrustedInstaller.cs
• app.manifest

Startup sequence:

1. App_Startup initializes settings, theme, language, single-instance behavior, OS compatibility checks, administrator checks, and device monitoring.
2. LoadingWindow.BackgroundWorker_DoWork() performs staged startup work:
   • Checks Windows activation status.
   • Starts the TrustedInstaller service.
   • Calls RunGuard.CheckingDefenderExclusions().
   • Reads bcdedit/network/bluetooth status.
   • Collects hardware, process count, service count, memory, and CPU data.
   • Reads installed AppX package data.
   • Performs public IP lookup.
   • Performs update-version checks.
3. MainWindow opens with the modules shown in the UI source: Utilities, Confidentiality, Interface, Applications, Services, System, Addons, and Toolset.

The application manifest requests:

requestedExecutionLevel level="requireAdministrator"

That means Windows should prompt for administrator rights before normal operation.

Settings Persistence

GTweak stores its own UI/config settings under:

HKCU\Software\GTweak

Observed/defined settings include:

• EnableNotifications
• EnableAutoUpdate
• EnableTopMost
• EnableIpBlur
• EnableSound
• VolumeLevel
• Language
• Theme
• AddonsPath
• DownloadPath

This is normal application settings persistence. I did not observe GTweak creating autorun persistence for itself.

Import Profile Workflow

GTweak supports exporting/importing .ini profiles.

How: SettingsEngine.OpenFileConfig() accepts a selected .ini only if it contains GTweak, author Greedeks, FormatVersion, and version 4. ImportWindow.ApplyTweaksWithProgress() then applies the listed tweak values.

Why: allow users to reuse selected tweak sets.

Risk: importing a config can apply many user-triggered toggles in bulk. This is not hidden persistence, but it can make high-impact changes faster than clicking individual toggles. The code intentionally applies System TglButton3 last, which is the Defender-related control.

Network Behavior

Public IP and Connectivity Checks

GTweak uses public network checks for connectivity and IP display. Code references include:

• free.freeipapi.com
• api.db-ip.com
• ipapi.co
• reallyfreegeoip.org
• get.geojs.io
• api.ip.sb
• whois.pconline.com.cn
• ip-api.com

How: NetworkProvider/hardware provider logic queries these services and stores/display public IP/country-style information.

Why: The System Information page displays network/system information, including the public IP address.

Risk: This discloses the user's public IP to third-party IP lookup services. That is not equivalent to spying by itself, but it is a privacy-relevant network call.

Update Checks

GTweak checks latest versions through:

• https://api.github.com/repos/greedeks/gtweak/releases/latest
• https://gitlab.com/api/v4/projects/Greedeks%2Fgtweak-ota-server/releases

How: NetworkProvider.ValidateVersionUpdates() resolves the latest version and update download URL.

Why: Show update availability and support updating GTweak.

Risk: Normal updater behavior, but still an outbound startup/network check if enabled.

Toolset Downloads

The Toolset page loads Resources\AppsCatalog.xml, which lists third-party tools such as NVIDIA App, AMD drivers, Rufus, Autoruns, CPU-Z, GPU-Z, CrystalDiskInfo, OCCT, and related utilities.

How: ToolsetDownloadService resolves download URLs from GitHub release APIs, SourceForge metadata/RSS, vendor pages, and TechPowerUp form flows. Downloads occur through explicit "Download" buttons shown in the Toolset screenshot.

Why: Convenience downloader for known tools.

Risk: It downloads executable/archive content from third-party sources. The risk depends on those upstream sources and URL matching logic. This is not silent persistence based on the reviewed UI/source.

Self-Update Download

GTweak has an update window that can download a newer release and replace the running executable.

How: UpdateWindow.xaml.cs uses WebClient.DownloadFileAsync() against the resolved update URL, then runs a command that kills the current process, deletes the old executable, renames the downloaded temporary file, and restarts GTweak.

Why: self-update.

Risk: because the public executable is unsigned and the report did not verify reproducible builds, the update path depends heavily on GitHub/GitLab account and transport trust. I did not find evidence that update downloads are hidden, but the trust model is weak compared with signed updates.

Activation Network Behavior

Windows activation logic includes a KMS fallback:

slmgr.vbs //b /skms kms.digiboy.ir

How: WinLicenseHandler.cs installs keys with slmgr.vbs, writes GenuineTicket XML from embedded resources, runs clipup, and falls back to KMS activation.

Why: Activate Windows when standard activation does not succeed.

Risk: This is a high legal/trust-risk area. It contacts a third-party KMS host and changes licensing state. It is user-triggered from the Utilities activation button, not needed for privacy/debloating.

Suspicious or High-Risk Findings

1. Startup Defender Exclusion Attempt

Trigger: Automatic during startup.

What it can do: Attempt to add the current GTweak executable/path to Microsoft Defender exclusions.

How it does it: RunGuard.CheckingDefenderExclusions() runs a PowerShell command through CommandExecutor.RunCommandAsTrustedInstaller(). It calls Get-MpPreference, checks ExclusionProcess and ExclusionPath, and calls Add-MpPreference if the current GTweak path is missing.

Where it happens: Utilities\Controls\RunGuard.cs, called by Windows\LoadingWindow.xaml.cs during the loading sequence.

Likely purpose: Reduce Defender interference because GTweak contains many actions Defender commonly flags: Defender tampering, service changes, protected-file ownership changes, NSudo/TrustedInstaller execution, and app removal.

Why it is suspicious: Malware often adds itself to Defender exclusions to avoid scanning. A system-control tool may do the same to avoid false positives, but it is still a strong trust-boundary crossing because this startup action is not presented as a separate explicit user choice in the reviewed source flow.

Local evidence: Defender remained active during audit. Exclusion visibility could not be conclusively verified because Defender exclusion reads returned access restrictions.

2. TrustedInstaller, NSudo, and Embedded Helper Executables

Trigger: Mixed. Startup starts the TrustedInstaller service automatically. Most actual privileged commands are tied to user-selected toggles/actions.

What it can do: Run commands/processes with privileges beyond a normal Administrator context.

How it does it: TrustedInstaller.cs uses service/process APIs, token/privilege APIs, parent-process manipulation, and CreateProcess mechanics. CommandExecutor.RunCommandAsTrustedInstaller() routes commands through this mechanism. Defender-management flows also decompress/use NSudoLC.exe and DisablingWD.exe from embedded gzip resources under:

C:\Windows\System32\Config\WDBackup_GTweak

The relevant resources are defined in Properties\Resources.resx as NSudoLC.gz and DisablingWD.gz, and written by ArchiveManager.Unarchive().

Where it is used: Defender management, Windows Update/service changes, file ownership changes, WindowsApps deletion, cleanup routines, Addons execution when selected, and scheduled-task changes.

Likely purpose: Many Windows files, registry keys, and services are protected even from Administrators. TrustedInstaller-level execution is used to bypass those restrictions and apply changes Microsoft does not expose cleanly.

Why it is suspicious: This is powerful security-tampering capability. It is not hidden in source, and the UI exposes many related controls, but if the binary were compromised or if a user runs unsafe addons, the privilege level could cause severe damage.

3. Defender, SmartScreen, VBS, Tamper Protection, Safe Mode, and Winlogon Controls

Trigger: User-triggered from the System page's Defender-related toggle and related routines. The UI source exposes this as a control, not an automatic action.

What it can do: Disable or re-enable Microsoft Defender and related security components.

How it does it:

• Decompresses helper binaries NSudoLC.exe and DisablingWD.exe.
• Runs Set-MpPreference commands.
• Writes Defender policy registry values such as DisableAntiSpyware, realtime protection policy keys, SmartScreen keys, cloud/MAPS reporting settings, and VBS-related keys.
• Alters service Start values for Defender-related services and drivers.
• Kills Defender/security processes.
• Uses takeown, icacls, and file renames to block or restore security executables.
• Adds broad Defender exclusions for fixed/removable drives when disabling.
• Modifies HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell to:

explorer.exe, <DefenderBackup>\DisablingWD.exe /unlock

• Runs bcdedit /set {current} safeboot minimal.
• Forces a reboot with shutdown /r /f /t 0.
• On restore/reactivation paths, it attempts to restore Defender tasks, service values, AppX packages, ACLs, and registry backups.

Where it happens: Utilities\Tweaks\DefenderManager\WindowsDefender.cs and Utilities\Tweaks\SystemTweaks.cs.

Likely purpose: Give users full control over Defender/SmartScreen/VBS when they intentionally reject those components.

Why it is suspicious: The behavior directly reduces endpoint security and overlaps with malware tradecraft. The Winlogon Shell modification plus Safe Mode boot is especially sensitive because it affects the login/session startup path. This explains antivirus detections. The key correction is that the reviewed evidence shows this as a capability exposed by UI/import profile, not something proven to have run automatically on this machine.

Local evidence: Defender protections were still enabled during audit.

4. UAC Control

Trigger: User-triggered from the System page's UAC toggle.

What it can do: Disable or re-enable User Account Control behavior.

How it does it: Writes values under:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

including EnableLUA, ConsentPromptBehaviorAdmin, PromptOnSecureDesktop, and related keys.

Where it happens: Utilities\Tweaks\SystemTweaks.cs.

Likely purpose: Remove prompts and friction from administrator actions.

Why it is suspicious: Disabling UAC weakens local privilege boundaries. It may be desired by some users, but it reduces safety.

Local evidence: UAC remained enabled during audit.

5. Windows Update and Service Controls

Trigger: User-triggered through System and Services page toggles, or through imported tweak profiles.

What it can do: Pause/disable Windows Update behavior and change many Windows service states.

How it does it:

• Writes Windows Update policy and UX registry keys such as NoAutoUpdate and pause fields.
• Changes services and scheduled tasks.
• Uses TrustedInstaller execution for protected service/task/file changes.
• Can rename/block update-related executables and delete update cache folders with ownership changes.

Where it happens: Utilities\Tweaks\SystemTweaks.cs, Utilities\Tweaks\ServicesTweaks.cs, Utilities\Managers\TaskSchedulerManager.cs, Utilities\Helpers\RegistryHelp.cs, and path definitions in PathLocator.cs.

Likely purpose: Stop forced updates, unwanted background services, update prompts, and Microsoft-controlled background activity.

Why it is suspicious: Blocking updates/services may improve user control but can leave vulnerabilities unpatched or break dependent Windows features.

Local evidence: Windows Update did not appear fully disabled in the live check.

6. Hosts File and Firewall Domain Blocking

Trigger: User-triggered from the Confidentiality page's "Network access to spy Microsoft domains" style privacy toggle. It may also be applied by an imported configuration profile.

What it can do: Block Microsoft, telemetry, advertising, analytics, and related domains/IPs.

How it does it:

• Backs up the hosts file to hosts (Default GTweak).
• Appends 0.0.0.0 domain entries from Resources\Blocklist.txt.
• Creates firewall rules named like GTweak - Spy domain names with remote IP blocks associated with Microsoft data-collection endpoints.

Where it happens: Utilities\Tweaks\ConfidentialityTweaks.cs, Utilities\Managers\FirewallManager.cs, and Resources\Blocklist.txt.

Likely purpose: Reduce Windows/Microsoft/advertising telemetry and prevent selected endpoints from resolving or connecting.

Why it is suspicious: Hosts/firewall modification is powerful. In malicious software, it can block security updates or redirect traffic. In the reviewed GTweak behavior, the observed entries are blocklist-style 0.0.0.0 mappings, not credential-stealing redirects.

Local evidence: This was definitely applied on the live system: the hosts file had 1396 blocking entries and a GTweak backup file existed.

7. App Removal and WindowsApps Deletion

Trigger: User-triggered through the Applications page by clicking app icons/actions. The UI warns that selected apps may be deleted permanently.

What it can do: Remove bundled/provisioned apps such as OneDrive, Edge, Widgets, Teams, Copilot, Cortana, Xbox apps, and similar packages.

How it does it:

• Uses PowerShell Get-AppxPackage -AllUsers | Remove-AppxPackage.
• Uses Remove-AppxProvisionedPackage.
• Takes ownership of matching C:\Program Files\WindowsApps directories.
• Deletes app directories and related registry keys.
• For Edge/WebView, kills Edge-related processes, invokes setup uninstall flags, removes update services/tasks, and deletes Edge/WebView directories and registry keys if selected.

Where it happens: Utilities\Tweaks\UninstallingPakages.cs.

Likely purpose: Remove Microsoft-bundled applications and provisioning so they do not return for all users.

Why it is suspicious: Removing provisioned apps can break WebView-dependent apps, widgets, Store components, sign-in flows, or update paths. It is invasive but consistent with debloating.

8. Addons Script Runner

Trigger: User-triggered only after selecting a folder and running a listed script. The Addons UI requires folder selection and exposes a "Run as TrustedInstaller" checkbox.

What it can do: Run .ps1, .bat, .cmd, and .reg files from a selected folder, optionally as TrustedInstaller.

How it does it:

• Scans the selected folder for supported script/registry file extensions.
• Runs .reg through reg.exe import.
• Runs .ps1 through PowerShell with -ExecutionPolicy Bypass.
• Runs .bat/.cmd through cmd.
• Uses TrustedInstaller execution if the checkbox is selected.

Where it happens: Core\ViewModel\AddonsViewModel.cs and View\AddonsView.xaml.

Likely purpose: Advanced custom tweak support.

Why it is suspicious: This is an execution surface, not a hidden backdoor. The risk comes from scripts placed in the folder. Running an untrusted addon here is equivalent to giving that script administrator or TrustedInstaller-level control.

8a. Low-Level Keyboard Hook in Overlay Window

Trigger: User-triggered operations that display OverlayWindow, such as activation/restore/long-running workflows.

What it can do: Install a low-level keyboard hook while the overlay is displayed.

How it does it: DisablingWinKeys.cs calls SetWindowsHookEx(13, ...) and checks keys such as left/right Windows key, Alt+Tab, Ctrl+Esc, and Alt+Esc. It returns 1 for those combinations, blocking them.

Where it happens: Windows\OverlayWindow.xaml.cs and Utilities\Helpers\DisablingWinKeys.cs.

Likely purpose: Prevent users from switching away while a blocking overlay is active.

Why it is suspicious: Keyboard hooks are sensitive APIs and often appear in keyloggers. In this implementation, I did not find code that records or exfiltrates keystrokes; it appears to suppress specific system key combinations. It should still be documented because security scanners reasonably flag low-level keyboard hooks.

9. Windows Activation Module

Trigger: User-triggered from the Utilities page's "Activate" button.

What it can do: Attempt Windows activation through HWID-like and KMS mechanisms.

How it does it:

• Installs product keys via slmgr.vbs /ipk.
• Clears ClipSVC ticket files.
• Writes GenuineTicket XML from embedded resources.
• Runs clipup -v -o.
• Falls back to KMS by setting kms.digiboy.ir and running activation.

Where it happens: Utilities\Maintenance\WinLicenseHandler.cs and Resources\Tickets.xml.

Likely purpose: Activate Windows without relying on the normal retail/Microsoft activation flow.

Why it is suspicious: This is legally and operationally risky. It contacts a third-party KMS host and manipulates licensing artifacts. It is not necessary for privacy, debloating, telemetry reduction, or app removal.

10. Restore Point, Registry Backup, Cleanup, and NTFS Compression Utilities

Trigger: User-triggered from the Utilities page buttons.

What it can do: Create/recover restore points, enable/disable System Restore, clear caches/temp data, enable/disable NTFS compression, and create registry backups.

How it does it: Uses maintenance classes such as SystemRestoreService, RegistryExporter, ClearingMemory, and NTFSCompressor, plus registry/service/command execution where needed.

Where it happens: Utilities\Maintenance\* classes and the Utilities page.

Likely purpose: Maintenance and rollback support before making system modifications.

Why it is suspicious: Some cleanup actions delete files and some restore/status controls can remove restore point protection if misused. The UI presents these as explicit actions.

11. Self-Removal

Trigger: User-triggered from settings/self-delete UI.

What it can do: Remove GTweak registry settings and delete its own executable.

How it does it:

• Deletes HKCU\Software\GTweak.
• Deletes GTweak tracing keys.
• Runs a delayed command that kills the process, deletes the executable, removes C:\ProgramData\GTweak, and removes a systemprofile GTweak folder.

Where it happens: Utilities\Controls\SettingsEngine.cs and Windows\MainWindow.xaml.cs.

Likely purpose: Provide a "delete this app" button.

Why it is suspicious: Self-deletion is often suspicious in malware. Here it is exposed as an application setting/action. It does not by itself prove stealth or malicious intent.

Behaviors Not Found in Reviewed Evidence

I did not find clear evidence of:

• Browser password, cookie, or profile theft.
• Crypto wallet theft.
• Keylogging.
• Screen capture, webcam capture, or microphone capture for exfiltration.
• Remote command-and-control loop.
• Hidden autorun persistence for GTweak itself.
• Automatic upload of documents, images, or other personal files.
• Obfuscated exfiltration endpoints.
• GTweak keeping active outbound connections during the live check.
• Code that enumerates browser profiles, password stores, wallet folders, or document folders for upload.
• Code that sends arbitrary local files to a remote server.

This does not prove absolute safety. It does lower the likelihood that the reviewed source is a conventional spyware/backdoor project.

Intent and Risk Interpretation

Many GTweak behaviors are consistent with a privacy/control goal:

• Blocking telemetry domains limits some Windows/Microsoft/advertising endpoints.
• Disabling scheduled telemetry tasks reduces background data collection.
• Removing provisioned apps prevents bundled apps from returning for new users.
• Disabling suggestions, ads, Copilot/Recall-related settings, and UI nags reduces unwanted Windows behavior.
• TrustedInstaller execution is used because normal Administrator privileges are often insufficient for protected Windows resources.

At the same time, intent and risk are separate. A privacy-motivated tool can still be risky. GTweak's high-risk behaviors are not subtle: the code openly provides controls that override Windows protection boundaries.

Risk Rating

Category	Rating	Reason
Spyware/backdoor evidence	Low	No direct evidence of stealer/backdoor behavior found in reviewed source, UI structure, or live network/persistence checks. Residual uncertainty remains because full dynamic malware-lab tracing was not performed.
Automatic security tampering	Medium	Startup Defender exclusion attempt and TrustedInstaller service start are automatic. Most other security changes are user-triggered or import-profile-triggered.
Local system integrity risk	High	TrustedInstaller execution, embedded helper executables, service changes, protected file ownership changes, Defender/UAC/Update controls, Winlogon Shell/Safe Mode changes, and WindowsApps deletion can materially alter Windows.
Privacy/control benefit	Medium to High	Hosts blocking, telemetry task disabling, app removal, ad/suggestion suppression, and UI/system toggles are real control mechanisms.
Misconfiguration/breakage risk	High	Can break Defender, Windows Update, Edge/WebView, Store apps, restore points, services, and app dependencies if used aggressively.
Legal/licensing risk	High	HWID/KMS activation logic and third-party KMS host are outside normal licensing flow.
Supply-chain trust risk	Medium	Open source and GitHub build workflow help, but the public executable is unsigned and not proven reproducible from source.

Trustworthiness Improvement Recommendations

These recommendations focus only on high-risk areas. They are not meant to remove GTweak's privacy/debloating purpose.

1. Remove Windows activation from the core app.

   The activation module should not ship inside the main privacy/debloating tool. If the author wants to keep it, it should be a separate optional plugin/addon outside the default release, with clear legal warnings and no automatic path from the core UI. The main app would become more trustworthy immediately if WinLicenseHandler, embedded Tickets.xml, HWID/KMS keys, and kms.digiboy.ir behavior were removed from the default build.

2. Stop adding Defender exclusions automatically on startup.

   If Defender exclusions are needed, the app should ask explicitly with a dedicated prompt explaining the exact path/process being excluded and why. A privacy tool can justify this, but doing it automatically is one of the strongest reasons security tools and users will distrust it.

3. Separate the Defender-disabling engine from normal tweaks.

   Defender/SmartScreen/VBS/Tamper Protection disablement should be an advanced module behind a separate download or explicit advanced-mode unlock. It should show a dry-run list of exact registry keys, services, files, tasks, exclusions, Safe Mode changes, and reboot actions before execution.

4. Avoid Winlogon Shell modification where possible.

   The Winlogon\Shell plus Safe Mode helper flow is powerful but very sensitive. If it must remain, the app should include a verified recovery path, action log, restore manifest, and explicit confirmation. A more trustworthy design would avoid modifying Winlogon\Shell unless there is no alternative.

5. Remove or fully verify embedded helper executables.

   Embedded NSudoLC and DisablingWD binaries should either be removed from the core app or documented with source links, version numbers, SHA256 hashes, build provenance, and signatures. Users should not have to trust opaque compressed executables inside a system-tweaking app.

6. Use signed releases and reproducible build evidence.

   The project should publish SHA256 hashes, build artifacts from GitHub Actions, release provenance, and ideally Authenticode signatures. For a tool that requests administrator rights, unsigned releases are a major trust weakness even if the source is benign.

7. Harden self-update.

   Self-update should verify a signed manifest or signed binary before replacing the current executable. Downloading a new executable and swapping it into place is acceptable only if authenticity is cryptographically checked.

8. Restrict high-risk import profile behavior.

   Import profiles should not silently apply Defender, UAC, Windows Update, Winlogon, activation, or TrustedInstaller-backed actions without a separate confirmation screen. A dry-run preview should mark high-risk actions clearly.

9. Make Addons safer by default.

   Addons are useful, but "Run as TrustedInstaller" should be off by default, require explicit per-script confirmation, and display the exact command line before execution. This keeps advanced power without making arbitrary privileged execution feel casual.

10. Add a machine-readable action log and rollback manifest.

Every high-risk action should write what changed, where it changed, previous values, and how to restore them. This would make the app easier to audit and safer to recover from.

These changes would not remove the useful privacy/debloating parts of GTweak. Hosts blocking, telemetry toggles, ad/suggestion removal, UI tweaks, selected app removal, and service controls can remain valuable if they are transparent, reversible, and clearly user-triggered. The main trust problem is the small set of high-risk features that cross security, boot, licensing, and arbitrary-execution boundaries.

Practical Recommendations

For the current machine:

1. Treat GTweak as a high-privilege system modification tool, not as a normal utility.
2. Keep Defender, UAC, Firewall, and Windows Update heavy-disable controls unchanged unless you knowingly accept the security tradeoff.
3. The hosts blocklist appears applied. It is reversible because a GTweak hosts backup exists.
4. Avoid the Windows activation module. It is unrelated to privacy/debloating and carries the highest legal/trust risk.
5. Avoid Addons/TrustedInstaller script execution unless every script is personally reviewed.
6. Use the app selectively for lower-risk goals: ads/suggestions disabling, telemetry task reduction, selected bundled app removal, and hosts/domain blocking.
7. Before applying Defender/Update/UAC/service changes, create a restore point or full disk image.
8. If stronger assurance is needed, build GTweak from source in a clean environment and compare behavior against the release binary. Because the release executable is unsigned, the GitHub download alone does not provide strong publisher authenticity.

Bottom Line

GTweak does not look like a conventional personal-data stealing malware project from the reviewed source, UI structure, and live-system evidence. The "dirty" or suspicious part is not observed spying; it is the intentional ability to bypass Windows protection boundaries and modify security, update, service, app, and licensing behavior.

The app is reasonable only under a narrow trust model: you trust the author, you trust the exact release binary, and you intentionally want a tool that can override Microsoft-controlled defaults. If that is the goal, the code and UI largely match that purpose. If the goal is low-risk debloating with minimal chance of weakening the security posture, GTweak is too powerful to use casually.

[Greedeks]

😕

[wannabexaker]

I want to be clear: I respect this project. GTweak is powerful, useful, and clearly took a lot of work. My goal is not to attack the author or the app. This is an AI-assisted, neutral trust/security review meant to document high-risk areas and suggest ways to improve user confidence.
Much respect to the author. I hope this is useful feedback.

[Greedeks]

@wannabexaker Maybe there was a bit of a misunderstanding on both sides.
I actually found it quite interesting, though I have to admit, seeing that massive email notification was a bit overwhelming at first.