Windows Application - Technical Deep Dive

A comprehensive overview of the Guard Windows application's architecture, features, and security measures, designed to provide robust and reliable internet access control.

1. Description

Guard is a Windows application that provides centralized control over internet access for any assigned device, managed securely through your online account at Guard.AlexWeb.app. Its core functionality is the ability to receive and apply instructions from your account, which define:

Rules: Flexible filters that can restrict access to specific websites or online resources according to a schedule you set (for example, only allowing access during homework hours).

Categories: Predefined groups—such as gambling, adult content, or social media—which are blocked at all times when selected.

Once a device is assigned, Guard keeps all settings automatically synchronized with your account. The application enforces restrictions by managing the system hosts file and Windows firewall rules, ensuring that the selected resources are inaccessible as specified by your instructions.

Guard protects access to its admin panel, closing, and uninstallation with a PIN code. Its state is securely encrypted, and all configuration data received from HTTP requests is thoroughly sanitized. The application is resistant to tampering: it monitors and automatically restarts itself if terminated, prevents operation without the necessary system privileges, and periodically verifies the device's clock using public time services to ensure accurate rule enforcement. These safeguards ensure that Guard's restrictions remain active and reliable, providing robust control.

2. Description of Data Variables and Objects in REST HTTP Requests

Assigning Code: 12-digit string – unique code used to identify the device in most cases.

DeviceId: Unique device ID, used for similar purposes in some cases (e.g., saving logs).

PinCode: 6-digit PIN code set by the user in their account at Guard.AlexWeb.app.

PinStatus: Integer – auto-incremented when the PIN code changes to avoid sending the PIN itself in each request.

SyncStatus: Boolean – indicates whether instructions are active for the device.

LastUpdate: String (JS date format) – records the last update with the server to efficiently check for changes.

Rules: Objects containing rule type (Preset or Custom URL) and an encoded week schedule for each rule.

Restricted Categories: Array of category IDs selected as restricted.

Presets: Objects with a preset name (e.g., Youtube, Roblox), URLs (encoded string), and IPs if available. Stored and updated server-side.

Categories: Objects with a category name (e.g., Gambling, Adult Content), included preset names, URLs, and IPs if available. Stored and updated server-side.

Instructions: Encoded string with current Rules and Restricted Categories.

Version: Version of instructions, used to minimize DB requests; updated whenever rules or restricted categories are changed.

ResetConnection: Boolean indicating whether to reset the network connection after applying changes (needed for some browsers).

Sound: Integer 0–100; planned for future notification volume settings.

Illustration for 2. Description of Data Variables and Objects in REST HTTP Requests

3. REST HTTPS Request Logic for Syncing Device State

After installation, the app starts with a clean state. All data received during HTTPS requests is sanitized to remove restricted characters.

1) Assigning Request: User assigns the device to their online account at Guard.AlexWeb.app using a unique 12-digit Assigning Code and 6-digit PIN Code (default: "123456"). This is sent via a REST HTTPS request to a secured API endpoint. In response, the device receives: DeviceId, Version. This information is saved to state after assignment.

2) Instruction Polling: After assignment and every 5 minutes (or manually via the tray menu), the app sends: deviceUid (Assigning Code), lastUpdate (initially empty), version, pinStatus. Server response may include: Presets (sent if first request or if changed), Categories (sent if first request or if changed), Version (sent if first request or version updated on server), Instructions (sent if first request or version updated), lastUpdate (sent if any changes need to be applied on the device).

3) Logging Requests: Logs are sent to HTTPS endpoints with deviceId and message (e.g., PIN entered, too many failed PIN attempts, startup info).

4) Time Sync Requests: The app queries public APIs for the real current time to prevent rule bypass via system clock changes.

Time APIs used:

• https://timeapi.io/api/Time/current/zone?timeZone=UTC • https://worldtimeapi.org/api/timezone/Etc/UTC • https://aisenseapi.com/services/v1/datetime

Illustration for 3. REST HTTPS Request Logic for Syncing Device State

4. High-Level Goals

• Receive and apply instructions from the online account at Guard.AlexWeb.app, modifying the system hosts file and Windows Firewall rules according to instructions and rule schedules.

• Secure access to the admin panel with a PIN code.

• Allow removal of all changes after PIN-protected uninstallation.

• Sanitize all REST HTTPS requests.

• Main process watches for the helper watchdog and vice versa, preventing functional loss if either is terminated.

• Protect against duplicate logic by guarding the main loop with app state.

• Periodically check real time with public APIs.

• Save and self-heal app state in three locations.

• Allow full cleanup on uninstall with correct PIN.

5. Final Architecture

The application suite is architected as four distinct components for security, resilience, and maintainability:

Guard.exe (Main Application): The user-facing app that runs in the system tray, provides the admin/diagnostic UI, and acts as the primary watchdog for the helper process.

StartHelperG.exe (Watchdog Helper): Lightweight console app to monitor Guard.exe. Relaunches the main app if terminated and can trigger cleanup if the main app fails.

Guard.Cleaner.exe (Secure Uninstaller): Standalone, PIN-protected utility for full-system cleanup. Runs on uninstall or after repeated startup failures.

Guard.Core.dll (Shared Library): Central library containing shared logic, data models (GuardState), and system interaction code (SystemCleaner, ScheduledTaskHelper, InputSanitizer) for consistent behavior across all executables.

6. Key Technical Features & Solutions Implemented

Resilience & Stability

Mutual Watchdog: Two-process system (guard.exe and StartHelperG.exe) monitor each other. This avoids Session 0 Isolation issues present with Windows Services.

Optimized Instruction Updates: Instruction updates are driven by the LastUpdate variable to efficiently manage multiple assigned devices and reduce unnecessary operations.

Single-Instance Guarantee: System-wide named Mutex in both executables prevents multiple instances, eliminating recursive launches ("fork bomb").

State Redundancy & Self-Healing: GuardState is encrypted with the Windows Data Protection API and saved to three locations (%AppData%, Documents, and a system folder). Periodic self-healing restores missing state files.

API request minimization: Default polling every 5 minutes; manual updates available as needed.

Time integrity: Rules are protected against incorrect system time via regular checks with public APIs.

Unified loop: Data fetching, rule preparation, and system application run in a protected, non-duplicating main loop.

System Integration & Startup

Elevated Startup via Scheduled Task: Uses a self-managed scheduled task for automatic, privileged startup on user logon—no UAC prompt required.

Manifest Elevation: All executables embed a manifest to request administrator rights when run manually.

Security

API Input Sanitization: The InputSanitizer class validates all API data, preventing command injection and unsafe domains, IPs, or CIDR ranges.

Secure Uninstall: Guard.Cleaner.exe must be run with the correct PIN to call shared cleanup routines for the hosts file, firewall, and scheduled tasks.

Professional Deployment

Inno Setup Packaging: Single professional installer with required admin rights, includes all project files and dependencies, sets up shortcuts, triggers Guard.Cleaner.exe on uninstall, and offers "Launch Application" at finish.

Illustration for 6. Key Technical Features & Solutions Implemented

7. Alternative Architectures Considered & Rejected

Windows Service Watchdog: Fully implemented and abandoned due to Session 0 Isolation (cannot launch interactive GUI apps with tray icon from service).

Installer: Migrated from Visual Studio Installer Projects extension to Inno Setup due to repeated build/configuration failures and reliability issues with multi-project packaging.

Illustration for 7. Alternative Architectures Considered & Rejected