I’m working on an application risk management study/survey focusing on the importance of one vulnerability exploit in particular: debugger hacks against production apps. Our initial data set already includes responses from 100+ developers targeting cloud, mobile and desktop platforms from 15+ countries.
Today we released Dotfuscator v4.25 that includes, for the first time, anti-debug defense and alert capabilities. Dotfuscator Professional users can now configure Dotfuscator to inject logic to defend against the unauthorized use of a debugger in production. We’ve already previewed this capability in our Java/Android product, DashO, and this latest anti-debug feature sits alongside our other “detective controls” including anti-tamper and shelf-life.
Note: this document is deprecated. Please see Obfuscating Xamarin Applications with Dotfuscator for up to date instructions on obfuscating Xamarin applications.
We've previously blogged about Using Dotfuscator Professional with Xamarin Applications. We've also blogged about the recently added command line support for Dotfuscator Community Edition. Now it is time to put these two concepts together, and show how to make reverse-engineering your Xamarin application more difficult by integrating Dotfuscator Community Edition (CE) into your Visual Studio build process.
The true value of trade secrets – as with any class of intellectual property – is directly proportional to the owner’s ability to enforce their rights through criminal and civil actions.
Today more than ever, applications are mobile and can be run worldwide. And many useful apps access sensitive data and have value-added functionality within them (such as trade secrets). Because traditional firewall type attacks are much more difficult today, hackers are increasingly targeting both consumer and enterprise mobile and desktop apps as a newer attack vector. So, those apps may be at risk from theft of IP/underlying sensitive data, malware injection and more advanced targeted threats.
Harden applications against hostile and compromised environments – not just simple attacks.
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?
Pokefan Alert - augmented reality apps like Pokemon Go are rooted in the REAL WORLD (not a virtual one) – a real world with a host of very real dangers.
Pokemon Go players are walking into traffic, being lured into remote locations to be robbed, and last (but in no way least) they’re being duped into using counterfeit (tampered) Pokemon Go apps.
