Mobuild Envuscator and Digitalis
The mobile client is an untrusted platform.
That is the starting point.
From a backend perspective, the app runs on hardware you do not control, inside software you do not control, in memory you do not control, under conditions you cannot fully verify. There will always be risk. The job is not to eliminate it. The job is to reduce it as much as possible.
That is why I built Mobuild Envuscator and Mobuild Digitalis.
They solve the same problem in different ways: how do you make mobile configuration harder to abuse?
More specifically, they both address the same broad class of issue behind OWASP Mobile Top 10 #1: improper credential usage. If apps carry sensitive material carelessly or accept protected configuration too loosely, they create exactly the kind of trust and exposure problems that category is warning about.
There are secondary overlaps too. Envuscator also helps with insufficient binary protections by making shipped material harder to pull apart. Digitalis also pushes into insecure data storage territory by treating protected configuration as a governed security asset with lifecycle controls instead of just another app setting.
Two Controls, Same Goal
Both projects are about configuration trust.
Both are also responses to the same practical mobile problem: credentials, configuration, and trust material are too often handled as if the client were safer than it is.
Envuscator focuses on configuration that ships with the app. It makes that material harder to extract by layering obfuscation into the build and runtime path. The point is simple: if values have to live in the client, they should not be sitting there in the easiest possible form.
Digitalis focuses on configuration that comes from the backend. It abstracts attestation services and turns secure configuration delivery into a backend control plane problem. The point there is also simple: if a client is untrusted, the backend should make the trust decision and only deliver protected configuration after verification and policy evaluation.
One hardens what the client carries.
The other hardens what the backend is willing to hand over.
Why I Built Envuscator
Envuscator exists because too many mobile apps are lazy about embedded configuration.
Not every value inside an app is a secret. That is not the point. The point is that values like endpoints, identifiers, feature controls, and public keys still shape the attack surface. If they are trivial to lift out of the binary, the app is doing part of the attacker’s work for them.
Envuscator is meant to make that extraction harder in layers.
The build path randomizes obfuscation per build. The result is compiled into native obfuscated binaries. A light runtime SDK reads values only when needed. That combination does not make the client trustworthy, and it does not claim perfect secrecy. It just stops donating configuration in plain form.
That is the right level of honesty for this kind of tool.
The credibility here is not just marketing language. The project docs and RFC work are explicit about the model: obfuscation is a control, not a complete solution; configuration should still be treated as potentially public; and the backend still has to carry the real trust burden.
That is why I think Envuscator works well for the beerware developer. It is a practical control. It is small. It is understandable. It fits into normal mobile build workflows. And it improves the posture of the app without dragging in enterprise machinery.
Why I Built Digitalis
Digitalis starts from a stricter position.
If the client is untrusted, then secure configuration cannot be a blind fetch. It has to be authorized. It has to be versioned. It has to be bound to backend policy. It has to be delivered in a way that reflects a security decision, not just a convenience API.
That is what Digitalis is for.
At a product level, Digitalis abstracts attestation services so apps do not have to build their security model around one provider or one vendor-shaped integration. At a system level, it turns attestation, policy, and configuration delivery into a consistent trust bootstrap.
That is not hand-wavy positioning. It is the actual architecture.
The Digitalis whitepaper and RFC set push this point clearly:
- the backend is the control plane for client trust
- attestation signals matter only after backend verification
- protected configuration should not activate before attestation and policy
- configuration is a governed security asset, not generic app settings
That is the difference between “remote config” and secure configuration.
Digitalis is the more enterprise-shaped answer because it has to be. Once the backend is making trust decisions, you are dealing with verification, authorization, rotation, rollback resistance, and auditability. That is inherently a bigger system than build-time obfuscation.
But it is solving the same class of problem. It is reducing how much trust is placed in the client and moving that trust decision to the place that should own it.
Why These Two Belong Together
I do not see Envuscator and Digitalis as competing ideas.
I see them as the same idea applied at different control points.
Envuscator says: if configuration must ship in the client, make extraction harder.
Digitalis says: if configuration comes from the backend, make delivery conditional and backend-authoritative.
Both assume the same thing: the client is exposed, so trust has to be earned and risk has to be reduced.
That is also why I see both of them as useful responses to OWASP Mobile #1. They attack improper credential usage from two sides: one by making embedded material harder to extract, the other by making protected backend-delivered material harder to issue without verification.
That is why I use both.
Digitalis is the stronger enterprise answer when you need backend-governed trust, attestation abstraction, protected config lifecycle, and policy enforcement. Envuscator is still effective when you want a lighter-weight control that makes shipped configuration materially harder to pull apart.
Different operating models. Same security instinct.
Why Beerware Still Matters
I keep calling these beerware solutions because I want them to stay close to working developers.
Security tools often fail before they start because they arrive with too much weight. Too much cost. Too much ceremony. Too much vendor gravity. So teams put the work off, which usually means they never do it.
I would rather have a clear control that people will actually adopt than a perfect architecture that lives forever in a roadmap or a sales process.
Envuscator is closer to that small-tool end of the spectrum. Digitalis pushes further into enterprise concerns, but the intent is the same: practical security controls, clear trust boundaries, less blind faith in the client.
That is the entire thesis.
The mobile client is untrusted. Risk remains. The only serious response is to reduce that risk as much as possible.