Once a mobile device, 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 a strictly production setting), doesn’t it make sense to be able to alter your app’s runtime behavior in real time, 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 a debugger, it runs just fine, and this may be precisely 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, 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 standard practice—when a device has been lost or stolen, most carriers (or OS providers) will let you lock or 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. Therefore, any environment where unauthorized debugging has occurred can reasonably be characterized as compromised or outright hostile.
Fortunately, by combining two complementary DashO features, you can defend against unauthorized production debugging in real time and forever.
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 (e.g., throwing random exceptions, notifications, etc.).
This simple post-compile injection process results in 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, data wiping, 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. The minimal “annotations” that were used to implement all of the above behaviors are included as well.
Risk management and app security policies need to be defined globally and applied consistently in order to be effective. 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 your software and data against hackers with debuggers, contact us.