.NET Application Protection

The platform operates at the intersection of build tooling and runtime security. It intercepts .NET assemblies during the build pipeline — rewriting them to obfuscate logic, encrypt strings, and inject runtime self-protection checks — then ships binary output that must run correctly in production across every customer's runtime environment and OS target.

Clomotech's role as a vendor partner is not client-to-builder. It is integration into the vendor's engineering team — working inside an established commercial codebase with existing customer contracts, existing regression baselines, and a zero-tolerance policy for silent breakage. Every change must be validated against real platform conditions: CI build agents, physical mobile devices, and release configurations that don't exist on a local development machine.

Contributions span four distinct areas of the product, each presenting its own platform-specific engineering challenge.

The platform's runtime application self-protection (RASP) features — binary tamper verification and rooted device detection — are injected into assemblies at build time and executed at runtime to verify the app's integrity and environment. On .NET MAUI Android, the runtime behaves differently from older mobile stacks: APK packaging, signing mechanics, and app startup differ in ways that affect when and how protection checks can reliably fire.

The challenge was making both checks dependable across real device and emulator conditions without generating false positives that block legitimate users. An overly sensitive tamper check would trigger on unsigned debug builds or test distribution; an overly broad root detection check would flag standard developer devices.

The solution involved updating the integration paths through which checks are injected into MAUI Android assemblies, and tuning the validation flow so checks execute at reliable runtime entry points. The fix was iterated against real device conditions — not just emulators — to catch platform-specific timing and execution differences before shipping.

Modern .NET applications rely on a *.deps.json file for runtime assembly and dependency resolution. When the platform's obfuscated output omitted this file, apps failed at startup — the runtime could not locate and load the required assemblies.

The first fix — explicit handling to ensure deps.json is always present in final obfuscated artifacts — resolved the runtime failure. But a second, independent failure mode remained: Jenkins release builds were failing even after the file was included. Local builds and debug configurations passed; the failure was specific to the CI release pipeline.

Investigation revealed that the metadata persistence strategy used to generate and store deps metadata — initially implemented with System.Text.Json — was not stable under obfuscation in release mode. The obfuscation process itself was interfering with the serialization path in a way that only manifested under release-configuration CI conditions.