Thick Client Penetration Testing

The difference is who controls the runtime. In a web test the browser stays largely out of the attacker's hands; in a thick client test the attacker owns the machine the application runs on, so everything the application trusts locally is open for examination. That shapes the work. We inspect the installed files and configuration, decompile managed .NET and Java code, hunt for hardcoded secrets and weak crypto, and review how the application stores data locally. We intercept and decode the client-to-server traffic, including proprietary and non-HTTP protocols that an ordinary web proxy never sees. We then patch the binary, manipulate memory at runtime and defeat licensing and integrity checks to prove what a determined user can change. Finally we test the backend the client depends on, because the impact that matters comes from a server trusting input from a client an attacker fully controls.

You supply the installer, working licences and test accounts, and we set up a controlled test machine at our end. The scoping call establishes which application versions, installers and backend services are in scope, and the rules of engagement are signed before any testing begins. From you we need the build we should test, credentials for each role the application distinguishes, the backend environment we are pointed at, agreed testing windows and named contacts we can reach while testing runs. A dedicated non-production backend is the usual choice, because this work involves tampering with the client and sending the server input it was never designed to receive. If only production exists, say so at scoping and we agree the limits in writing rather than discovering them mid-test. Source code is not required here; where you want the code itself examined, that is our Secure Code Review service.

Yes, defeating licensing and integrity checks is an explicit part of this engagement, and obfuscation changes the effort rather than the outcome. Client-side protections are tested on the assumption that an attacker has unlimited time with the binary on a machine they own, which is the honest assumption for desktop software. We patch the binary to alter behaviour, manipulate memory at runtime and work around the checks that decide what the application will allow. Obfuscated or natively compiled code takes longer to read than managed .NET or Java, so we raise that at scoping and price the effort rather than discover it later. What matters in the report is not that a protection was bypassed, since given the machine most are, but which of them were the only thing standing between a user and data or functionality they should not reach. That distinction decides where the server-side fix belongs.

The recurring findings cluster around trust the application places in the machine it runs on. Secrets and connection strings left in configuration files or recoverable from decompiled code. Sensitive data written to local storage, logs or temporary files without protection. Weak or absent transport security on a proprietary protocol. Authorisation decided in the client and accepted by the server on trust. Licensing or feature gates enforced only client-side. On the backend, the common pattern is a service that validates little because the client validated it already. Every issue is reproduced by hand before it is written down, and it is written down once, with proof of concept attached. Findings are graded with CVSS v4.0, and the work is measured against OWASP ASVS, PTES, NIST SP 800-115 and OSSTMM. Critical findings reach you within three hours of discovery rather than waiting for the report.

Scope decides both, and both are fixed in writing before anything starts. A thirty to forty-five minute scoping call establishes the application, the installers, the roles and the backend services involved, and you receive a written scope with a timeline and a fixed price rather than a day rate that drifts. Effort is driven by how the application is built, how many roles and workflows it distinguishes, whether the protocol is standard or proprietary, and how large the backend behind it is. The price includes the retest, so verifying your fixes is not a separate invoice. Not included: source code review, which is a separate service; dependency analysis, which is our Software Composition Analysis service; and anything outside the signed scope, including systems you cannot authorise. Nothing is touched without written authorisation, and destructive actions stay out unless they are separately agreed.