Devil-Guard is a connected protection, identity, evidence and server-enforcement platform for participating Delta Force: Black Hawk Down communities. It combines the Devil-Guard website, the Devil-Guard Server service installed beside the game server, and the Devil-Guard PC Sentinel installed on participating player computers. Each component has a separate job, and the three components exchange signed or authenticated information so that protection decisions are based on current evidence rather than assumptions.
This page explains what each component does, how information moves between them, what happens when a player joins a protected server, how detections such as DLL injection or runtime hooks are reported, how Windows GDID and game-server IP history are correlated, how optional VPN/proxy policy works, and how the current privacy, registration, council-retention and ban-history controls fit into the platform.
Authenticates users and components, issues personal PC tokens and server tokens, validates signed attestations, stores protection and evidence records while required, evaluates connected players, manages aliases and appeals, records network identity history, coordinates council outcomes, minimises completed case data, keeps compact ban history, and sends enforcement commands to protected servers.
Reads the real HawkSync player list, uses the game-server-observed IP as the authoritative game address, asks the website for current decisions, sends warnings, maintains Devil-Guard-owned HawkSync bans, kicks live players when required, and creates narrowly scoped paired Windows Firewall rules.
Runs the Sentinel Windows service, watches the configured DFBHD process, checks executable and monitored-file integrity, reviews selected runtime hooks and loaded modules, reads the local Windows identity used by Devil-Guard, and submits challenge-bound signed protection reports to the website.
Registered users sign in to the website and use role-based areas such as the Client Portal, server-host tools, Council review and administration. A permitted client user can issue a personal Devil-Guard PC token. The PC client uses that token over HTTPS when sending presence heartbeats, requesting one-time attestation challenges and submitting signed protection reports.
The website keeps the registered DFBHD player name and approved aliases so a live HawkSync name can be associated with the correct account without assuming every display-name change represents a different person. Alias information is part of identity correlation, but a name match by itself is not treated as cryptographic device proof.
Normal PC heartbeats tell the website that the Sentinel service is alive, whether the configured game process is running, the configured player name, session information and the signed-device identifiers available to the client. Heartbeats are separate from detailed evidence reports.
Before a detailed attestation is accepted, the website issues a fresh random challenge tied to the authenticated client and machine. The PC refuses to sign and submit detailed evidence if it cannot obtain a valid fresh challenge.
The website checks the report structure, canonical package hash, registered device key, one-time challenge and ECDSA signature before treating the evidence as verified. Challenge validity and signature validity are tracked separately so administrators can see why a report was or was not accepted.
Accepted reports update the current attestation record and can create evidence/detection events containing the trusted detection state, approved executable status, signal summary and permitted evidence metadata. Detailed case-linked evidence is retained for the operational/review purpose and can be minimised after the final council outcome instead of being treated as permanent history.
When Devil-Guard Server submits a live player snapshot, the website compares the HawkSync-observed player with current PC protection, recognised names/aliases, grace periods, whitelists, network policy and existing enforcement cases. The Server then receives the action appropriate to that current state.
Kick, managed-ban and Windows Firewall outcomes are reported back to the website. Completed results are acknowledged and added to the enforcement/audit state so operators can distinguish a requested action from an action that actually completed on the game server.
Players can manage their account, personal client token, protected identity, aliases, current protection state, relevant server sessions, restrictions and eligible appeal options without being given administrator-only data.
Authorised administrators can review verified Windows GDID identity, linked machine identity, game-server-observed IP history, network classification, first/last seen information and connection history where the required verified correlation exists.
Evidence views distinguish verified reports from challenge or signature failures and expose the information required for an administrator or Council reviewer to understand a protection decision without treating unverified input as trusted evidence.
Eligible restrictions can move through structured appeal and Council workflows. When the final vote is reached, the website first writes a compact ban-history record and then minimises detailed case-linked evidence, appeal correspondence, free-form vote comments and redundant session/device material. An upheld ban remains enforceable; an overturned ban is removed or queued for removal.
New client registrations require separate acknowledgement of the Terms of Service, Privacy/Retention information and PC Monitoring/Automated Enforcement information. The accepted policy versions are recorded so the website can show which disclosures applied when the account was created.
Visitors are shown a privacy and data notice. Essential session/security storage remains available for site operation, while optional third-party media stays blocked unless the visitor chooses to allow it. The choice can be changed later from Privacy settings in the footer.
The website is designed to separate raw input, verified evidence, policy and final action. A player name, an IP address or an unverified client field is not by itself equivalent to a trusted signed device identity.
DevilGuardServer runs independently of the browser dashboard. The normal operating cycle polls configured game-server profiles, reads the current server-manager snapshot and communicates with the Devil-Guard website. The default poll interval is ten seconds, and overlapping enforcement passes are prevented.
The local dashboard shows service health, configured instances, HawkSync connectivity, live player state, managed firewall inventory, player/GDID/IP history where verified, network-intelligence status and recent integration errors. Dashboard access is authenticated and can be kept local-only or restricted for remote administration.
The Server requests the live HawkSync player snapshot. The live slot, player name, public game IP and active DFBHD UDP port come from the server side and are therefore independent of the IP the player may use for normal website HTTPS traffic.
The IP HawkSync sees for the DFBHD connection is treated as the authoritative game address. This matters with split-tunnel VPN configurations where the player’s browser/PC-client HTTPS traffic may use one route while DFBHD uses another.
The current live player list is sent to the authenticated enforcement endpoint. The website returns protection status, client-required/grace information, recognised identity context and any current enforcement instruction.
For missing or stale client protection, compatible HawkSync builds can deliver staged private messages explaining that Devil-Guard PC is required and how much grace remains. A valid signed PC report received during the grace period can cancel pending client-missing enforcement.
Pending block/unblock commands are processed as actions, not rebuilt continuously on every poll. Existing correct managed rules are left in place. The Server reports exactly what succeeded or failed so the website can display a meaningful state.
Completed action results are saved locally before the website acknowledgement arrives. If the portal is temporarily unavailable, the completed result can be retried later instead of blindly repeating the kick, ban or firewall operation.
Managed blocks use both inbound and outbound rules for the same player IP, DFBHD UDP port, selected game executable and configured network interface. Devil-Guard does not need to block every port on the machine.
On an approved unblock, the Server removes only the HawkSync name/IP records and Windows Firewall rules that Devil-Guard owns. Unrelated bans created by another administrator are not intended to be removed.
If the player disappears before the command is processed, an immediate kick is no longer required, but the durable managed ban/firewall state can still be applied when policy requires it.
The Server retains already-applied restrictions and pending action results through temporary portal failures. It should not fabricate a new missing-client or VPN decision when the authoritative website decision cannot be obtained.
The Server and website can use cached IP intelligence and the configured vpnapi.io integration to classify the actual game-server-observed IP as clean/direct, VPN, proxy, Tor or private relay, with available network/country/ASN context.
A classified VPN does not automatically mean “ban” unless the server’s VPN-blocking policy is enabled. VPN, proxy, Tor and relay blocking are separate policy choices. Classification can therefore be stored/displayed without forcing a kick.
If the external network-intelligence provider cannot return a trustworthy result, Devil-Guard does not invent a VPN/proxy classification merely to create a block. Existing independently justified restrictions remain separate.
When the website confirms a verified signed Windows GDID match for a live player, Devil-Guard Server can retain that identity/network association in its local SQLite history. Records can include the Windows GDID, Devil-Guard machine ID, authoritative game IP, network classification, first/last seen timestamps, connection count and protected server/profile identity. Sensitive identifiers are protected at rest by the Server’s local data-protection layer.
Repeated ten-second enforcement polls are not intended to inflate connection totals. A new live connection, reconnect or changed observed IP creates the meaningful history event. If verified PC identity becomes available shortly after the join, the correlation can be captured when that verified identity arrives.
The separate Server page focuses on installation behaviour, HawkSync integration, firewall scope and the local dashboard.
Closing the normal status/setup window does not by itself stop protection. Sentinel runs as a Windows service, starts its monitoring cycle independently and keeps reporting while the configured DFBHD process is active and the website/token configuration remains valid.
Sentinel is concerned with the approved local DFBHD executable and its runtime state, not only with one particular Devil-Guard game server. That means local integrity and injection/hook/module monitoring continues while the recognised DFBHD process is running even if the player joins another community’s server.
The configured game process is reviewed on a roughly twenty-second monitoring cycle after startup. Overlapping passes are skipped instead of building a queue of scans when a prior pass is still finishing.
The approved game executable receives periodic SHA-256 revalidation, while obvious file-size or timestamp changes can trigger earlier work. The approved hash state becomes part of the signed attestation.
Top-level EXE, DLL and ASI files in the configured game directory are tracked for additions, removals and changes. The baseline is periodically revalidated so a change is not accepted merely because it remained present for several monitoring passes.
Loaded-module topology and suspicious-module evidence are cached and refreshed when the module set changes or the refresh interval is reached, reducing repeated hashing/signature work while still preserving detection context.
Selected virtualisation, Docker and related environment indicators are checked on a slower interval because they do not need to be enumerated on every runtime pass.
While reporting is configured, the PC sends a lightweight heartbeat that lets the website know the Sentinel/device session is present and whether DFBHD is currently running. This heartbeat is distinct from the detailed signed evidence report.
The configured game executable can be compared against the approved SHA-256 set. A mismatch becomes a protection signal and is included in the signed report rather than silently treating the executable as trusted.
Sentinel checks selected runtime function state used by DFBHD. Unexpected runtime changes can set the hook-detected state. This is one of the mechanisms used to identify behaviour consistent with DLL injection or runtime hooking without exposing low-level bypass details on the public website.
Loaded modules can be reviewed for unexpected origin and supporting file/signature/hash information. Suspicious module state is included in the signed evidence package when present.
New, removed or modified monitored EXE, DLL and ASI files can produce a directory-integrity signal. This provides evidence when the local DFBHD installation changes after the approved baseline was established.
Sentinel reads the Windows GDID available to the service and includes it alongside the Devil-Guard machine identity in signed reporting. The GDID is useful for grouping the same verified Windows identity across observed game IP changes, but Devil-Guard does not pretend an IP address can reveal a GDID when the PC client is absent.
Each PC maintains its own device signing identity. The website registers and verifies the public side of that identity; the private key remains on the Windows computer and is protected using Windows machine-level data protection. Signed reports therefore carry stronger provenance than a plain machine-ID/GDID string sent without a valid device signature.
If Devil-Guard PC is installed, Sentinel is running, the recognised configured DFBHD process is active and the personal token can reach the Devil-Guard website, the normal monitoring and attestation cycle continues even when the player is connected to a server that does not run Devil-Guard Server.
The changed protection state causes the next signed-attestation cycle to include that detection. The PC must first obtain a valid one-time challenge; if challenge retrieval fails, the client deliberately does not submit unsigned or challenge-less evidence.
After validation, the website stores the attestation/detection state and its evidence context. The detection is therefore not dependent on the other game server running Devil-Guard Server.
Devil-Guard cannot kick, blacklist or create a firewall rule on a third-party server it does not administer. The website can retain the protection detection for later review, but enforcement on a game server requires that server to be participating and running the Devil-Guard Server integration.
Normal signed reports can include the device/machine identity, Windows GDID, configured player/game information, approved executable state, detection flags, signal summary, monitored-file information, selected module information, client/session timestamps and the one-time challenge/signature package needed for verification.
When the relevant setup options and policy allow it, a detection can also collect selected items such as a DFBHD window screenshot, a process minidump, an unapproved executable copy, selected Windows event information or a running-process list. These are intended for confirmed detection review and are not required for the basic runtime/file/module detection flags to work.
The separate PC page focuses on player installation, monitoring cadence, client-required behaviour and privacy/evidence choices.
The PC’s HTTPS source IP is not substituted for the DFBHD game IP. A player can legitimately have one web route and another game route, especially when a VPN is split by application.
A verified GDID can accumulate multiple observed game IPs over time. A later VPN address does not erase the earlier clean or VPN address; it becomes additional history for that identity.
Normal recurring PC heartbeats and recurring Server polls are not intended to masquerade as new joins. Connection totals are driven by actual live connection/reconnection observations.
If the PC client is not present or the signed identity cannot be verified, the game-server name/IP can still exist as an observed connection or enforcement case, but it should not be labelled as a verified Windows GDID.
Sentinel is running and reporting, the player joins a protected server, HawkSync sees the live name/IP, the website finds recent verified signed PC evidence and the correct registered name/alias, and the Server receives an allow/compliant result. The live game IP can be associated with the verified GDID and no enforcement is required.
HawkSync sees the player but the website cannot find current acceptable Devil-Guard PC protection. The player can enter a configured grace period and receive an in-game notice. If valid protection returns, pending enforcement can be cancelled; otherwise the participating Server can kick and apply the configured temporary/persistent restriction.
The Server uses HawkSync’s actual game IP, classifies that address when network intelligence is enabled and sends the result to the website. If VPN blocking is enabled, the Server can apply its managed ban, kick and paired firewall block. If VPN blocking is disabled, the classification may still be recorded/displayed without enforcing merely because the address is a VPN.
The local Sentinel monitoring continues because DFBHD is running. A changed hook/module/integrity state is placed into a fresh signed attestation and submitted to the website. The website can retain the verified detection even though the current third-party game server cannot be controlled by Devil-Guard Server.
Devil-Guard PC is not a VPN or DFBHD traffic relay. Game packets still travel between the player and the actual game server. This is why the game server’s HawkSync-observed IP is authoritative for server enforcement.
Devil-Guard Server does not have a mechanism to infer a Windows GDID from an IP address. The GDID must come from the local PC client and be accepted as part of the signed device identity.
Personal client tokens, server enforcer tokens, passwords, protected machine identifiers, raw filesystem paths and player IP addresses are not intended to be exposed on normal public status pages.
Current website and Server builds protect supported sensitive identity/network values at rest. The website relies on its configured data-encryption key, while the Server uses its local Windows data-protection/encryption layer for local history and configuration material.
Core detection flags do not require every enhanced capture option. Screenshots, dumps, copied executables, event details or process-list evidence are controlled separately. When detailed case evidence has served the council-review purpose, the current retention workflow can remove those attachments and records rather than keeping them as the permanent ban history.
A field claiming to be a GDID, machine ID or detection state is not enough by itself. Device-key registration, challenge validation and signature verification exist so the website can distinguish trusted signed evidence from unverified claims.
Server actions are recorded with case identity, reasons and results. Unblocking is designed to remove only Devil-Guard-owned restrictions, pending acknowledgements are retained for retry, and final council outcomes preserve enough compact history to audit whether a restriction was upheld or overturned.
Devil-Guard provides integrity, runtime, identity and enforcement signals. No anti-cheat system can promise that every malicious technique will always be detected or that every unusual system state is malicious. Evidence review, policy and appeals therefore remain part of the platform.
The site separates essential functionality from optional third-party media. Essential browser storage supports security, login sessions and saved site preferences. Optional embedded media is blocked until the visitor chooses to allow it, and the choice can later be changed using the footer Privacy settings control.
Registration does not rely on a single hidden statement. New clients separately acknowledge the Terms of Service, the Privacy Policy/Data Retention information, and the PC Monitoring/Automated Enforcement disclosures. The site records the policy versions accepted at registration.
A player does not need a website account or Devil-Guard PC for a participating game server to observe the player name and actual DFBHD connection IP through HawkSync. The dedicated join-data notice explains that server-side processing, network classification and possible enforcement. Without a verified PC client, the Windows GDID remains unknown.
The public Automated Decisions & Enforcement page explains the categories of information that may contribute to a server decision, possible consequences such as grace/kick/managed restriction, the fact that classification and blocking are separate policy choices, and the available human appeal/Council review path.
During an eligible appeal and Council review, Devil-Guard can retain the restriction details, signed detection material, permitted evidence attachments, appeal information and review context required to decide the case.
When the Council reaches its final outcome, the website creates the durable ban-history record before deleting the detailed case package. That protects the audit trail if cleanup is interrupted and lets the website retry unfinished minimisation safely.
The purge removes case-linked evidence attachments, detailed PC attestation material, appeal correspondence/reply tokens, external evidence links, free-form council comments and redundant case-linked session/presence data that is no longer required for the finished review.
If the restriction is upheld, the active HawkSync/firewall restriction remains. Only the minimum identifiers still required for enforcement and the compact historical result are retained; the full evidence package is not used as the permanent ban record.
If the restriction is overturned, Devil-Guard removes or queues removal of its managed server restrictions. The compact history remains marked Overturned so administrators can see that the case existed and how it concluded without restoring the deleted evidence package.
The Data Rights page provides a common route for applicable Australian privacy and GDPR requests including access, correction, erasure, restriction/objection, portability where applicable, and questions about automated decisions. Deletion is assessed against information that still has a lawful operational or legal reason to remain.
Explains the categories of personal information handled by the website, PC client and participating protected servers, the purposes of processing, disclosures, security, retention and privacy contacts.
Explains account responsibilities, fair-play expectations, PC monitoring, protected-server enforcement, appeals, third-party-server boundaries and statutory rights.
Explains the essential session cookie, local preferences, optional-media choice and the absence of required advertising or behavioural-tracking cookies.
Explains what Sentinel monitors, that core detections can be submitted while DFBHD is running on another server, and how enhanced evidence remains separate.
Explains HawkSync-observed player/IP data and server-side processing for registered and unregistered players, including the boundary that an IP cannot be converted into a Windows GDID.
Explains the post-council purge, the minimum information retained for an upheld active restriction, and the compact history kept for both upheld and overturned outcomes.
Explains the inputs and consequences of automated server decisions and the human appeal/Council safeguards available for eligible restrictions.
Separate public pages explain privacy requests, complaints, security controls, incident handling, Australian NDB responsibilities where applicable and GDPR breach handling where applicable.
Use this report to inspect the VirusTotal analysis associated with the supplied Devil-Guard PC setup hash.
213bc282d073c161560f0605c84fca6275a44d20ba7015e7c3a05f186dfbb810Use this report to inspect the VirusTotal analysis associated with the supplied Devil-Guard Server setup hash.
0a9e6236b6633bfd683194cbf880f0ae401b55cb917d16e769009f0fb2003b67Devil-Guard is designed to connect local PC protection, live game-server observation and accountable website decisions without pretending that any one signal tells the entire story. The PC supplies signed local evidence, the Server supplies authoritative live game-session information, and the website records, verifies, coordinates and later minimises the result according to the published retention workflow.