Blindagem Windows: from script to C# application

The challenge

A script-based technical workflow needed to become an application with structured installation, visible state and maintenance.

An administrative routine may begin as a sequence of commands, but an application requires further decisions. Users need to understand the current state, select an action, follow messages and know how to install or update the program. These stages belong to the product architecture.

Blindagem Windows demonstrates this evolution in an internal project that remains in development. Version 1.5.0 brings together a Windows Forms interface, restriction components, licensing, terms, reports and an update client. This case explains the implemented work and the stages that still require validation.

How the workflow works

1. 01

   Organize the components

   The interface, restriction rules and update client have separate responsibilities. The screen presents the state of mechanisms such as WSH, WMIC, BAT/CMD, MSI, PowerShell and SCR, including an indication of partial status.

2. 02

   Prepare installation

   The installer organizes application files, creates shortcuts and registers an uninstaller. User logs and preferences are separated from machine-wide data, instead of treating every piece of information as part of the executable.

3. 03

   Check for updates

   The prepared framework checks versions on launch and every six hours while the application remains open. Users can check manually and choose when to install; there is no permanent monitoring while the program is closed.

4. 04

   Verify the download

   The workflow validates the manifest, requires HTTPS and keeps the installer on the expected domain. It checks the file's SHA-256 before installation. Publishing the update channel and completing runtime tests remain separate stages.

The work

A C# Windows Forms application with an installer, organized application data and an update framework with integrity checks.

• Desktop interface and installer
• Organized logs and preferences
• Update framework with SHA-256 checks

Installation is part of development

An executable alone does not address file locations, shortcuts, permissions, preferences or maintenance. This project's packaging handles those needs and prepares a foundation for subsequent releases.

Data organization distinguishes program files, user reports and machine information. That helps define what an update may replace and what must remain available across versions.

Checks with explicit limits

The history records 17 acceptance checks, including version comparison, rejection of invalid manifests and integrity verification. Those checks did not apply restrictions to the computer or validate the entire administrative installation.

Product validation must include installation, updating, removal and actual behavior in an appropriate environment. The current restoration writes Windows defaults; it does not yet capture all pre-existing settings faithfully.

Example of an integrity check

Adapted example explaining SHA-256. It installs nothing, applies no restrictions and does not replace code signing.

static bool MatchesHash(string path, string expected)
{
    using (var sha = SHA256.Create())
    using (var input = File.OpenRead(path))
    {
        var actual = BitConverter.ToString(
            sha.ComputeHash(input)).Replace("-", "");
        return string.Equals(actual, expected,
            StringComparison.OrdinalIgnoreCase);
    }
}

Delivery and context

Version 1.5.0 and its installer are prepared. Full installation, real restriction application and update distribution remain under validation.

Frequently asked questions