I am not a superstitious person and I don’t believe in magic, but even still – I have to confess that the way Xamarin spits out Android and iOS apps (along with all the other platforms) feels kind of magical to me. Of course, when something breaks, I am reminded all too quickly that there is no magic happening here – Xamarin has just encapsulated a lot of complex steps into a neat and tidy black box.

For me, and I bet I am not alone here, I am very happy to leave that black box alone – and I am also happy to ignore as much of the platform-specific details as I possibly can.

Unfortunately, when it comes to security, there are platform-specific issues that simply cannot be ignored.

Welcome to the Support Corner, where we’ll occasionally talk about topics that we’re seeing while working with our customers. If you’d like to see more like this, please click the Support Corner Category.

In addition to Renaming and Control Flow, String Encryption is an obfuscation transform that can help protect your application. When customers enable String Encryption in Dotfuscator, they are often surprised to see that string constant definitions are still visible in decompiled code. Customers often contact us asking how to encrypt those string constants.

However, those string constants don’t need to be encrypted; they need to be removed entirely. Dotfuscator’s String Encryption feature takes the strings that have been inlined by the .NET compiler and encrypts them. That leaves the constant definitions behind, unused – and they can be removed.

Mobile App Security and Best Practices: Leveraging the OWASP 3-Layer Model

The mobile attack surface is expanding. As of January 2018 there were 3.7 billion unique mobile users worldwide choosing from more than 10 million verified applications across popular online stores. So it’s no surprise that security firms now detect millions of malicious install packages each quarter as hackers look for ways to compromise both existing mobile devices and their newest iteration, IoT.

In an effort to address the changing nature of mobile security the Open Web Application Security Project (OWASP) — well-known for its “top 10” vulnerability lists — has released version 1.0 of its Mobile AppSec Verification Standard (MASVS), which includes a three-layer model for application defense designed to “offer a baseline for mobile application security (MASVS-L1), while also allowing for the inclusion of defense-in-depth measures (MASVS-L2) and protections against client-side threats (MASVS-R). Here’s how your organization can leverage these layers to improve overall mobile app security.

Welcome to the Support Corner, where we’ll occasionally talk about topics that we’re seeing while working with our customers. If you’d like to see more like this, please click the Support Corner Category.

Recently, we’ve worked with a handful of customers who are using the Spring Boot framework. Spring Boot provides a simple way to create Spring-based applications. This blog explains how to protect jars created with the framework.

Spring Boot jars use an embedded class file structure which DashO does not directly recognize. DashO processes the regular class and package hierarchy. However, it does not embed the class files from the BOOT-INF/classes directory when writing the obfuscated jar.

How important is root detection?

• Rooted devices can be extremely dangerous: When running on a rooted device, an otherwise harmless App can unmount file systems, kill processes, or run any arbitrary command.
• Rooted devices are plentiful: In the annual Android Security 2017 Year in Review, Google reported that its SafetyNet service identifies over 14 million rooted devices DAILY.
• Sensitive applications must include controls to mitigate these risks: Recent PCI Security Council guidelines and NIST controls are just two notable examples where rooted device detection and response obligations are explicitly assigned to development organizations. More generally, rooted access is synonomous with unauthorized privilege escalation and is, therefore, incorporated by reference in virtually every privacy obligation developers face, e.g. GDPR, HIPAA...

2018’s RSA Conference is in the books; IT professionals and C-suite executives are heading back to work, ready to leverage what they’ve learned and put it into practice. This year’s stand-out? The changing role of data privacy and protection regulations. Attendees made it clear that these topics were top-of-mind — hackers are finding new ways to compromise app security, even as emerging legislation puts more pressure on companies to keep data safe.

Development’s Journey to Effectively Implementing App Protection

Because data is created, accessed, and changed through applications, hardening and shielding your applications is a key component to protecting your data. Adding application protection to your secure software development lifecycle will make it more difficult for people and machines to exploit them. But, what are the factors to consider when thinking about application risk? Effective application risk management is a sustained, consistent practice and technology selection and implementation is a specialized discipline within that practice. The initial steps below offer a roadmap to selecting and implementing application hardening and shielding as a part of a broader application risk management program.

The full Infographic in pdf form is available here.

• Does app have intellectual property?
• Does app gate access to value?
• Does app access private information?
• Is the app subject to regulation?
• Does app run in an untrusted environment?

“Software is eating the world.” The now-famous quote by technology expert Marc Andreessen was relevant in 2011 but seems downright prophetic in 2018 — the rise of web-based, mobile and IoT applications have created a market both massive and ever-changing. Companies know that simply staying competitive requires cutting-edge apps that both streamline the user experience and provide a steady flow of actionable data. But malicious actors also recognize the value of applications — and will do anything they can to compromise, infiltrate or damage business app networks.

It gets worse: According to the Center for Internet Security, “malspam” threats — unsolicited emails that contain malicious links or attachments — remain the number one attack vector for cybercriminals. Why? Because despite their simplicity, these attacks succeed. As noted by SC Magazine, meanwhile, 80 percent of IoT applications still aren’t tested for security vulnerabilities.