Once a mobile device or an on-premises server or a PC… is known to be compromised or in hostile hands (detected, for example, when someone attaches a debugger to an app in what is a strictly production setting), doesn’t it make sense to be able to alter your app’s runtime behavior in real time? …and not just at the time of discovery – but also into the future – and for as long as the runtime environment remains suspect?
DashO (PreEmptive’s Java and Android obfuscation tool) can inject logic (no coding) to detect if a debugger is attached at runtime– further, DashO can inject a variety of real-time defenses and even transmit an alert (Dotfuscator for .NET flavors will soon have these same capabilities) – but all of this awesomeness is only triggered when the debugger is attached.
If the same app is restarted without the presence of a debugger, it runs just fine – this may be exactly the behavior you need – but this may be a big issue too. After all, the app is still in the hands of someone willing and able to attach a debugger!
What may make sense in this scenario is to disable the app permanently – not just when a debugger is attached – but for all time – why? Because a debugger was attached so who knows what’s coming next? What you need in this scenario is “application bricking.”
Note, I’m using the term “bricking” even though I may want to do all sorts of other things once I suspect foul play including (but not limited to) modifying app behavior, transmitting special telemetry, etc…
Device bricking is already common practice – when a device has been lost or stolen, most carriers (or OS providers) will let you lock or even wipe a device. Why? …because once a phone is in the hands of someone who’d steal a smartphone, the likelihood skyrockets that this person would, given the opportunity, also steal data, dollars, or an identity.
Why link application bricking with a debugger defense? Any self-respecting hacker makes sure to develop mad debugging skills – debuggers are the go to tool when you need to:
Using these techniques, a hacker can gain access to systems and data far beyond the one application; and, therefore, any environment where unauthorized debugging has occurred can reasonably be characterized as compromised or outright hostile.
Fortunately, by combining two complimentary DashO features, you can defend against unauthorized production debugging – in real-time and for all time.
Here’s a simple three step recipe (for more detailed technical documentation, visit DashO Debug Preview Doc.
Step 1: implement DashO Shelf Life with an updatable trigger set in the distant future.
Step 2: implement a simple method to update that trigger setting from the future to the past; once set, the application will assume the behavior of an expired trial, e.g. it will refuse to run under any circumstance.
Step 3: Implement DashO Debug Defense to automatically call the method described in step two along with any real-time anti-debugger defenses you may want to deploy (throwing random exceptions, notifications, etc.).
The result of this simple post-compile injection process is an application that, if ever attached to a debugger in production, would be “bricked going forward,” e.g. it would never run again (with or without a debugger attached).
Custom messages, wiping of data, or any other defensive action can be embedded alongside the automatic behavior outlined above.
The following illustration describes an Android App that has been instrumented with both debug detection and Shelf Life (auto-expiry) technology as described above – the minimal “annotations” that were used to implement all of the above behaviors are included as well.
In order to be effective, risk management and app security policies need to be defined globally and applied consistently. Post-compile injection as a final step in your build and deployment pipeline provides an efficient, scalable, repeatable, and auditable means to standardize these kinds of controls without having to train and coordinate across your development teams.
Platform support:
For more information on how DashO or Dotfuscator can be used to secure you software and data against hackers with debuggers, contact us.