Desktop applications have a structural disadvantage that web applications don’t: they run on machines you don’t control. Everything the application “knows” in order to function — credentials, connection strings, keys, the logic it hides — is right there on the endpoint, within reach of anyone who has a copy of it. The difference between a minor issue and a serious one often comes down to architecture: a two-tier application that talks directly to the database carries database credentials and logic on the client — and from there an attacker can reach the data directly via SQL injection.
What we test
- Storage and secrets at rest — configuration files, registry, SQLite databases, memory, temporary files: credentials, connection strings, API keys, tokens
- Binary and DLL — decompilation and reverse engineering (.NET and native); hardening checks (ASLR, DEP, Authenticode signing); DLL hijacking and search-order abuse, identified through “NAME NOT FOUND” analysis
- Traffic — HTTP/S and non-HTTP interception (proprietary binary protocols), TLS validation and certificate pinning bypass
- Runtime manipulation — function hooking with Frida, to bypass client-side controls: licensing, role checks, disabled buttons, business logic dangerously kept in the application
- Backend injection — SQL injection (especially on 2-tier applications), command injection, insecure deserialisation, server-side authorisation checks
- Local privilege escalation — insecure file and registry permissions, services running as SYSTEM, unquoted service paths, installation directories with write access
What you get
- Findings mapped to CWE, each with evidence (intercepted requests, modified binaries, extracted secrets)
- An architecture risk note (2-tier vs 3-tier) and its implications
- Concrete remediation: move trust and secrets to the server, apply TLS and pinning correctly, harden the binary, fix ACLs and service paths