Thick Client Penetration Testing

Desktop applications hold secrets scanners never see — we decompile, inspect, and break them like a real attacker would.

Why this matters: Thick clients — desktop applications — sit in a blind spot between web security and binary analysis. They store credentials locally, trust the operating system too much, and often talk to backend APIs that were never designed for a hostile client. Attackers reverse-engineer them in minutes; most security programs never test them at all.

What we cover

  • Electron, .NET, Java, and native desktop applications
  • Local storage: tokens, API keys, and PII in plaintext
  • DLL hijacking, side-loading, and library planting
  • IPC, named pipes, and COM interface abuse
  • Hardcoded secrets, debug flags, and update mechanisms
  • Backend API authorization flaws the client exposes

How we test

1Static analysis

Decompilation and disassembly: embedded secrets, authentication logic, and configuration.

2Dynamic testing

Runtime instrumentation on real systems: traffic interception, storage inspection, and IPC probing.

3Backend review

The APIs the client calls are tested for authorization and abuse — the client is the attack vehicle.

4Report & retest

Findings with reproduction steps and environment-specific remediation; retest included.

What you get

  • Desktop-specific findings with reproduction steps
  • Backend API issues the client exposes
  • Hardening guidance for the next release
  • Free retest of fixed findings

The engagement at a glance

📞 Free scoping call

A short conversation about your environment. You receive a written scope, timeline, and fixed quote — no obligation.

✍️ Signed authorization

Testing begins only with your written permission and agreed rules of engagement. Always.

⏱️ Time-boxed delivery

A calendar agreed before we start, with an agreed communication plan while testing runs.

🔁 Retest included

A verification pass over everything you fix — included in the price, not an add-on.

See the full engagement process → and how pricing is scoped in our public pricing guide.

Related research from Hmmnm

Common questions

Which frameworks do you test?

Electron, .NET (WPF/WinForms), Java, and native C/C++ applications. The methodology adapts to the framework but always covers storage, transport, IPC, and the backend API surface.

Do you need the installer or a running environment?

Both are useful — the installer for static analysis, a running environment (VM preferred) for dynamic testing. We can work with either.

Is this different from web application testing?

Yes. Thick clients have local storage, OS-level trust, IPC channels, and binary-level secrets that web scanners cannot see. The testing methodology is fundamentally different.

Authorization first, always. Testing happens only with your written permission and agreed rules of engagement — the same ethics that govern responsible disclosure on this site.

Want this assessed for your environment?

A short scoping conversation is enough to get a fixed quote. No obligation — a researcher replies.

Start the conversation →