-------------------------------------------------------------------------------- title: "Frequently Asked Questions | Guardsquare" description: "Here are some answers for frequently asked questions regarding Mobile App Security, Mobile Application Protection, MAST, Open Source, Guardsquare, & more." source: "https://www.guardsquare.com/frequently-asked-questions" -------------------------------------------------------------------------------- # Frequently Asked Questions Learn more about mobile application security and the value of applying protective security measures to enhance your mobile app protection. ## 1. Mobile Application Security Mobile application security is the practice of securing your application from external threats. Good mobile application security strategy relies on understanding your threat model and applying the appropriate tools and techniques throughout your SDLC to eliminate or mitigate the risk of threats to your applications, related services or the data they process. ### What is mobile application security? Mobile application security is the general concept of introducing processes and practices to help find, fix and, ideally, prevent security issues from impacting your application. It is a broad category that can include any discipline of app security and applying the concepts to the unique technological considerations of a mobile app and its threat model. ### What is mobile application tampering? A malicious user will use tools and techniques to tamper with a mobile application, usually for the purpose of learning its behavior and modifying the application. This is frequently done to commit fraud or an attack against the app, its back-end or broader infrastructure, or its end users. ### How much of a threat are rooted / jailbroken devices? Rooted or jailbroken devices are more susceptible to tampering due to the elevated privileges that software and tools have on the device. If your app is running on a rooted and jailbroken device, it doesn’t necessarily mean your app is being attacked; however, jailbroken or rooted devices are often a prerequisite for certain types of attacks. In fact, a significant amount of the software that powers a mobile app can be easily manipulated by the end user on such a device. For this reason, it is encouraged that you implement detections for your app when it is running in such an untrusted environment. ### What are the threats of malware for my mobile application? Malware on mobile phones poses the biggest risk to the end users of the device. Though detection and mitigation often falls in the technical purview of the platforms themselves (Android, iOS), specific mobile malware may take advantage of the knowledge gained during a reverse engineering effort to explicitly target and exploit apps on a user’s phone. There is no single answer to protecting your app and your users data from malware, but having an in-depth defense strategy goes a long way to preventing or limiting the impact of malware on your application. ### What are man-in-the-middle attacks? Man-in-the-middle (MITM) attacks are when a malicious user intercepts and spoofs the communications between two endpoints. In a mobile application context, such an attack is usually the result of intercepting communications between the mobile app and a server, often by impersonating the server, or intercepting the requests to a server. Though such attacks are well known and relatively easy to execute, they are also entirely preventable with proper security practices in place that focus on communications. ### What are man-at-the-end attacks? Man-at-the-end (MATE) attacks describe a scenario where the end user of your application is the attacker. In this scenario, the end user has complete control over the application and the client environment used to execute it. MATE attacks use various tools, techniques and often elevated privileges to inspect, reverse engineer and tamper with the application or to spoof communications to the server. ### What is mobile application threat monitoring? Mobile application [threat monitoring](https://www.guardsquare.com/threat-monitoring) is a specialized practice of observing data and signals from a device or app to identify potential security threats. In a mobile application security context, this can include detecting occurrences of tampering, such as failed environment checks, API requests not originating from a trusted source, bot activity, code tampering, such as hooking, or invalid code signing. ### Why is mobile application threat monitoring important? Mobile application threat monitoring can be useful for assessing the significance of the threat landscape for your mobile application. It can draw attention to, and provide more insight into, the types and targets of attacks users may be performing. In certain scenarios, it can also be used to refine and target protections, block users or flag potential for fraud. ### What is mobile app attestation? [App attestation](https://www.guardsquare.com/introducing-mobile-app-attestation) is a secure approach to verify that only your app can connect to your APIs. By adding server-side validation, app developers and security teams can ensure only legitimate apps interact with their APIs - blocking bots or non-genuine apps from interacting with your APIs. ### What is the difference between app attestation and client-side protections? Unlike client-side protection, mobile app attestation logic is executed on the server, resulting in enforcement that is opaque to attackers. It gives you greater control to instantly change security policies that evaluate the app environment and code integrity. These policies allow fine-grained control and can be modified without requiring your app to be republished to the app store. ## 2. Mobile Application Protection Mobile application protection is the concept of applying protective security measures to provide defense against reverse engineering and tampering. This can help prevent your app from being tampered, modified, cloned or analyzed to exploit other vulnerabilities affecting the app or the data it processes. ### What is mobile application protection? [Mobile application protection](https://www.guardsquare.com/what-is-mobile-application-protection), also known as app shielding, is the practice of implementing protective measures to increase the complexity of an app’s code to prevent reverse engineering or tampering. ### What is SSL pinning or certificate pinning? SSL, TLS or [certificate pinning](https://www.guardsquare.com/blog/ios-ssl-certificate-pinning-bypassing) ensures that an application only trusts a pre-defined back-end identified by the public key contained in its TLS certificate. SSL pinning would be used as an additional layer of security for API communications, ensuring the communication cannot be intercepted by a man-in-the-middle (MITM) attack that would present a different, but otherwise valid, security certificate. ### What is reverse engineering and how is it applicable to mobile applications? Reverse engineering is the practice of acquiring knowledge through inspection and analysis of an application package. Often, the information is used to modify or bypass certain logic or functionality. Though sometimes, reverse engineering can simply be used to learn how an application works or to discover the presence of unannounced features that can be valuable to leak to the public. Any mobile application that is downloadable by untrusted users on their devices is susceptible to reverse engineering. ### What is code hardening? [Code hardening](https://www.guardsquare.com/code-hardening) is the general concept of increasing the security of your code. Said another way, it’s the process of improving the resilience against reverse engineering or runtime analysis, and reducing the potential for vulnerabilities or security threats. ### What is polymorphism? Polymorphism is pivotal in Guardsquare's security framework. While initial code transformations and security checks offer effectiveness, they're prone to discovery and bypassing over time by determined attackers. Once malicious actors decode obfuscated values and identify security checks, attacking subsequent application versions becomes easier. Maintaining a favorable defense requires continuously changing protective measure placement, a strategy known as "resetting the clock" on attackers. This forces them to repeatedly reverse engineer each iteration as if it's a new program as the previously acquired knowledge is lost. This concept of resetting the clock with every new build is known as Polymorphism. ### Is there a difference between code hardening and code obfuscation? Even though code hardening and code obfuscation are often used as synonyms, code hardening is a more general term. It covers a variety of practices for increasing the robustness of your code against a variety of security threats. [Code obfuscation](https://www.guardsquare.com/what-is-code-obfuscation), on the other hand, is a specific technique or practice that increases the complexity of a mobile app’s code and hides data, making it less susceptible to inspection and analysis. Code obfuscation is a useful layer of defense, increasing the complexity of analyzing an application. ### Is obfuscation a reliable approach for security? Correctly applied and renewed, state of the art obfuscation techniques can practically prevent an attacker from gaining useful insight into application data and logic through binary inspection and analysis. This approach often leads attackers to look for other approaches to infiltrate a mobile app. This is where the numerous other layers of a complete mobile application protection solution come into play. While obfuscation should not be relied on as the sole security measure for your application, it is very useful in combination with other mobile app protection features. ### What is runtime application self-protection? (RASP) (RASP)[https://www.guardsquare.com/runtime-application-self-protection-rasp] is a term commonly used to refer to a set of runtime protection techniques aimed at detecting anomalies in the execution environment or process code and data. Typically, because such detection can be configured with a reaction, e.g. reporting or crashes, they are said to be ‘self protecting.’ ### Why is runtime application self-protection (RASP) an important part of mobile app security? RASP features help ensure environment integrity, code integrity and app integrity, and can be very powerful when combined with code obfuscation and other protections against static analysis. Any good, in-depth security strategy relies on layers of protection to deal with the multitude of tools and techniques used by an attacker. ### What is environment integrity? Environment integrity is a specific category of RASP features that ensure the environment in which an application is executed can be more readily trusted. This typically means verifying the lack of elevated privileges (root, jailbreaks), ensuring real hardware (rather than emulation), and verifying certain tools and techniques commonly used for tampering are not present. ### What is system library integrity? Mobile applications don’t just rely on the code within the application itself; they also rely on code provided from system libraries. For this reason, system libraries are a vector that an attacker can focus on with reverse engineering efforts. System library integrity is a specific RASP feature that focuses on ensuring critical system libraries your application relies on have not been tampered with. ### What is hooking? Hooking is a technique that is used to intercept calls to a function of an application and replace it with a script or code that changes the behavior. This technique is often used to achieve some sort of progress in reverse engineering, usually bypassing some form of check or step in the application logic. ## 3. Mobile Application Security Testing [Mobile Application Security Testing (MAST)](https://www.guardsquare.com/what-is-mobile-application-security-testing) covers the processes and tools used to identify potential security issues in your Android and iOS mobile applications. It also provides information to help remediate those issues to reduce risk. Mobile Application Security Testing can be performed manually or through the use of automated tools using a variety of techniques. ### What is MAST and why is it important? Mobile application security testing is the processes and tools used to identify security issues in an application with the intent to remediate those issues before they can be exploited by an attacker and have an impact on users or business. ### What is the difference between MAST and pentesting? Penetration testing (also known as pentesting) is a form of security testing that typically involves a 3rd party expert performing a range of tests and analysis on an application to identify security risks. Because it is typically done by an external party and may require more significant resources, it is often conducted at infrequent intervals, usually with specific requirements. ### Why is automating your mobile app security testing important? Relying solely on penetration testing and manual efforts to test the security of your application can be costly and often will not keep up with the pace of software development of a mobile application. The manual activity would slow down the release process and possibly compromise the completeness of your security testing. A common strategy to reduce the impact of security testing on development teams is to shift left with the testing and verification being done through automation as part of the CI/CD process. By automating your MAST, you get immediate feedback on security issues in your app, you can remediate them very quickly, and make pentesting more efficient and effective with a higher likelihood of a positive outcome. The automation, the timely feedback, and the ability to quickly fix issues results in less disruptions for the development team and reduced schedule impacts. ### Are there any standards I can reference for performing mobile application security testing? The most relevant standard for mobile application security testing is the [OWASP Mobile Application Security Verification Standard (MASVS)](https://www.guardsquare.com/blog/owasp-mobile-top-10-security-risks-for-app-developers), which provides guidelines on what to test for. This is complemented by the Mobile Application Security Testing Guide (MASTG), which provides guidelines on how to test for them. These guides identify the primary security risks to consider when developing a mobile application. ### What is static application security testing? Static application security testing (SAST) is a security testing method that involves analyzing the source code, bytecode, or binary code of a mobile application without actually running the application. It aims to identify security issues, weaknesses, and potential flaws in the application's codebase. ### What is dynamic application security testing? Dynamic application security testing (DAST) is a type of security testing that involves actively scanning and testing the mobile application while it is running on a real device or on a simulated runtime environment. It aims to identify security issues that the apps can incur during runtime. There are different types of dynamic application security testing, including black box testing, or interactive testing. ### What is interactive application security testing? Interactive application security testing (IAST) is a type of dynamic security testing which combines elements of both static application security testing (SAST) and dynamic application security testing (DAST) to provide comprehensive security analysis. In the context of mobile apps, IAST involves instrumenting the application with additional monitoring functionality that actively observes the application's behavior and interactions during runtime. The monitoring is added to the application's code, libraries, and dependencies to identify security issues and weaknesses at runtime. Typically, the instrumented app is run by an app developer, or as part of the development team’s runtime tests. ## 4. Open Source Open source software is a critical enabler for modern software development. Guardsquare itself has its origins in [ProGuard®](https://www.guardsquare.com/what-is-mobile-application-security-testing), an open source technology for optimizing and shrinking your Android applications. ### What does it mean to be an open source tool? Open source software refers to software released with source code under a license that allows you to inspect, modify or distribute that software with fewer restrictions than a typical closed source software package or component. Open source software often originates from a passionate community of developers that wish to share the software they use to solve a problem or need. ###Are open source tools safe to use? Open source software should be considered as safe as other forms of software. In some cases, open source software can be trusted more than closed source software because of your ability to inspect and modify the software. That said, relying on popular open source software and components can introduce risk if you don’t adequately assess the risk and provenance of that software. ### How is open source software used in mobile app development? Many aspects of mobile app development are supported by open source software. Google is perhaps the most well known leader in open source for the mobile community with the Android operating system and developer tools. There are many other specialist tools that help support the development process for mobile apps, as well as popular open source components which are used for many of the common functions of a modern mobile application. ### Does ProGuard® provide security protection for my mobile app? The primary purpose of [ProGuard®](https://www.guardsquare.com/proguard) is to optimize and shrink your Android app. One of the core features, name obfuscation, which helps decrease the size of an app, also provides a layer of obfuscation. ### What is the difference between ProGuard® and DexGuard? [DexGuard](https://www.guardsquare.com/dexguard) is a commercial product, built on the same core as ProGuard®. It offers backward compatibility with your keep rules, and many additional mobile app security and protection features for your app. DexGuard also gives you the benefit of shrinking and optimization with added advantages to protect your application from reverse engineering and tampering. More details about ProGuard® and DexGuard can be found in this [blog post](https://www.guardsquare.com/blog/dexguard-vs-proguard). ### Since ProGuard® is open source, who primarily maintains and contributes to it? Guardsquare is the company that was ultimately created after the success of the ProGuard® project and is the official maintainer of the project. Guardsquare works with a community of developers to continually improve and maintain ProGuard®. ### What is ProGuardCORE and what can I do with it? [ProGuardCORE](https://github.com/Guardsquare/proguard-core) is a free library to read, analyze, modify, and write Java class files. It is the core of the well-known shrinker, optimizer, and obfuscator [ProGuard®](https://github.com/Guardsquare/proguard), the [ProGuard® Assembler](https://github.com/Guardsquare/proguard-assembler) and Disassembler, and our [Kotlin Metadata Printer](https://github.com/Guardsquare/kotlin-metadata-printer). It is also the core of our commercial tools, including DexGuard and AppSweep. ### How can ProGuard® help with managing keep rules for ProGuard® or R8? Though ProGuard® and R8 are both similar (they are designed to shrink, optimize and perform simple name obfuscation for Android apps), ProGuard® contains a feature not found in R8 to help quickly debug configurations: ‘-addconfigurationdebugging’. This provides invaluable feedback at run-time about possibly missing configurations. You can read more in our [blog](https://www.guardsquare.com/blog/proguard-configuration-made-easy). Given the similarities in the keep rules for ProGuard® and R8, we’ve also created a free convenient service called [ProGuard Playground](https://playground.proguard.com/) to interactively test and tweak keep rules without having to rebuild your app. This is compatible with ProGuard® and R8. ### How can I contribute to Guardsquare’s open-source projects? We are always looking to hear from the community of developers that use the tools we provide. You can contribute directly to [ProGuard® on GitHub](https://github.com/Guardsquare/proguard) by submitting issues or pull-requests. You can also find a complete list of other interesting repos for projects we’ve open-sourced on our [GitHub page](https://github.com/Guardsquare/). ## 5. Guardsquare Supported Technology Guardsquare offers several products that support the development of mobile applications and helps in achieving strong [mobile app security](https://www.guardsquare.com/what-is-mobile-app-security). ProGuard, DexGuard, iXGuard, AppSweep and ThreatCast are all part of the Guardsquare suite of products, helping you optimize, protect, test and monitor your applications. ### Is mobile app security necessary on all platforms? Mobile application threats exist on both Android and iOS. A common [misconception](https://www.guardsquare.com/video/misconceptions-about-ios-mobile-app-security) is that iOS inherently is more secure than Android. Though there are certainly differences between Android and iOS with respect to security considerations and level of difficulty to reverse engineer, the bottom line is that a skilled person with the right knowledge of reverse engineering and tampering can accomplish many of the same goals with apps on the iOS platform. ### Do you support Flutter™? Guardsquare offers mobile app protection for a wide variety of native and cross-platform languages and frameworks, including [Flutter™](https://www.guardsquare.com/flutter-mobile-app-protection). ### Do you support React Native? Guardsquare offers mobile app protection for a wide variety of native and cross-platform languages and frameworks, including React Native. ### Do you support Java? Guardsquare offers mobile app protection for a wide variety of native and cross-platform languages and frameworks, including Java and Kotlin. ### Can Guardsquare protect libraries / SDKs? If so, which libraries does it support? Guardsquare’s mobile app protection is used by some of the leading SDK providers to protect their intellectual property and to harden SDK’s against reverse engineering. Many third party mobile libraries you rely on, especially for security sensitive functions, such as payment processing, likely rely on Guardsquare for protection. ### Do iOS apps require additional security? Mobile apps built for iOS require similar levels of mobile app protection as mobile apps built for Android. The threat model is quite similar, though there are technological differences. For iOS, we offer a product called iXGuard that is purpose built to support Objective C, Swift and cross-platform frameworks used for iOS. ## 6. Guardsquare Products Guardsquare offers several products that support the development of mobile applications and helps in achieving strong mobile app security. ProGuard®, DexGuard, [iXGuard](https://www.guardsquare.com/ixguard), AppSweep and ThreatCast are all part of the Guardsquare suite of products, helping you optimize, protect, test and monitor your applications. ### Will mobile app protection solutions from Guardsquare impact the performance of the apps? Guardsquare products offer a high degree of configurability, so you can easily adjust where security checks are performed and the aggressiveness of the checks. These configuration options can be used to ensure the optimal balance of security and performance. In fact, Guardsquare is trusted by many of the leading online gaming studios, where performance expectations are highest. ### What are the main differences between DexGuard and iXGuard? DexGuard and iXGuard are both part of Guardsquare’s mobile app protection solution. DexGuard is our solution built specifically for Android applications and iXGuard is our solution built for iOS applications. Conceptually, the products are very similar and protect against roughly the same threats. The primary difference is specific to the technology differences in Android vs iOS apps. ### How long does it take to configure mobile app protection? The fastest way to integrate is by using our guided workflow approach, which can be done in less than a day. Integration using the manual configuration through a text-based file can take up to 2-3 weeks. ### Does Guardsquare provide protection against malware attacks? Guardsquare provides both the security expertise and customizable protection tools required to harden Android applications against malware attacks. Using [DexGuard’s built-in malware protection](https://www.guardsquare.com/dexguard) feature, you can easily protect against accessibility services abuse, screen spying, and UI injection attacks while maintaining the full functionality and proper usability of your app for all users. By combining DexGuard’s malware protection with code hardening and runtime protection you can ensure the most robust protection. Using the Secure In-App keyboard add-on for DexGuard & iXGuard, you can defend against keylogger malware and eliminate the risk of data leaks, while ensuring a seamless user experience. You can learn more about malware, the common attack methods and behavior, and how to protect your app in our malware research at the [Mobile Application Security Research Center](https://www.guardsquare.com/mobile-app-security-research-center/malware/overview). ### Does Guardsquare offer a solution for mobile application threat monitoring? Yes, Guardsquare offers a product called [ThreatCast](https://www.guardsquare.com/threatcast-mobile-threat-defense) for mobile application threat monitoring. It provides real-time visibility into threats from devices running your application so you can understand where reverse engineering efforts are coming from and what those attacks are targeting. Through custom webhook integration, you can also consume those insights integrating them into a SIEM tool, or as part of a fraud or anti-cheat system. ### Does ThreatCast require DexGuard and iXGuard? Currently ThreatCast offers insights on triggered RASP events and therefore requires that you utilize DexGuard or iXGuard to protect your mobile application. ### Does ThreatCast work for SDKs? ThreatCast is not suitable for a mobile SDK, since your SDK will be consumed by many end applications that you do not control. ### What kind of data does ThreatCast collect? ThreatCast will capture basic telemetry of the device, device metadata and forensics about the mobile threat detected. Full details of the data we collect can be found in our [Data Processing Agreement](https://www.guardsquare.com/data-processing-agreement). ### What is AppSweep? [AppSweep](https://www.guardsquare.com/appsweep-mobile-application-security-testing) by Guardsquare performs automated mobile application security testing with every build. It’s a developer-friendly solution that helps you shift your security testing left, identifying security issues sooner and providing actionable recommendations to fix. ### How can I use AppSweep to better secure my mobile application? The best practice with AppSweep is to integrate mobile application security testing into your CI/CD process, so each release you build is analyzed for potential security issues. The more frequently you scan with AppSweep, the easier it is to resolve security issues. [Learn how AppSweep](https://www.guardsquare.com/blog/supporting-owasp-masvs-v2-appsweep) provides support for the OWASP Mobile Application Security Verification Standard (MASVS) ### Does AppSweep replace pentesting? AppSweep allows you to get immediate results from testing your mobile application. It can be used as part of every build of your mobile application, giving your team the best chance of resolving security issues before release and in advance of any further security reviews. Worth noting is that penetration testing can still be a valuable exercise to periodically assess the security of your app with a robust set of tests that go beyond what can be automated using tools. But using AppSweep as part of your regular development process will minimize the chances of discovering issues during a formal security review or pen test. ### Are there any compatibility or usage issues? Compatibility and usage depend on the choices made by the developers during implementation. Developers have the option to choose between the system keyboard and the Secure In-App Keyboard SDK for each view that implements a keyboard. Developers need to make this choice based on their specific requirements and considerations. ## [Do you want to learn more about Guardsquare?](https://www.guardsquare.com/request-pricing) -------------------------------------------------------------------------------- title: "Mobile Banking Security for Financial Apps | Guardsquare" description: "Mobile banking security is essential. Give your users confidence their information is securely protected with Guardsquare financial app security." source: "https://www.guardsquare.com/mobile-banking-finance-app-security" -------------------------------------------------------------------------------- # Trustworthy and compliant financial app security Give your users confidence their financial data is in good hands. Protect against Android malware attacks, reverse engineering and tampering and meet compliance mandates like PSD2, PCI (DSS & MPoC), and more with Guardsquare mobile banking security. [Connect with an expert](https://www.guardsquare.com/request-pricing) ## Mobile financial services depend on user trust But without the widespread adoption of security practices like code hardening or threat monitoring, it’s not hard to see why users have trouble entrusting mobile apps with their sensitive financial information. Connect with Guardsquare to benefit from a team of experts deeply versed in mobile banking app security best practices and ensure that your app has your users’ full trust. * Less than 50% of these financial apps are using proper mobile application security. Source: [Financial App Security Report](https://www.guardsquare.com/financial-app-security-report) ## Why security is key to mobile success In order to meet modern consumers’ wants and needs, financial app security is essential. ### Meet Compliance #### Exceed local and industry regulations Upgrade your mobile banking security and privacy practices, protect sensitive customer data and minimize your overall risk profile by meeting regulations and compliance mandates. With Guardsquare’s suite of mobile app security solutions, you’ll meet regulatory requirements such as: - PCI (DSS & MPoC) - PSD2 - International banking regulations [Read our blog](https://www.guardsquare.com/blog/4-impacts-of-mpoc-on-mobile-payment-app-security) ### Secure customer data #### Gain multiple layers of data protection Proper application shielding requires more than just code obfuscation. Guardsquare’s solutions combine multiple layers of protection — including code hardening, Runtime Application Self-Protection (RASP), Mobile Application Security Testing (MAST), and real-time threat monitoring — to make it increasingly difficult for a threat actor to access your customers’ data and your intellectual property. [What is mobile app security](https://www.guardsquare.com/what-is-mobile-app-security) ### Protect against malware #### Protect your application against Android malware attacks Due to the surge in mobile banking usage, Android malware threats increasingly target Android banking and digital wallet apps. While defending against malware is a collaborative effort, mobile app publishers should ensure their apps are resilient against attacks from the start. Guardsquare financial mobile app security provides you with comprehensive protection against Android malware while maintaining the full functionality and proper usability of your app for all users. [Learn more](https://www.guardsquare.com/android-malware) ### Build brand reputation #### Give your users peace of mind Mobile app developers — no matter what their industry — have to fight back against the perception that their apps are less secure. In the financial services industry, this perception can kill adoption rates. Prove to your users that financial app security has been a priority throughout the software development lifecycle. [Read our blog] (https://www.guardsquare.com/blog/the-impact-of-mobile-app-security-for-financial-services) ### API runtime defense against malware and fraud Authenticate the integrity of your app before initiating financial transactions like peer-to-peer (P2P) payments and fund transfers. Reinforce protective measures to KYC implementation with the flexibility of dynamic, server-side configuration policies. [Learn more about app attestation](https://www.guardsquare.com/introducing-mobile-app-attestation) ### Facilitate secure payments on SoftPOS systems Enhance your app’s security posture when delivering mobile payments. Examine real-time threats and attestation results in the same dashboard to stay up-to-date on attackers and remain compliant with PCI MPoC standards. [Learn more about app attestation and threat monitoring with ThreatCast](https://www.guardsquare.com/threatcast-mobile-threat-defense) ### Report: Most mobile financial apps fall short of security best practices We researched more than 3,000 of the world’s leading financial services apps on the Android marketplace and assessed their application shielding practices. Despite how essential mobile banking security is to the financial industry and its customer base. [Read the report](https://www.guardsquare.com/financial-app-security-report) - <50% of financial apps apply best practices in mobile application security. - 40% of consumers who don’t use mobile payments cite security concerns as their main concern. - 75% of consumers are “very cautious” when sharing their financial data. ### Comprehensive security We provide the full spectrum of protection for both Android and iOS financial service apps as well as mobile app security testing, platform-agnostic threat monitoring, and highly responsive support to maximize uptime and speed of implementation. #### DexGuard for Android Protect your mobile Android apps and SDKs against reverse engineering and tampering through multiple layers of code hardening and RASP checks. [Learn more](https://www.guardsquare.com/dexguard) #### iXGuard for iOS Use iXGuard to prevent threat actors from accessing your user’s data and learning about your intellectual property through multiple layers of code hardening and RASP checks. [Learn more](https://www.guardsquare.com/ixguard) #### ThreatCast for real-time monitoring Gain visibility into your apps post-publication, track suspicious activity and continuously improve your security implementation. [Learn more](https://www.guardsquare.com/threatcast-mobile-threat-defense) #### AppSweep for security testing Application security testing designed for developers, built for mobile. Find and fix security issues in your Android app’s code and dependencies. [Learn more](https://www.guardsquare.com/appsweep-mobile-application-security-testing) -------------------------------------------------------------------------------- title: "Compiler-Based Mobile App Security vs. App Wrappers | Guardsquare" description: "Learn about the key considerations when choosing between compiler-based mobile app security vs. mobile app wrappers and appropriate use cases." source: "https://www.guardsquare.com/blog/compiler-vs-wrapper" -------------------------------------------------------------------------------- [Mobile application protection](https://www.guardsquare.com/what-is-mobile-application-protection)puts the necessary lock on the application package you release. It prevents brand damage and revenue loss from threats such as back-end abuse, app cloning, piracy, IP theft, reverse engineering, and more. While there are multiple well known tools available to protect your mobile app, they are, of course, not all created equally. Selecting an application protection tool should not be a checklist exercise with obscure feature names. Rather, it should start with choosing a proper foundation! In this article we explain the two groups of mobile app protection solutions available in the market. We’ll describe how they fundamentally work and why the group of compiler-based solutions is uniquely qualified to provide that foundation. One group, mobile app security wrappers, will add a protected library with security primitives to your application. Typically, these solutions will instrument your original code with the required calls into the new library. The other group is compiler-based solutions which, on the other hand, will rebuild your original code completely and weave in multiple layers of protections in addition to [hardening your application code](https://www.guardsquare.com/code-hardening). So which of these groups fits your use-case? In the sections below, we’ll first paint a more complete picture of both groups, afterwards we discuss benefits, challenges, and appropriate use cases of each type. Mobile app security with wrappers --------------------------------- Conceptually, wrappers are typically combinations of a regular Android/iOS SDK and some application package level post-processing. The SDK serves two main purposes: 1. Providing the application developer with some security controls, e.g. root detection 2. Undoing transformations at runtime, which post-processing logic puts in place, e.g. code or asset encryption. An important point to highlight here is that, just like any other regular SDK, there is the clear 1-to-many distribution approach. A single version or build of the SDK will be used to protect all customers. A second SDK property that’s inherently shared by these types of solutions is the ‘separation of concerns.’ All library-provided logic is cleanly separated from your main application code. The communication between the two happens through a limited, by design, very visible set of channels. This separation exists on two abstraction levels: on the package file content level as a clearly separate library, and on the code level as a set of clearly separate functions. Though a mitigation for the first one could be static linking, this is typically not possible due to technical constraints. Some wrappers go a small step beyond combining a library with package level post-processing and include some rudimentary code patching. Sometimes called ‘hybrid solutions’, these efforts are taken in an attempt to unlock some of the typical advantages of compiler solutions (described below). Some available examples include: * ‘unbreaking’ application code from the included library for tighter coupling, * automatically calling into the additional library from the application code to try and remove some of the security bottleneck. These patches are basic pattern matching-based replacements and should not be confused with proper recompilation-based solutions. The need to maintain the wrapper approach advantages prevents the required depth needed to make the code patching effective. Compiler-based mobile app security solutions -------------------------------------------- Solutions in the compiler-based group will replace/repeat and enhance a step in the app compilation pipeline. Different solutions use different abstraction levels to apply their transformations (e.g. source-to-source, AST, IR, machine code). Though we won’t address the technical nuances of each abstraction level in this post, it is worth noting that there is more depth here to consider as it relates to leveraging a compiler-based solution. Moving on, regardless of the chosen abstraction, the compiler-based approach enables analysis and code manipulation techniques fundamentally out of reach with any library-centric approach as seen in wrappers. These building blocks, in turn, unlock many of the advanced protection features that make up a modern software protection scheme. This is crucial because, in this way, compiler solutions level the playing field between attacker tools and the security solution, ensuring compiler solutions are not at a conceptual disadvantage vs. the attacker. The major steps taken by compiler solutions are the following: * Parse and model the code and data, application package, and metadata * Reconstruct and derive high-level abstractions, e.g. control flow * Add to and transform the instructions * Rebuild and repackage the application Several of these steps dictate some of the inherent properties not found in wrappers. First of all, having to parse, model, reason and rebuild will always take more time than adding an additional library to your application. This results in comparatively longer build times than library-based approaches. Second, having to parse and model your application and its metadata means that this approach is more sensitive to changes in your tech stack, like switching languages or upgrading versions. Wrappers vs. compilers: The key differences ------------------------------------------- Now that we understand both types of solutions, let’s explore some of the pros and cons of the earlier discussed characteristics. #### One-to-many approach As stated above, wrappers in general need no or very little information about the application they are protecting. They work 1-to-many, essentially just ‘packing’ all apps with the same protection library over and over again. This enables some quick wins, though they come at a great cost. The table below summarizes the trade-offs of this approach, the benefits of being a “pro” for app security wrapping solutions, and the disadvantages of being a “pro” for compiler-based solutions. **Wrappers** **Compiler-based**Depending on the solution, there is a potential initial integration advantage for your team since the **build times are generally faster** than compiler solutions.Need for proper modeling of your app and recompilation leads to, **on average, longer build times**. It’s impossible for a library-based solution to really tie the protection to the application internals, even though some hybrid approaches try. This leads to a glaring security issue, i.e. **attacks on these solutions are inherently easy to scale**. By using the same lock for all customers, an attacker only needs to learn how to break one to unlock them all. Compilers inherently recreate all your application code, which presents the opportunity to **interweave the security controls**. With minimal effort, these additions are randomized in semantics, locations, and structure. This property enables two crucial aspects of application security: 1. The “reset the clock” principle, forcing attackers to approach every app and version from scratch 2. A big, uniformly obfuscated “haystack,” making it hard to zero in on the security controls **Need for dynamic configuration.** Since it’s infeasible to ship or generate a new SDK for every possible combination of the configurable security controls, wrappers have to resort to runtime configuration. Technically, this means your protected application will be packaged with a protected piece of data used to decide whether the SDK should, for example, execute root detection or not. Tampering with this critical bottleneck offers attackers a straightforward way to disable all configurable controls. These issues have already popped up at several security conferences. No one-size-fits-all prebuilt artifacts are required, allowing **configuration to be interpreted at protection-time to construct and apply bespoke security controls.** Effectively, the discussed configuration bottleneck is not available in the protected application. #### Skipping application & code modeling Compiler solutions, depending on the exact approach, have to reconstruct and model a lot of information about the application they protect. This differentiator again leads to several (dis)advantages across our two groups. In the table below, benefits of the modeling are a “pro” for compiler solutions. **Wrappers** **Compiler-basedMore likely to support new technologies** without requiring an update due to the library approach and the absence of insight into your application.Requires R&D and **updates** from the mobile security solution provider to maintain proper modeling of your app **when using new technologies**. Generally, no configuration needed (or even available) beyond expressing your intent, making it **more simple to apply**. This is possible because the superficial security controls do not have to care or know about the actual application internals. In a sense, this is similar to the no-code app development concept due to necessity; a lack of depth in understanding of the application structure requires any security control to be very broad and generic. **Configuration is typically necessary** to augment the solution’s understanding of the application it needs to protect. This ties back directly to the required deeper analysis and modeling. By **not going to the same level of depth as** a compiler-based solution, **attackers** are not forced to either! **Example:** The concept of [‘code obfuscation’](https://www.guardsquare.com/what-is-code-obfuscation) is a set of techniques used to harden other controls or prevent IP theft in itself. Library solutions claiming this capability have to resort to blanket code encryption; they wrap the application code in a thin encryption layer. The packer here can be unpacked. Conceptual **availability of the same abstractions, tools and techniques as reverse engineers.** **Example:** Code obfuscation fundamentally removes or changes semantic information in the code, changes and shuffles instructions, control and data flow, etc. The transformations can often not be reversed or force the use of complex tools and techniques to approximate the original input. When to use a wrappers vs. compiler-based solution -------------------------------------------------- Overall, we’ve learned that app wrappers can potentially be a bit easier to set up and would probably have a smaller impact on your development flow. In addition, the reduced complexity and vendor R&D requirements should make them the cheaper solution. However, after a deeper look, it’s clear that these wins are only possible because of the many shortcuts taken with the library approach. While this would often be a net positive, this reasoning doesn’t apply to [mobile application security](https://www.guardsquare.com/what-is-mobile-app-security) at all! So when can you use this approach to protect your mobile application? It’s a solid first step if your app is built with technology that no compiler-based solution supports yet. In addition, if your app is temporary (used for events, or various one-off instances) and the threat model allows for it, you could consider wrapping your application. To summarize: Though it may seem counterintuitive, some complexity is actually a good thing for mobile application security. Avoiding it by design puts you at a fundamental disadvantage because it leaves your defense inherently lacking the depth it needs in a fast evolving cat and mouse game. Tag(s): [Protection](https://www.guardsquare.com/blog/tag/protection) , [Dexguard](https://www.guardsquare.com/blog/tag/dexguard) , [iXGuard](https://www.guardsquare.com/blog/tag/ixguard) , [Thought leadership](https://www.guardsquare.com/blog/tag/thought-leadership)[](https://www.guardsquare.com/report/owasp-mobile-top-10-security-risks-mobile-application-security-verification-standard) -------------------------------------------------------------------------------- title: "What is Runtime Application Self-Protection (RASP)? | Guardsquare" description: "RASP security (runtime application self-protection) enables mobile apps to defend against live attacks. Explore RASP Android and iOS solutions." source: "https://www.guardsquare.com/runtime-application-self-protection-rasp" -------------------------------------------------------------------------------- Runtime Application Self-Protection (RASP)**Mobile Security** ============================================================= RASP (runtime application self-protection) security enables iOS and Android mobile apps to monitor for suspicious behavior at runtime. When a runtime threat is detected, the RASP features help defend against threat actors attempting to tamper with your app or perform a dynamic analysis. [Connect with an expert](https://www.guardsquare.com/request-pricing) What are **RASP solutions**? ---------------------------- RASP solutions are security tools designed to protect applications at runtime by identifying and allowing you to take action against security threats and attacks. Unlike traditional security measures that focus on network or perimeter defense, RASP operates directly within the application itself. What is **dynamic analysis and why is it a threat?** ---------------------------------------------------- At runtime, threat actors can employ a variety of techniques to analyze and modify the app. Today, it is easier than ever before for a malicious user to deploy various techniques like jailbreaking, rooting, hooking, and more in order to steal decryption keys, intercept communication to servers, and more. Threat actors tamper with mobile apps for a variety of ends, such as to unlock hidden or premium functions, repackage apps to steal confidential data or learn more about the application at runtime to support reverse engineering attempts. Protection against runtime attacks helps to prevent these outcomes, preserving your app’s integrity and your brand’s reputation. iPhone runtime application self protection ------------------------------------------ iPhone Runtime Application Self Protection (RASP) is a crucial security measure that helps safeguard iOS applications against runtime threats, such as code injection, reverse engineering, and tampering. Unlike traditional security measures that focus on perimeter defenses, iOS runtime application self protection operates within the app itself, continuously monitoring and responding to suspicious activity in real-time. In iOS app development, integrating iPhone runtime application self protection ensures that applications can detect and mitigate threats dynamically, preventing attackers from exploiting vulnerabilities while the app is running. Key techniques include jailbreak detection, runtime integrity checks, obfuscation, and real-time threat analytics. These measures help developers enhance app security, protect sensitive data, and comply with industry regulations, making RASP an essential component of modern iOS security strategies. Android runtime application self protection ------------------------------------------- Android Runtime Application Self Protection (RASP) is a critical security mechanism designed to safeguard Android applications against real-time threats such as reverse engineering, tampering, and malware injection. Unlike traditional security approaches that rely on external defenses, RASP Android operates within the app, actively monitoring and responding to potential attacks during runtime. In Android app development, implementing Android runtime protection helps ensure app integrity by leveraging techniques such as root detection, code obfuscation, runtime integrity checks, and behavioral analysis. These security measures prevent unauthorized modifications, data breaches, and other malicious activities, making RASP Android a vital component in building secure and resilient applications. Why **RASP** security solutions are needed ------------------------------------------ Research shows that despite developers' priorities, mobile apps still aren't secure enough. [Read the Report](https://www.guardsquare.com/state-of-mobile-application-security-report) * 81%** of developers believe iOS standard security isn't sufficient.** * 84%** of developers believe Android standard security isn't sufficient.** * 96%** of developers still rely on operating system security.** * 36%** of apps include anti-tampering security measures.** How RASP security **prevents tampering** ---------------------------------------- Runtime application self-protection implementations monitor both the app and the environment it runs within to detect threats like jailbroken or rooted devices, function hooking attempts and more. When these threats are detected, RASP mobile security implementations respond with pre-programmed actions, like terminating the user’s session, displaying a warning message or limiting functionality. Resetting the clock to attackers with **every build** ----------------------------------------------------- Guardsquare’s polymorphic approach ensures that every app’s build comes with a unique combination of check locations and exact checks, as every RASP integrity can be validated with a diverse palette of specific checks. And as an app developer you have full control over which parts of your app not to touch, or to touch more aggressively. For additional protection, code hardening is automatically applied to all inject locations. **Security for every stage** of the mobile app lifecycle. --------------------------------------------------------- Too often delayed to the end of the development lifecycle, security needs to be considered right from the start. As your app development progresses, testing, feedback and monitoring helps you to ensure the highest possible level of security. **DevelopProtectTestMonitor** ### Develop [Mobile app security](https://www.guardsquare.com/what-is-mobile-app-security) is most effective when it’s considered from the outset of the development lifecycle, which includes making informed design choices, following best practices as well as early rounds of testing and refinement. Ultimately, engaging in secure software development practices identifies security risks early, when they’re quick and cheap to fix, rather than after deployment.[](https://www.guardsquare.com/report/owasp-mobile-top-10-security-risks-mobile-application-security-verification-standard) -------------------------------------------------------------------------------- title: "What is Code Obfuscation? | Guardsquare" description: "What is code obfuscation and how can it be used to make data more difficult for hackers to understand? Learn more about obfuscation in mobile apps." source: "https://www.guardsquare.com/what-is-code-obfuscation" -------------------------------------------------------------------------------- What is **code obfuscation?** ============================= Code obfuscation prevents any unauthorized party from accessing and gaining insight into the logic of an application, which prevents the attacker from extracting data, tampering with code, exploiting vulnerabilities, and more. The **Problem** --------------- Mobile applications can be reverse engineered using readily available disassemblers and/or decompilers, making it easy for hackers to access and analyze the source code of your applications. Hackers can then: * Steal intellectual property & clone applications * Extract sensitive information & harvest credentials * Identify vulnerabilities * Add malicious code to apps & repackage them Data of a sensitive nature may include; valuable intellectual property (such as custom algorithms), authentication mechanisms, in-app payment mechanisms, keys (API keys, hardcoded encryption keys etc.), credentials (database passwords etc.), the logic behind server communication, and much more. The **Solution:** Code Obfuscation ---------------------------------- **Code Obfuscation** is the practice of changing data and code to make it more difficult for attackers to read, understand, decompile, or disassemble. This is done by transforming the application’s code into an equally functional but less readable form. This helps to protect intellectual property and prevent reverse engineering.Application developers must harden the code at various layers. This is the only way to achieve the level of protection necessary to safeguard sensitive data and property in mobile applications. Obfuscation is part of a broader mobile application shielding strategy.Application shielding is a broad term for the process of making it more difficult for hackers to reverse engineer or modify an app. There are various techniques that can be used for application shielding, including code obfuscation and other [code hardening](https://www.guardsquare.com/code-hardening) techniques, as well as [runtime mobile application self-protection](https://www.guardsquare.com/runtime-application-self-protection-rasp) (RASP). Why use **code obfuscation?** ----------------------------- All of this is undertaken without altering the function of the code or the end user experience in a meaningful way. ### Code obfuscation strategies include: * Renaming classes, fields, methods, libraries etc. * Altering the structure of the code * Transforming arithmetic and logical expressions * Encryption of strings, classes etc. * Removing certain metadata * Hiding calls to sensitive APIs, and more Mobile application **obfuscation** prevents hacking --------------------------------------------------- **Code obfuscation** is a technique of mobile app protection that is used to enhance the security of the software by making it more resistant to reverse engineering and unauthorized modifications. The goal is to delay hackers attempting to understand how the code works. Ready to see how code obfuscation can **better secure your mobile applications?** --------------------------------------------------------------------------------- [Request pricing](https://www.guardsquare.com/request-pricing) **Types** of obfuscated code ---------------------------- There are several techniques available today to obfuscate code. These include:**Name obfuscation** The replacement of readable names in the code by difficult to decipher alternatives **Control flow obfuscation** The modification of the logical structure of the code to make it less predictable and traceable **Arithmetic obfuscation** The conversion of simple arithmetic and logical expressions into complex equivalents **Code virtualization** The transformation of method implementation into instructions for randomly generated virtual machines[](https://www.guardsquare.com/report/owasp-mobile-top-10-security-risks-mobile-application-security-verification-standard) -------------------------------------------------------------------------------- title: "Mobile App Security Threat Defense | ThreatCast | Guardsquare" description: "Guardsquare ThreatCast lets DexGuard and iXGuard users monitor threats in real-time, adapt security configurations, and protect their apps. Learn more." source: "https://www.guardsquare.com/threatcast-mobile-threat-defense" -------------------------------------------------------------------------------- MONITOR. IDENTIFY. ACT **Stop threats at their outset** **with real-time mobile app threat monitoring** ================================================================================ [Connect with an expert](https://www.guardsquare.com/request-pricing)[Download the ThreatCast fact sheet](https://www.guardsquare.com/factsheet-threatcast) **ThreatCast** ### **Limit the impact of an attack** **with real-time threat detection** * Minimize risk with clear, real-time visibility into your global threat landscape. * Stay ahead of malicious actors with precise detection of runtime threats. * Gain real-world validation of your RASP checks and incorporate insights into app development. ##### Actionable security intelligence Integrate security findings into future app development by identifying suspicious users and analyzing their activity. ##### Single-click integration Augment Guardsquare's protection features with zero config real-time threat monitoring and gain real-world insights. ##### Global threat trends Understand emerging attack patterns — like a spike in dynamic instrumentation or jailbreak variants — before they become mainstream. ### **Analyze attack details to prevent current and future threats** Developers can analyze threat actors’ attempts at reverse engineering and tampering to identify common attack vectors. Set custom alerts and actions to become aware of threat events as they occur and respond **before** a breach occurs. Add client-side protection to Threatcast ### **Verify it's your app** **with mobile attestation** * Secure your API endpoints with runtime protection that verifies the authenticity of apps interacting with your backend. * Ensure apps are genuine and their devices are operating in trusted environments to avoid API abuse. * Create and define security policies that automatically block bots and scripts from accessing your application. * Leverage continuous updates from the server-side to block attackers with the latest detections, without requiring an app update. [Learn more about attestation](https://www.guardsquare.com/introducing-mobile-app-attestation) **How** ThreatCast works ------------------------ The Detection #### A live attack is detected by ThreatCast Malicious activity like resigning, code tampering, repackaging, accessibility abuse, or other runtime threats are detected by RASP and securely sent to the ThreatCast server in real-time. By relying on ThreatCast data reporting, detailed evidence is collected without compromising the protection of your application. The Analysis #### Understand the threat Threat reports deliver incident transparency, including detailed reasons why a detection was triggered, and a clear explanation of the risk. Reports include information on the alterations made to your application or on anomalies detected on the device. The Response #### Prevent malicious attacks ThreatCast's easy data forwarding capabilities allow you to incorporate threat detections into your own SIEM or fraud detection system, providing data enrichment that can block attackers across device or system boundaries. Combined with self-protections embedded within your application, ThreatCast allows you to set up a comprehensive threat reaction strategy that suits your application's needs.Looking for an even more flexible reaction strategy? Have a look at our [attestation solution.](https://www.guardsquare.com/introducing-mobile-app-attestation) **Surface attackers** ThreatCast's data insights allow you to separate less impactful detections from severe reverse engineering or repackaging attempts. By combining multiple monitoring techniques, Threatcast helps to identify malicious users of your application. **Comprehensive security** for mobile applications -------------------------------------------------- Explore our other powerful products like uncompromising protection and security testing to extend your mobile app security across the entire dev lifecycle. ### DexGuard **ANDROID PROTECTION** **Uncompromising protection** for Android mobile apps and SDKs -------------------------------------------------------------- Secure native Android and cross-platform apps and SDKs with DexGuard, offering multilayered, polymorphic obfuscation and built-in runtime application self-protection (RASP). [Learn more about DexGuard](https://www.guardsquare.com/dexguard)**iXGuardiOS PROTECTION** Secure native iOS and cross-platform apps and SDKs with iXGuard, offering multilayered, polymorphic obfuscation and built-in runtime application self-protection (RASP). [Learn more about iXGuard](https://www.guardsquare.com/ixguard)**AppSweepSECURITY TESTING** Find and address security issues in Android and iOS mobile apps and SDKs with AppSweep, our app security testing product. Designed for developers, AppSweep scales to meet enterprise needs. [Learn more about AppSweep](https://www.guardsquare.com/appsweep-mobile-application-security-testing) Discover how Guardsquare provides industry-leading **visibility for Android, iOS, and cross-platform apps** ----------------------------------------------------------------------------------------------------------- [Request pricing](https://www.guardsquare.com/request-pricing) **ThreatCast** TL;DR -------------------- **What is ThreatCast?** Threatcast is a mobile application threat monitoring solution that provides real-time visibility into threats from devices running your application so organizations can understand where reverse engineering efforts are coming from and the intended attack targets. By integrating custom webhooks, teams can consume insights by integrating them into a SIEM tool, or as part of a fraud or anti-cheat system. **How does ThreatCast enhance mobile app security?** ThreatCast augments the mobile app security capabilities of DexGuard and iXGuard by providing real-time threat data of your application. Identified threats can be relayed to developers from security analysts, and data from emerging threats is incorporated into your development cycle to prepare your application against future threats. **What is active threat monitoring?** Mobile application threat monitoring is a specialized practice of observing data and signals from a device or app to identify potential security threats. In a mobile application security context, this can include detecting occurrences of tampering, such as failed environment checks, API requests not originating from a trusted source, bot activity, code tampering, such as hooking, or invalid code signing. **Can ThreatCast help with compliance or regulatory requirements?** ThreatCast monitors threat activity in your mobile application and integrates with your existing SIEM system to deliver a unified view of security threats, making it easier for your team to maintain compliance. **Is ThreatCast compatible with both Android and iOS platforms?** ThreatCast is fully compatible with Android and iOS platforms. **How does ThreatCast protect against mobile app fraud and data breaches?** ThreatCast’s ability to provide immediate, context-rich insights into runtime integrity violations enriches anti-fraud strategy and enables institutions to swiftly and more accurately detect and mitigate threats before they escalate. By leveraging this data, you can dynamically and proactively adjust your detection and mitigation approach, build richer user segmentation profiles while ensuring optimal user experience, and collaborate more effectively across departments and with external partners. **Why is threat monitoring important?** Mobile application threat monitoring can be useful for assessing the significance of the threat landscape for your mobile application. It can draw attention to, and provide more insight into, the types and targets of attacks users may be performing. In certain scenarios, it can also be used to refine and target protections, block users or flag potential for fraud. -------------------------------------------------------------------------------- title: "DexGuard Android Application Security | Guardsquare" description: "DexGuard provides industry-leading protection for Android apps. Discover how to protect your intellectual property and prevent the extraction of sensitive data." source: "https://www.guardsquare.com/dexguard" -------------------------------------------------------------------------------- **Uncompromising** **Android app protection** ============================================= [**Connect with an expert**](https://www.guardsquare.com/request-pricing)[**Download the DexGuard fact sheet**](https://www.guardsquare.com/factsheet-dexguard) **DexGuard** ### **Defend against static analysis** **Apply in-depth protection against reverse engineering. Layered techniques such as data encryption, control flow obfuscation, code virtualization and name obfuscation keep logic hidden.** * **Protect your IP and prevent extraction of secrets and sensitive information** * **Hide sensitive code related to authentication, transactions, and in-app purchases** * **Prevent exposure of backend APIs and request logic** ### **Counter dynamic analysis** **Prevent runtime tampering and inspection. Ensure continuous integrity of your code and its execution environment.** * **Block function hooks, dynamic instrumentation, and other code changes.** * **Act on tampered system libraries, emulators, virtual environments, and root privileges.** * **Defend against overlays, a11y abuse, and other malware techniques.** **Supported technologies** -------------------------- **How DexGuard works** ---------------------- **Polymorphic, compiler-based approach** #### **Comprehensive and evolving security** **Having defenses injected and applied during code compilation avoids the common pitfalls of SDK-based protection (i.e., “wrappers”).** **DexGuard applies polymorphic obfuscation techniques and automatically injects endless variations of integrity checks throughout your existing code. No two protected builds ever look the same.** * **Reset the clock on reverse engineering, rendering any gained knowledge useless with each app release.** * **Conceal the boundaries between your application logic and the protection code for reinforced security.** * **Unique protections with every build ensure that lessons from attacking other applications don't apply to your app.** **Mutually reinforcing protection layers** #### A force multiplier for your mobile app’s security **DexGuard’s multi-layered defenses provide robust Android mobile app protection against static and dynamic analysis.** * **Overlapping obfuscation layers reinforce each other. After code semantics are stripped and logic is obfuscated, the app can be virtualized and encrypted.** * **Obfuscated RASP checks verify environment integrity. These checks are then verified by other code integrity RASP checks.** * **Malicious inspection and modification of code is prevented by ensuring the environment has normal privileges, is free of debuggers, and is an actual physical device.** **Highest level of protection, in less than a day**Configure maximum protection with ease **Weaving multi-layered protection into your existing application logic historically required detailed insight into your application as well as fine-grained configuration capabilities.** **Guardsquare's unique guided workflow reduces this process into two simple steps, and is proven to take less than a day.** * **DexGuard automatically collects all the required application information.** * **Simplify your deployment with intuitive configuration assistance.** [**Learn more about our guided workflow**](https://www.guardsquare.com/mobile-app-protection-guided-workflow) **Comprehensive security for mobile applications** -------------------------------------------------- **Explore our other powerful products like threat monitoring, security testing, and attestation to extend your mobile app security across the entire dev lifecycle.** ### **ThreatCast** **Real-time threat monitoring** ------------------------------- **Gain visibility into vulnerabilities and suspicious activity and adapt your security configuration to face the constantly evolving threat landscape.** [**Learn more about ThreatCast**](https://www.guardsquare.com/threatcast-mobile-threat-defense)**AppSweepSECURITY TESTING** **Find and address security issues in Android and iOS mobile apps and SDKs with AppSweep, our app security testing product. Designed for developers, AppSweep scales to meet enterprise needs.** [**Learn more about AppSweep**](https://www.guardsquare.com/appsweep-mobile-application-security-testing)**App AttestationTRUST, VERIFIED.** **Ensure the app interacting with your APIs at runtime is authentic, untampered and safe to trust. Detect real-time threats and enforce dynamic security policies, automatically blocking unauthorized access based on aggregated threat intelligence.** [**Learn more about app attestation**](https://www.guardsquare.com/introducing-mobile-app-attestation) **Responsive support** ---------------------- **Get technical assistance from the same people who built your mobile app security solution.Choose the level of support that best suits your needs.** ##### **Basic support** **Rely on the Guardsquare team for bug fixes and setup support at no additional cost.** * **Installation and setup support** * **Bug fixes** * **Response within 3 business days** * **Email support** ##### **Gold support** **Gain expert-level access to the Guardsquare knowledge base as well as executive technical and business review.** * **Installation and setup support** * **Bug fixes** * **Project-specific support** * **Configuration optimization** * **Response within 1 business day** * **Email and phone support** **\*Add Gold support to any Guardsquare package.** **Discover how Guardsquare provides industry-leading protection for Android mobile apps** ----------------------------------------------------------------------------------------- [**Request pricing**](https://www.guardsquare.com/request-pricing) **DexGuard TL;DR** ------------------ **What is DexGuard?** **DexGuard is Guardsquare’s mobile app protection product, built specifically for Android applications.** **How does DexGuard enhance mobile app security for Android?** **DexGuard protects against reverse engineering, tampering, and other sophisticated mobile app threats through a combination of code-hardening (multi-layered obfuscation and encryption techniques), automated runtime application self protection (RASP) checks, and built-in malware defenses.** **Can DexGuard help with compliance or regulatory requirements?** **DexGuard establishes comprehensive mobile app protections that can help organizations meet compliance and regulatory goals. This includes requirements for data privacy (GDPR, CCPA, LGPD), financial services (PSD2, PCI), healthcare (FDA, EU-MDR), and more.** **Is DexGuard compatible with Android Studio and Gradle?** **DexGuard is compatible with both Android Studio and Gradle. Adding it to your project is easy and allows for a transparent integration with your build.** **Can DexGuard protect apps downloaded from Google Play?** **DexGuard is designed to protect applications downloaded from the Google Play store.** **Why is mobile app protection important?** **In-depth mobile application security must include layers of protection to defend against the ever-evolving tools and techniques employed by attacks in the wild. As a compiler-based tool, DexGuard provides more robust protection than app shielding or wrapper tools.** **What is the difference between DexGuard and iXGuard?** **DexGuard and iXGuard are both part of Guardsquare’s mobile app protection tool offerings. DexGuard is our product built specifically for Android applications and iXGuard is our product built for iOS applications. Conceptually, the products are very similar and protect against roughly the same threats. The primary difference is specific to the technology differences in Android vs iOS apps.** -------------------------------------------------------------------------------- title: "iXGuard iOS App Security and Obfuscation | Guardsquare" description: "iXGuard is a leader in iOS app security, offering advanced runtime application self-protection, encryption, and obfuscation capabilities. Learn more." source: "https://www.guardsquare.com/ixguard" -------------------------------------------------------------------------------- **Uncompromising** **iOS app protection** ========================================= [Connect with an expert](https://www.guardsquare.com/request-pricing)[Download the iXGuard fact sheet](https://www.guardsquare.com/factsheet-ixguard) **iXGuard** ### **Defend against static analysis** Apply in-depth protection against reverse engineering. Layered techniques such as data encryption, control flow obfuscation, code virtualization and name obfuscation keep logic hidden. * Protect your IP and prevent extraction of secrets and sensitive information * Hide sensitive code related to authentication, transactions, and in-app purchases. * Prevent exposure of backend APIs and request logic. ### **Counter dynamic analysis** Prevent runtime tampering and inspection. Ensure continuous integrity of your code and its execution environment. * Block function hooks, dynamic instrumentation, and other code changes. * Act on tampered system libraries, emulators, virtual environments, and root privileges. * Defend against overlays, a11y abuse, and other malware techniques. Supported technologies ---------------------- **How** **iXGuard works** ------------------------- Polymorphic, compiler-based approach #### Comprehensive and evolving security Having defenses injected and applied during code compilation avoids the common pitfalls of SDK-based protection (i.e., “wrappers”). iXGuard applies polymorphic obfuscation techniques and automatically injects endless variations of integrity checks throughout your existing code. No two protected builds ever look the same. * **Reset the clock on reverse engineering,** rendering any gained knowledge useless with each app release. * **Conceal the boundaries** between your application logic and the protection code for reinforced security. * **Unique protections with every build** ensure that lessons from attacking other applications don't apply to your app. Mutually reinforcing protection layers #### A force multiplier for your mobile app’s security DexGuard’s multi-layered defenses provide robust Android mobile app protection against static and dynamic analysis. * **Overlapping obfuscation layers reinforce each other.** After code semantics are stripped and logic is obfuscated, the app can be virtualized and encrypted. * **Obfuscated RASP checks verify environment integrity.** These checks are then verified by other code integrity RASP checks. * **Malicious inspection and modification of code is prevented** by ensuring the environment has normal privileges, is free of debuggers, and is an actual physical device. Highest level of protection, in less than a day #### Configure maximum protection with ease Weaving multi-layered protection into your existing application logic historically required detailed insight into your application as well as fine-grained configuration capabilities. Guardsquare's unique guided workflow reduces this process into two simple steps, and is proven to take less than a day. * iXGuard automatically collects all the required application information. * Simplify your deployment with intuitive configuration assistance. [Learn more about our guided workflow](https://www.guardsquare.com/mobile-app-protection-guided-workflow) **Comprehensive security** for mobile applications -------------------------------------------------- Explore our other powerful products like threat monitoring, security testing, and attestation to extend your mobile app security across the entire dev lifecycle. ### ThreatCast **ANDROID & iOS** Real-time **threat monitoring** ------------------------------- Gain visibility into vulnerabilities and suspicious activity and adapt your security configuration to face the constantly evolving threat landscape. [Learn more about ThreatCast](https://www.guardsquare.com/threatcast-mobile-threat-defense)**AppSweepSECURITY TESTING** Find and address security issues in Android and iOS mobile apps and SDKs with AppSweep, our app security testing product. Designed for developers, AppSweep scales to meet enterprise needs. [Learn more about AppSweep](https://www.guardsquare.com/appsweep-mobile-application-security-testing)**App AttestationTRUST, VERIFIED.** Ensure the app interacting with your APIs at runtime is authentic, untampered and safe to trust. Detect real-time threats and enforce dynamic security policies, automatically blocking unauthorized access based on aggregated threat intelligence. [Learn more about mobile attestation](https://www.guardsquare.com/introducing-mobile-app-attestation) Responsive **support** ---------------------- Get technical assistance from the same people who built your mobile app security solution.Choose the level of support that best suits your needs. ##### Basic support Rely on the Guardsquare team for bug fixes and setup support at no additional cost. * Installation and setup support * Bug fixes * Response within 3 business days * Email support ##### Gold support Gain expert-level access to the Guardsquare knowledge base as well as executive technical and business review. * Installation and setup support * Bug fixes * Project-specific support * Configuration optimization * Response within 1 business day * Email and phone support **\*Add Gold support to any Guardsquare package.** Discover how iXGuard provides industry-leading **protection for iOS and cross-platform mobile apps** ---------------------------------------------------------------------------------------------------- [Request pricing](https://www.guardsquare.com/request-pricing) **iXGuard** TL;DR ----------------- **What is iXGuard** iXGuard is Guardsquare’s mobile app protection product, built specifically for iOS applications. **How does iXGuard enhance mobile app security for iOS?** iXGuard protects against reverse engineering, tampering, and other sophisticated mobile app threats through a combination of code-hardening (multi-layered obfuscation and encryption techniques), automated runtime application self protection (RASP) checks, and built-in malware defenses. **Can iXGuard help with compliance or regulatory requirements?** iXGuard establishes comprehensive mobile app protections that can help organizations meet compliance and regulatory goals. This includes requirements for data privacy (GDPR, CCPA, LGPD), financial services (PSD2, PCI), healthcare (FDA, EU-MDR), and more. **Which iOS threats does iXGuard defend against?** iXGuard defends against static analysis to ensure your code will be as resistant to reverse engineering attacks. It also protects against dynamic analysis to prevent threat actors from tampering with apps at runtime. This includes RASP checks like jailbreak detection, debugger detection, repackaging detection, code tracing detection, and hook detection. **Does iXGuard work with Swift and Objective-C?** iXGuard is designed to protect both native (Objective-C, Swift) and cross- platform (e.g., Unity, Cordova, Ionic, Flutter, React Native) iOS apps and SDKs. **Why is mobile app protection important?** In-depth mobile application security must include layers of protection to defend against the ever-evolving tools and techniques used by attacks in the wild. As a compiler-based tool, iXGuard provides more robust protection than app shielding or wrapper tools. **What is the difference between DexGuard and iXGuard?** DexGuard and iXGuard are both part of Guardsquare’s mobile app protection tool offerings. DexGuard is our product built specifically for Android applications and iXGuard is our product built for iOS applications. Conceptually, the products are very similar and protect against roughly the same threats. The primary difference is specific to the technology differences in Android vs iOS apps. -------------------------------------------------------------------------------- title: "Mobile Application Security Testing | AppSweep" description: "AppSweep, a mobile app security testing tool that finds security issues in your apps & SDKs, with actionable insights to quickly resolve security risks." source: "https://www.guardsquare.com/appsweep-mobile-application-security-testing" -------------------------------------------------------------------------------- **Security testing** **built for mobile** ========================================= [Connect with an expert](https://www.guardsquare.com/request-pricing)[Download the AppSweep fact sheet](https://www.guardsquare.com/fact-sheet/appsweep?hsCtaAttrib=190183465385) **AppSweep** ### **Find security issues in mobile apps quickly** Leverage AppSweep’s actionable insights, which go beyond advanced pattern matching, to fix security issues early in the development process. * Multi-analysis mobile app security testing (static and interactive) * Prioritize vulnerabilities according to OWASP MASVS * Continuous CLI integration into existing DevOps pipelines ##### Testing built for mobile Mobile apps have unique risks and AppSweep precisely identifies these threats and provides relevant, actionable recommendations to fix security issues rapidly. ##### Designed for developers With an intuitive UI, navigate easily through key findings and easily integrate mobile app security testing in DevOps toolchains. ##### Security standards, simplified By using OWASP industry standards like [MASTG](https://mas.owasp.org/MASTG/), to group security testing results, AppSweep empowers teams to improve security workflows and helps developers to find and fix issues faster. **How** **AppSweep works** -------------------------- Shift security left with seamless integration #### The earlier a security issue is found, the cheaper it is to fix Developers can set up automated scanning of apps by directly integrating the AppSweep CLI into their existing CI pipelines such as Bitrise, Fastlane, Github, Jenkins, and more, to detect issues during development. AppSweep groups findings according to OWASP MASVS for clear vulnerability classification, prioritization, and remediation, enabling developers to resolve security issues quickly. With fast and easy integration, AppSweep is the most efficient way to shift left. Unprecedented accuracy #### AppSweep allows your team to focus on the most relevant and actionable security issues Beyond common pattern matching-based approaches, AppSweep performs in-depth code analysis. Findings are backed by advanced control and data flow analysis and optionally augmented further through interactive runtime testing. * **State-of-the-art taint analysis** * **Proven ProGuard reachability and dead code tracking** * **Strong value reconstruction and propagation algorithms** Do more with AppSweep Enterprise #### AppSweep Enterprise provides enhanced controls and capabilities, making it easier to share MAST capabilities across teams of any size. * **Extended integration:** Integrating AppSweep's extended CLI allows you to easily export and integrate more detailed findings. This feature allows teams to collectively review issues, track trends, and reference performance metrics. * **Reachability analysis:** Focus remediation efforts on relevant issues by excluding findings from unreachable parts of the code. * **Scales for enterprise:** AppSweep Enterprise supports the upload of larger apps; you can define automated data retention policies to ensure collected data complies with your company policies. Built for **developers,** scales effortlessly --------------------------------------------- ##### AppSweep For individual developers or teams looking to add mobile application security testing to their development process. * Unlimited scans of Android and iOS apps * Unlimited team members * Multi-analysis (static application security testing and interactive application security testing) * CLI for continuous integration (CI) * Alignment with OWASP MASVS categories * Downloadable PDF report of findings [Connect with an expert](https://www.guardsquare.com/request-pricing?utm_campaign=Mobile AppSec Testing&utm_source=AppSweep Website&appsweep_option=appsweep&hsCtaAttrib=190174985648) ##### AppSweep Enterprise For organizations that need to manage and scale mobile app security testing across development teams with seamless integration into the company IT architecture. * All the features of AppSweep plus... * Extended CLI for integration * Automated data retention policies * Support for larger apps * Filter out issues in 'dead code' [Connect with an expert](https://www.guardsquare.com/request-pricing?utm_campaign=Mobile AppSec Testing&utm_source=AppSweep Website&appsweep_option=enterprise&hsCtaAttrib=191802947175) **Comprehensive security** for mobile applications -------------------------------------------------- Explore our other powerful products like threat monitoring, and attestation to extend your mobile app security across the entire dev lifecycle ### DexGuard **ANDROID PROTECTION** **Uncompromising protection** for Android mobile apps and SDKs -------------------------------------------------------------- Secure native Android and cross-platform apps and SDKs with DexGuard, offering multilayered, polymorphic obfuscation and built-in runtime application self-protection (RASP). [Learn more about DexGuard](https://www.guardsquare.com/dexguard)**iXGuardiOS PROTECTION** Secure native iOS and cross-platform apps and SDKs with iXGuard, offering multilayered, polymorphic obfuscation and built-in runtime application self-protection (RASP). [Learn more about iXGuard](https://www.guardsquare.com/ixguard)**ThreatCastTHREAT MONITORING** Gain visibility into vulnerabilities and suspicious activity and adapt your security configuration to face the constantly evolving threat landscape. [Learn more about ThreatCast](https://www.guardsquare.com/threatcast-mobile-threat-defense) Discover how Guardsquare provides industry-leading **testing for mobile apps** ------------------------------------------------------------------------------ [Request pricing](https://www.guardsquare.com/request-pricing?utm_campaign=Mobile AppSec Testing&utm_source=AppSweep Website&appsweep_option=enterprise&hsCtaAttrib=191802947175) **AppSweep** TL;DR ------------------ **What is AppSweep?** AppSweep is a mobile application security testing product by Guardsquare that automates security checks with every build. Designed for developers and built for mobile apps, AppSweep enable enables teams to identify vulnerabilities early in the software development lifecycle and provides actionable recommendations to address them. With seamless CI/CD integration and support for OWASP MASVS, AppSweep helps development teams shift security left and ship secure apps faster. **How do you check if a mobile app is secure?** To check if a mobile app is secure, developers should perform a combination of static and dynamic security testing. This includes scanning for common vulnerabilities, insecure coding patterns, exposed secrets, weak encryption practices, and misconfigured permissions. Products like AppSweep simplify this process by automating the analysis of the Android and iOS app binary and flagging issues across categories like code obfuscation, data storage, network security, and cryptographic implementation. **What is mobile app security testing?** Mobile app security testing is the process of identifying vulnerabilities and weaknesses in a mobile application that could be exploited by attackers. It involves analyzing the app’s source code, configuration files, libraries, and network behavior. Security testing should follow standards like the OWASP Mobile Application Security Verification Standard (MASVS). AppSweep supports this by automatically categorizing findings according to MASVS and surfacing critical risks before the app reaches users. **Can AppSweep help with compliance or regulatory requirements?** Yes. AppSweep helps teams align with compliance and regulatory frameworks by identifying security issues mapped to MASVS categories. This is particularly useful for highly regulated industries such as financial services where security audits and trade association standards like the ones issued by PCI SSC demand secure software practices. AppSweep serves as an early step toward audit readiness and continuous security validation. **What types of vulnerabilities does AppSweep detect?** AppSweep identifies a broad range of vulnerabilities, including: * Insecure data storage (e.g., hardcoded credentials, plaintext files) * Weak encryption configurations * Debug logs in production builds * Improper TLS/SSL implementation * Code constructs vulnerable to reverse engineering * Exposure to tapjacking * Use of deprecated or vulnerable third-party libraries All findings are categorized by severity and aligned with OWASP MASVS categories to prioritize remediation. **How does AppSweep integrate with the development lifecycle?** AppSweep is designed to integrate directly into CI/CD pipelines via its Command Line Interface (CLI). Developers can trigger scans automatically with every build, pull results into their existing workflows, and track trends over time. Integration with popular build systems enables fast feedback loops, empowering developers to address issues without slowing down delivery. **Why is mobile app security testing important?** Mobile app security testing is crucial because mobile apps operate in untrusted environments and are frequent targets for reverse engineering, tampering, and data theft. A secure backend isn’t enough, the client-side must be hardened and tested regularly. Without proactive testing, vulnerabilities can lead to financial losses, data breaches, compliance failures, and reputational damage. Continuous security testing with tools like AppSweep ensures that mobile apps remain resilient against evolving threats throughout the development cycle. -------------------------------------------------------------------------------- title: "Multi-Layered Approach to Mobile App Defense | Guardsquare" description: "Defend your mobile apps from reverse engineering and tampering with multi-layered app security. Learn how to strengthen your mobile app defense." source: "https://www.guardsquare.com/blog/multi-layered-mobile-app-protection" -------------------------------------------------------------------------------- March 18, 2025 Mobile App Defense: A Multi-Layered App Security Approach ========================================================= Written by: Jija Bhattacharya - Product Marketing Manager How an attacker views your app ------------------------------ The rise of fake, modified mobile apps should serve as a wake-up call for companies and brands to reinforce their mobile app defense. Organizations must take proactive steps with mobile app defense to prevent attackers from reverse-engineering their applications, tampering with app logic, or studying proprietary intellectual property (IP). Protecting your IP means ensuring that no one can create unauthorized "enhanced" versions of your app, replicate proprietary algorithms, or extract key functions from your app or SDK. It also means preventing unauthorized modifications, access to, and use of, APIs, content, or sensitive IP. Security breaches highlight the serious consequences of neglecting [mobile application protection](https://www.guardsquare.com/what-is-mobile-application-protection). Attackers often begin by decompiling an app using readily available tools, allowing them to access its folder structure and source code. This makes identifying risks, and security gaps, and making unauthorized modifications easier. Strengthening your mobile app with a multi-layered app security approach is no longer optional, and it is essential to safeguarding your brand, users, and proprietary technology. #### The typical attack process: * [Decompiling](https://www.guardsquare.com/blog/four-phases-of-a-mobile-application-attack) the app – Using decompiler tools to retrieve the app’s source code. * Reverse engineering – Understanding the app’s logic and security implementations. * Modifying the code – Disabling security checks or injecting malicious code. * Recompiling and distributing the modified app – Creating a compromised version for exploitation. With a weak mobile app protection approach, such as applying a single layer of protection, the attacker can easily bypass security mechanisms and either change the application code logic or add his own malicious code to the application​​. This is why a multilayered protection approach is critical. #### What do we mean by "mobile app defense" and "multi-layered app security"? * Mobile app defense refers to the set of techniques, tools, and processes designed to protect an app against reverse engineering, tampering, instrumentation, and misuse at runtime. * Multi-layered app security means combining multiple complementary protection layers, such as obfuscation, string encryption, runtime checks, integrity verification, and anti-debugging, to form a resilient mobile app security defense. #### Why multi-layered app security is a nonnegotiable Now, let's consider the flaws in single-layer security approaches. A single-layer approach, such as simply wrapping the app in a security layer or relying on one method (e.g., root detection), may seem like a quick solution. However, attackers can often bypass individual protection mechanisms or find different techniques for achieving their goal. Remember do not rely on a single protection mechanism, for example: #### **Overreliance on any single protection feature** * Encrypting the entire code into one blob and then decrypting it at runtime may sound like a good idea. However, once the attacker figures out the decryption mechanism, they can retrieve the original code and access the underlying logic, rendering the entire approach ineffective. It's important to emphasize that techniques like code encryption can be part of an effective protection strategy for your mobile app. **The challenge is when they are used in isolation as the sole security measure. This nuance is crucial: the problem isn't the technique itself but the overreliance on a single layer of protection.** A competent security strategy requires multiple layers of protection, as no single technique can fully safeguard an application against attacks. When used in isolation, these techniques fall short because they create a single point of failure. Once an attacker breaks through one layer, they gain access to the app's logic and data. This is why multilayered security is essential. By incorporating multiple defenses, even if one layer is breached, others will still protect the app. What is a multilayered protection approach for mobile app defense? ------------------------------------------------------------------ From banking to social media to e-commerce, mobile apps handle a vast amount of personal data and provide access to essential services. This makes them prime targets for malicious intent. Securing the app at multiple levels is paramount to protecting your app and its users. A multilayered approach to [mobile app security](https://www.guardsquare.com/what-is-mobile-app-security) is a dynamic and strategic defense method that goes beyond simple encryption or obfuscation. In this blog, we'll delve into the importance of such an approach and explain how it works to thwart reverse engineering and tampering attempts by attackers. A multi-layered app security approach combines various techniques and protection layers to defend an application against malicious attacks. It is the backbone of effective mobile app defense. By using several different methods to secure your app, you can effectively reduce the chances of any single attack method succeeding. While no single security layer is foolproof, the combination of multiple techniques creates a strong security architecture that an attacker must bypass. To understand the effectiveness of a multilayered security approach, consider the analogy of a medieval castle. ​​Just as a castle relies on multiple layers of defense - a drawbridge, a moat, fortified walls, and watchtowers - mobile app security should integrate multiple protective techniques that work together to strengthen overall resilience. These layers may include [code obfuscation](https://www.guardsquare.com/what-is-code-obfuscation), string encryption, control flow obfuscation, and runtime protections, among others. While this is not an exhaustive list, Guardsquare’s dedicated Security Research team continuously refines and enhances security strategies to stay ahead of emerging threats. When an attacker attempts to reverse engineer an app, layered defenses create significant hurdles, requiring substantial time, effort, and resources to bypass. By disrupting the attacker’s workflow and increasing the complexity of reverse engineering, developers can significantly reduce the risk of successful exploitation, ensuring stronger protection for their applications. Multilayered protection against static analysis ----------------------------------------------- [Static analysis](https://www.guardsquare.com/blog/addressing-static-and-dynamic-attacks) debugs compiled code without running the application. Let’s explore the types of protection that can be incorporated into a mobile app and see how they work together. Please note the examples provided here are intentionally simplified to illustrate key security concepts clearly. In real-world applications, security measures are far more sophisticated, relying on advanced, multi-layered strategies to effectively protect against threats. Guardsquare’s solutions go well beyond these fundamental techniques, incorporating a diverse range of cutting-edge protections designed to provide robust and comprehensive protections. 1. One of the first layers of defense is obfuscating function and class names. Name obfuscation is the process of making the source code difficult to understand by transforming the code into a version that looks like a meaningless mess yet still functions correctly. This makes it much harder for an attacker to extract sensitive information from the app by reading through the code. Original Code: ``` public class UserAuthenticator { public boolean authenticate(String username, String password) { // Authentication logic }} ``` Obfuscated Code: ``` public class a { public boolean b(String c, String d) { // Authentication logic }}While helpful, AI-powered tools can infer function names and, in some cases, allow the attacker to defeat this basic protection. Thus, additional layers are necessary. ``` 2. Another common weakness in many mobile apps is the hardcoding of sensitive information, such as API keys, credentials, and tokens, directly in the code. Even if an app's code is obfuscated, these plain-text strings can still be exposed when an attacker decompiles the app. Encrypting strings ensures that critical information remains protected.This is where string encryption plays a vital role. By encrypting strings and decrypting them only at runtime, developers ensure that sensitive data is never exposed in plain text within the app’s code. Without Encryption: ``` String apiKey = "12345-ABCDE"; ``` ``` With Encryption:String encryptedKey = decrypt("fgdsf43y6sf3f4fs"); ``` 3. While obfuscating code and encrypting strings are essential, they don’t necessarily prevent attackers from understanding the logic of the app. Once attackers can analyze the flow of execution, they might be able to reverse engineer critical functionality. To prevent this, control flow obfuscation is used.Control flow obfuscation alters the code’s logical flow, introducing artificial loops, branches, and jumps that make it harder for an attacker to follow the original execution path. In simple terms, it takes a straightforward process and makes it look like a convoluted mess of code. This adds another layer of difficulty for reverse engineers trying to determine the app's core functionality. Before: ``` if (user.isAuthenticated()) { grantAccess();} else { denyAccess();} ``` After: ``` switch (someComplexCondition()) { case 1: grantAccess(); break; case 2: denyAccess(); break; default: logError(); break;} ``` 4. Eliminating direct method calls: Another step towards confusion Replacing direct function calls with indirect references hides method calls, making it harder to understand the app’s logic. Attackers typically look for specific methods and function calls when trying to reverse engineer an app. Method call hiding adds another layer of disarray by obfuscating method calls, making it difficult for attackers to track which functions are being executed.By hiding method calls or renaming methods to random characters, attackers will have a harder time understanding which functions are interacting with each other and how the app operates. This technique, when used in conjunction with control flow obfuscation and string encryption, ensures that reverse engineers can't easily deduce the app’s underlying logic. Before: ``` UserAuthenticator auth = new UserAuthenticator();auth.authenticate(username, password); ``` ``` Object result = callMethod("wfowo434#$3", username, password); ``` In this example, direct method calls are replaced with a generic proxy function (callMethod), which takes an obfuscated string identifier and parameters instead of referencing actual class or method names. Unlike standard reflection, the obfuscated identifier ("wfowo434#$3") does not directly correspond to the real method name. Instead, it is mapped internally within the code, making it significantly harder for attackers to reverse-engineer or identify the original function being invoked. Multilayered protection against dynamic analysis ------------------------------------------------ Even when static analysis tools fail to break down an app, attackers can still use dynamic analysis to attack a running application. Dynamic analysis allows attackers to observe how an app behaves when it’s executed, giving them an opportunity to manipulate or tamper with the app's runtime environment. How do they begin? Enter - [Debuggers](https://www.guardsquare.com/blog/debugging-your-protected-application-with-the-new-ixguard). A debugger is a tool that enables developers to analyze software code during execution, helping them identify and resolve issues in real time. However, attackers can also misuse debuggers to identify security gaps, bypass security measures, and manipulate app functionality for malicious purposes. To counter this, [Runtime Application Self-Protection (RASP)](https://www.guardsquare.com/runtime-application-self-protection-rasp) techniques are embedded directly into the app. RASP monitors the app's runtime behavior and detects any suspicious activity, such as attempts to tamper with the app's memory or bypass security mechanisms. RASP should ideally operate from within the app, making it harder for attackers to disable or circumvent it. Moreover, RASP can be implemented in a way that makes it difficult for attackers to identify the specific checks. Instead of relying on a single RASP thread or function, developers can distribute RASP checks throughout the entire app code. This increases the complexity of the app’s security and makes it more challenging for attackers to bypass it. #### Creating a controlled environment for dynamic analysis: 1. Modifying the system – Attackers alter the OS to observe and control the application’s execution. Most of the time, an attacker's first step is to use a [rooted or jailbroken](https://www.guardsquare.com/blog/what-rooting-and-jailbreaking) device, allowing them to read or tamper with any data stored at rest by the application. This is often a prerequisite for utilizing more advanced dynamic analysis tools. 2. Modifying application data – Changing the application’s data at rest or in process memory can alter the behavior of the application. Sometimes, applications store the status of premium features in local data storage without encryption. In such cases, an attacker can achieve their goal simply by modifying this file. If that's not possible, they will need to take the next step: modifying the application itself. 3. Modifying the application – Directly changing the app to observe and control the application’s execution. For instance, the attacker may use hooking or a debugger to trace the code execution and potentially alter the application's behavior. #### Strengthening runtime security with RASP * **Single RASP** **check** A single check can be easily disabled by an attacker, rendering it ineffective. * **Multiple reinforcing RASP checks** By embedding RASP checks directly into the user code rather than isolating them in separate functions, attackers face an exponentially greater challenge in bypassing security. This exponential difficulty arises because the checks are not just standalone barriers; they reinforce and interlock with each other. If an attacker identifies and attempts to disable a root check, an application resigning check might stop them. If they try bypassing that by tampering with system libraries, system library integrity will detect the manipulation. Any attempt to patch out a system integrity check could be thwarted by code checksumming, while attempts to hook into that check could trigger additional layers of detection. Each failed attack leads to another hurdle, creating a compounding effect where the time and effort required to bypass security measures increase dramatically. This layered, interdependent approach makes it significantly harder for attackers to disable even a single check, let alone compromise the entire app. The role of a compiler based approach in this layered strategy -------------------------------------------------------------- Compiler based approach plays a vital role in implementing effective code obfuscation. Guardsquare’s approach is analogous to how a compiler works, we operate on the code directly, rather than encapsulating the code with a simple layer of protection. Since compilers naturally regenerate an application's code, they provide an ideal framework for embedding security controls seamlessly. This capability supports advanced code analysis and transformation techniques, serving as a cornerstone of modern software protection. One of the biggest advantages of compiler-based obfuscation is its ability to introduce randomized variations in code semantics, structure, and placement with minimal effort from developers. This results in two major benefits: **The "reset the clock" effect** – Each new application version forces attackers to start their reverse-engineering efforts from scratch, which, after a point in time, becomes expensive in every aspect and, hence, futile. At Guardsquare, we refer to this phenomenon as [polymorphism](https://www.guardsquare.com/blog/why-resetting-the-clock-matters-for-mobile-app-security), meaning that the security measures change with each new app version. This dynamic strategy ensures that attackers can't rely on the same knowledge to tamper with the app over time. With every new build, the protection mechanism adapts, making reverse engineering significantly harder. **A vast, uniformly obfuscated "haystack"**—The idea behind "haystacking" comes from the proverb "finding a needle in a haystack." In the context of mobile app security, this means making it difficult for attackers to locate what they’re trying to protect in the first place. This involves two key aspects: hiding secrets and embedding protections. With the help of Guardsquare products, developers can obfuscate far more than just critical secrets; they can disguise other parts of the codebase as well, making it harder to distinguish sensitive elements from the rest. Similarly, RASP (Runtime Application Self-Protection) should not only be applied to high-value functions but distributed throughout the code to create additional layers of security. RASP checks are incorporated into the code during compilation. This comprehensive approach ensures that both the app’s defenses and its sensitive data remain deeply concealed, significantly increasing the effort required for an attacker to reverse-engineer the application. By utilizing a compiler based approach, developers can ensure that security mechanisms are not only deeply embedded but also evolve dynamically with each build. The much needed complexity of multi-layered app security -------------------------------------------------------- A multilayered approach to mobile app security is essential for protecting both the app and its users from reverse engineering and malicious attacks. By combining techniques like name obfuscation, string encryption, control flow obfuscation, and other obfuscation techniques complemented by runtime protection, all of which adapt with every software build, developers can create an app that is far harder to breach. The key takeaway is that it’s not enough to rely on a single layer of protection. As attackers grow more sophisticated, so must our security strategies. By implementing [multiple layers of defense](https://www.guardsquare.com/blog/fortress-your-app-with-multi-layered-code-obfuscation), we make it exponentially harder for attackers to succeed, protecting our apps, data, and user trust. Weaving these layers seamlessly into the app’s structure, developers can significantly increase the complexity of reverse engineering attempts, deterring attackers and securing sensitive application logic. Mobile app security is not just about adding protections. It’s about strategically layering them for maximum resilience. Just as a medieval castle architecture used to defend its owner, so does this modern security strategy for your mobile apps, and the stakes are equally high. [Contact us](https://www.guardsquare.com/request-pricing) to discuss your mobile app security strategy. Tag(s): [Android](https://www.guardsquare.com/blog/tag/android) , [iOS](https://www.guardsquare.com/blog/tag/ios) , [Protection](https://www.guardsquare.com/blog/tag/protection) , [Dexguard](https://www.guardsquare.com/blog/tag/dexguard) , [iXGuard](https://www.guardsquare.com/blog/tag/ixguard) -------------------------------------------------------------------------------- title: "Hardware-Backed Android Key Attestation Security | Guardsquare" description: "Hardware-backed key attestation helps developers confirm that a device’s OS hasn’t been compromised. Discover hardware attestation security for Android." source: "https://www.guardsquare.com/blog/hardware-backed-key-attestation-security-guardsquare" -------------------------------------------------------------------------------- February 11, 2025 Resetting the Clock for Polymorphic Mobile App Security ======================================================= Written by: Jija Bhattacharya - Product Marketing Manager In an age where mobile apps hold extensive sensitive data, securing the environment in which these apps operate is critical. [Mobile app security](https://www.guardsquare.com/what-is-mobile-app-security) encompasses multiple layers of protection, and one crucial aspect of the security is ensuring that the device running the app can be trusted and has not been tampered with. Hardware-backed key attestation is a mechanism that can play a role in protecting mobile apps by validating the integrity of the device and its environment. This blog explores what key attestation is, how it works, and its specific use cases in [mobile application protection](https://www.guardsquare.com/what-is-mobile-application-protection), especially from a security standpoint. **What** is hardware-backed key attestation? -------------------------------------------- Key attestation is an enabling feature of the Android ecosystem. It allows mobile applications to verify that the device's operating system, bootloader, and overall environment have not been tampered with. Android key attestation checks whether the device’s OS has been modified and ensures that the device is running trusted software directly from the hardware layer. [DexGuard](https://www.guardsquare.com/dexguard) recently introduced a feature called OS Integrity which builds upon this key attestation scheme. A key attestation implementation can extend or complement existing heuristic root detections. Heuristic root detections only check for signs of rooting or custom modifications in the application sandbox, while hardware key attestation involves data from the device’s Secure Element or Trusted Execution Environment. These techniques pull data from the device’s Secure Element or Trusted Execution Environment (TEE) to confirm the device’s integrity. The process involves verifying the device's bootloader, ensuring the authenticity of the device ROM. This enables additional, more strict verifications around the integrity of the device. This can be particularly helpful since many common rooting techniques on Android require unlocking the device bootloader. **How** does it work? --------------------- The process begins by leveraging the device's KeyStore, which stores cryptographic keys, to retrieve a certificate chain. This attestation certificate will contain information about the integrity of the bootloader, ensuring that the device has not been compromised. The verification checks several factors, including: 1. **Certificate chain verification:** The integrity of the certificates in the chain is verified to ensure they have not been revoked or tampered with. 2. **Root certificate verification:** Checks that the root certificate is trusted, coming from Google or a trusted third party, ensuring that the device has not been tampered with. **The importance** of key attestation for mobile app protection --------------------------------------------------------------- While key attestation offers robust security for mobile applications, it does come with trade-offs that app developers need to consider carefully. Here's how it [enhances mobile app security](https://www.guardsquare.com/blog/mobile-app-security-strategy-guide) and the challenges it may pose: **Real-world use cases** for hardware-backed key attestation ------------------------------------------------------------ Android key attestation provides critical security benefits across various industries and use cases. Below are examples where its application can be particularly impactful: 1. Point-of-sale systems are among the most significant beneficiaries of the strictness provided by hardware-backed key attestation. Ensuring that the environment handling payments and PIN entry is uncompromised is paramount for maintaining transactional security. Merchants using POS apps can reasonably be required to meet strict device system requirements to ensure compliance with security standards like PCI DSS and to protect against fraud or data breaches. By leveraging key attestation, developers can enforce a secure, tamper-resistant environment that inspires trust and enhances the reliability of POS systems. 2. For financial institutions and mobile payment applications, [protecting sensitive financial data](https://www.guardsquare.com/mobile-banking-finance-app-security) and preventing fraud is critical. In these cases, maintaining strict environment integrity ensures that devices running these apps are not tampered with and that security measures cannot be bypassed through device modifications. For example, a payment app requiring compliance with PCI DSS standards may utilize key attestation to guarantee the strictest levels of security for transactions. 3. [Security-focused SDKs](https://www.guardsquare.com/mobile-sdk-protection), such as those used for identity verification, can greatly benefit from implementing key attestation as part of their protection strategy. By verifying the integrity of the device's environment, these SDKs can ensure that identity assurances are provided only when the device is uncompromised. For devices that fail key attestation, indicating potential tampering or a compromised environment, the SDK can return an inconclusive or risky verdict, signaling that the identity verification process may be vulnerable to manipulation. This approach helps maintain the integrity of sensitive operations, such as authentication or fraud prevention, by prioritizing secure environments and flagging high-risk scenarios for further review. Strictness of key attestation: **challenges & trade-offs** ---------------------------------------------------------- While key attestation offers substantial security benefits, it also comes with trade-offs. On the one hand, key attestation provides strong security by ensuring that devices with modified bootloaders or custom ROMs fail integrity checks, preventing attackers from bypassing app protections. However, this level of strictness can inadvertently alienate non-malicious users who rely on custom ROMs for device personalization or updates. Similarly, certain OEMs may not implement trusted certificates (e.g., passed Google certification), causing their devices to fail key attestation by default unless a customized solution is employed to accommodate these non-certified devices. Additionally, older devices often lack support for hardware key attestation entirely, which can lead to failures if such checks are strictly enforced. For apps that need to maintain compatibility with legacy devices, these limitations must be carefully considered to strike a balance between security and usability. **A flexible approach** to achieve both security & a strong UX for consumer apps -------------------------------------------------------------------------------- Given the challenges and trade-offs, that doesn't mean that key attestation can't be useful for you. One beneficial approach to consider is enabling this scheme but utilizing server-side threat data collection to gain insight into when this detection triggers. In these cases, you can allow users to continue using your application but have insight on which users and devices are running your app on potentially untrusted devices. You can tailor the app experience or simply use this insight to help with fraud analysis and decision making. Guardsquare makes this possible by combining DexGuard with [ThreatCast](https://www.guardsquare.com/threatcast-mobile-threat-defense), giving you full visibility of the integrity of your users' devices. **Guardsquare** enables you to tailor security to your app’s need ----------------------------------------------------------------- A key attestation scheme, such as the one we implement with DexGuard’s OS integrity feature, provides a powerful tool for enhancing mobile app security by verifying the integrity of the device and its environment. It is a critical component for applications that handle sensitive data or need to comply with strict regulatory standards. However, its strictness can lead to impacts on your application UX, affecting non-malicious users who use custom ROMs or unlocked bootloaders for legitimate reasons. DexGuard offers you the flexibility to enable this feature in situations that best suit your security needs. App developers must carefully assess whether the trade-offs involved in implementing key attestation are appropriate for their specific use case. For apps where security is paramount, such as financial services or payment solutions, key attestation can be a useful layer. For more conservative use cases, enabling it in combination with [threat monitoring](https://www.guardsquare.com/threat-monitoring) can give you visibility without sacrificing UX. In the evolving landscape of mobile app security, key attestation offers a critical layer of protection that ensures devices remain trustworthy and secure, providing peace of mind to both developers and users alike. [Contact our experts today](https://www.guardsquare.com/request-pricing) to discover how Guardsquare can help you create the most secure version of your mobile app. Tag(s): [Android](https://www.guardsquare.com/blog/tag/android) , [Protection](https://www.guardsquare.com/blog/tag/protection) , [Financial services](https://www.guardsquare.com/blog/tag/financial-services) , [Dexguard](https://www.guardsquare.com/blog/tag/dexguard) , [Thought leadership](https://www.guardsquare.com/blog/tag/thought-leadership) , [App attestation](https://www.guardsquare.com/blog/tag/app-attestation) -------------------------------------------------------------------------------- title: "Protect Against Malware With Threat Monitoring | Guardsquare" description: "Discover how mobile app threat monitoring helps detect malware campaigns early, including new and evolving threats, to keep your mobile app secure." source: "https://www.guardsquare.com/blog/fight-malware-attacks-with-threat-monitoring" -------------------------------------------------------------------------------- September 9, 2025 Protect Against Evolving Malware Attacks with Threat Monitoring =============================================================== Written by: Sergio Castell - Security Researcher Historically, malware has posed a serious threat to mobile applications, ranging from targeting financial services applications (stealing customers’ credentials, credit card, and wallet data) or utilities like two-factor authentication applications (stealing OTP codes for account takeover). The trend is usually that common malware takes advantage of certain mobile OS features, accessibility services, and permissions in order to perform their initial infection and gain control over the features they target. But malware is continuously evolving. Threat actors come up with new and creative ways to both bypass known countermeasures already deployed against said common attacks and achieve greater privileges over the infected device or target application. In this post, we’ll explore how mobile app security teams can stay ahead of these evolving attacks through monitoring and early detection. We’ll also discuss various attack techniques, some of which, while individually known to the mobile security industry, pose significant risks when combined in advanced malware campaigns. Then, we will show how mobile app developers can help security teams by implementing a [multi-layered mobile app defense strategy](https://www.guardsquare.com/blog/multi-layered-mobile-app-protection). Monitor attacks as they happen ------------------------------ When a malware campaign begins, it’s only a matter of time before the [phishing work and fraud](https://www.guardsquare.com/blog/mobile-app-security-mitigates-fraud) start. Having advanced analytics that showcase malware attacks in real-time, including what security measures threat actors attempt to circumvent from an application, is crucial to understand the attack and any remediations that would be necessary before it becomes widespread. This kind of data can be easily collected by utilizing advanced [mobile app threat monitoring](https://www.guardsquare.com/threat-monitoring) capabilities in your application. For example, in April 2025, [ThreatCast](https://www.guardsquare.com/threatcast-mobile-threat-defense) observed a surge in malicious activity across certain countries, originating from specific financial mobile applications. During this spike, ThreatCast detected hook mechanisms targeting protected apps, from impacting several hundred to several thousand of users per day. This activity occurred alongside the use of accessibility services and a potential OS integrity failure affecting specific devices and OS versions. The graph below illustrates this surge in hook detection events in April, clearly linking the activity to the malware campaign. When a malware campaign begins to spread, and access to a sample isn’t immediately available, attributing specific behavior to a particular malware strand can be challenging. Despite this, ThreatCast users were still able to know, from the moment the attack started, what was happening. Even though ThreatCast users were unsure of the specific malware strand performing the attack, the techniques that were being used could be identified. Since ThreatCast can also link a given device’s activity to a user’s account, app developers were able to inform their users about the attack and temporarily limit their accounts as necessary if they were infected by the malware. App developers were also able to collect further information about the attack from these users, such as in which context the malware sideloading/phishing took place. This information is crucial in order to both understand and stop the malware campaign as soon as possible. Following an internal analysis, Guardsquare was able to correlate the spike in malicious activity to a new variant of the Godfather malware. Godfather is just one example of recent attacks in which malware relies on diversifying its techniques in an attempt to extract the maximum amount of data from its victims while attempting to remain undetected. When first reported by [Cyble](https://cyble.com/blog/godfather-malware-targets-500-banking-and-crypto-apps-worldwide/) back in November 2024, Godfather was already able to target 500 banks and crypto wallet applications with a classical accessibility and permission-based attack, along with the simulation of user actions on-screen. In this new variant, the malware gained the capability to create virtualized [copies of bank applications](https://www.guardsquare.com/blog/phishing-attacks-mobile-banking-apps) and steal user credentials from certain targeted banks in Turkey. It should be noted that Guardsquare customers have been protected from this new variant of Godfather since before the campaign started, thanks to our layered defenses and advanced detection capabilities, which have been present in our solutions for over two years. Just like in the case of Godfather, when malware evolves and gains new attack capabilities, ThreatCast users are not only able to know whether their application is being attacked, but by correlating the amount and types of events, they are able to know when the attack is happening, when it started, which users are being targeted, and with what kinds of attacks. Beyond monitoring: Implementing detections for evolving malware attack techniques --------------------------------------------------------------------------------- As we’ve seen with Godfather, mobile malware is not stagnant; it continues to change how it attacks high-value operations in applications. Monitoring malware trends can help developers understand the ways in which their applications need to be protected in order to achieve their desired level of protection and stay ahead of attacks. But what’s needed to get to that level of protection? Let’s build on the example of the recent Godfather variant to examine why evolving malware strains like Godfather succeed in extracting user data from unprotected or insufficiently protected mobile apps: * **Virtualized copies of targeted apps:** Godfather can make virtualized copies of the mobile applications it targets, running in a malware-controlled virtual environment. Within this virtual environment, the malware can control all variables, allowing it to manipulate [Android Java APIs](https://www.guardsquare.com/blog/hidden-mobile-app-security-risks-in-android-libraries-guardsquare) or hook into the Android Binder without root or additional privileges. This enables data manipulation and helps hide the malware’s traces by manipulating Android’s accessibility APIs. * **Targeted hooks:** Godfather relies on open-source hook frameworks like PineXposed, working at the application level without [tampering](https://www.guardsquare.com/blog/mobile-app-tampering) with the device or application binary as it is loaded into memory. This enables the malware to disable security features or intercept network communication libraries like OkHttp. * **Syscall instrumentation:** To further hide its traces, Godfather places hooks that instrument and manipulates syscalls executed by the target app process using seccomp filters. While common malware may rely on accessibility and permission-based attacks, identifying these techniques alone is insufficient. Malware, like Godfather, combines multiple techniques, creating complex, multi-layered attacks that can bypass traditional defenses. Another example we have [recently covered](https://www.guardsquare.com/blog/phishing-attacks-mobile-banking-apps) is when malware relies on statically patching an application’s [anti-tampering measures](https://www.guardsquare.com/blog/why-all-mobile-apps-need-anti-tampering-protection) along with the checks the application performs to look for enabled accessibility services. In this scenario, applications are unaware they are being attacked, unless proper anti-tampering (with a sufficient number of random injection points, indistinguishable from the application’s own code) and threat monitoring are in place. The key takeaway here is that while many of these attacks may not be new to the [mobile app security](https://www.guardsquare.com/what-is-mobile-app-security) industry, detecting and identifying each of them individually as well as implementing robust security measures is crucial to preventing complex attacks. This is what's referred to as a multi-layered approach. Detecting root, app tampering, and more with Guardsquare’s RASP --------------------------------------------------------------- While the aforementioned attacks may not be unknown to the mobile app security industry, detecting and identifying each of them individually is what helps prevent multiple different attack techniques from being stacked and complex attacks from being built upon them. This, too, is part of a multi-layered approach. > Detecting rooting, app tampering, or even the use of accessibility services would not have been enough to detect the presence of evolving mobile malware strands This is where Guardsquare’s unique [runtime application self protection (RASP)](https://www.guardsquare.com/runtime-application-self-protection-rasp) solution capabilities comes into play. Guardsquare’s RASP was designed from the ground up to be agnostic of malware strands. For this reason, it’s able to detect a given type of attack, regardless of whether it’s being used in conjunction with more attacks, as seen with Godfather. Guardsquare’s approach to protection is based on achieving the best outcomes by combining these layered security features. As previously stated, Guardsquare has been able to detect and protect its customers from the latest Godfather variants of the malware since before it started spreading by identifying the hooks the malware places against the target application, such as through seccomp filters. Guardsquare has had these detections for over two years. With Guardsquare, app developers are able to detect the use of these different techniques and make decisions about whether to crash the mobile application, invoke a custom callback as well as optionally report these threats to our threat monitoring service. #### Going further with app attestation As we have seen, proactive monitoring and a solid RASP defense are necessary in order to stay ahead of attacks. But what if there was a way to complement these and gain insights about whether the device and application are legitimate? Or if you could adjust and improve your detection capabilities on the go with server-side changes, without needing to re-release your application? A way in which you can complement ThreatCast data is with [Guardsquare’s App Attestation](https://www.guardsquare.com/introducing-mobile-app-attestation). For example, you can obtain attestation tokens which are linked to specific instances of a mobile application running on a device. With them, you can get threat information directly at the specific points in time you choose, such as during user login, where you can link users and tokens. This allows for correlating possible attacks with specific user accounts. Threat data combined with App Attestation results can then be turned into actionable recommendations. If you consider that specific devices do not meet your desired criteria based on App Attestation results, these can be blocked from accessing your API when used in combination with server-side attestation, or trigger a degraded user experience with enhanced mitigations. In some cases, App Attestation can perform additional detections without having to re-release your application. Policies can also be reconfigured dynamically, allowing you to adjust RASP checks, security controls, and reaction mechanisms in real-time. #### What this means for your business Threats are evolving fast, as shown by the surge of Godfather malware variants, but with visibility into real-world attack behaviour, the ability to detect suspicious activities in real-time, and [mobile application protection](https://www.guardsquare.com/what-is-mobile-application-protection) that adapt without disrupting your release cycle, Guardsquare’s unique mobile app threat intelligence data, collected across hundreds of millions of daily active devices, empowers security teams to proactively defend their mobile apps from malware, [reverse engineering](https://www.guardsquare.com/blog/protecting-against-reverse-engineering), and tampering threats. To learn more, [connect with an expert today](https://www.guardsquare.com/request-pricing?). Tag(s): [Android](https://www.guardsquare.com/blog/tag/android) , [Protection](https://www.guardsquare.com/blog/tag/protection) , [Dexguard](https://www.guardsquare.com/blog/tag/dexguard) , [Threatcast](https://www.guardsquare.com/blog/tag/threatcast) , [Threat monitoring](https://www.guardsquare.com/blog/tag/threat-monitoring) -------------------------------------------------------------------------------- title: "Why Code Obfuscation Isn’t Enough to Protect Mobile Apps | Guardsquare" description: "Learn why relying solely on code obfuscation techniques isn't sufficient and discover the multi-layered approach to effectively protecting mobile apps." source: "https://www.guardsquare.com/blog/code-obfuscation-mobile-app-protection" -------------------------------------------------------------------------------- July 30, 2024 Why Code Obfuscation Isn’t Enough to Protect Mobile Apps ======================================================== Written by: Guardsquare For many businesses, mobile applications are integral to operations and customer engagement. However, the rise of mobile apps has also heightened the risk of intellectual property (IP) theft, putting revenue, brand reputation, and other critical aspects at risk. Attackers typically attempt to [reverse-engineer](https://www.guardsquare.com/blog/reverse-engineering-financial-apps-protection) a mobile app through: 1. **Decompiling:** Attackers use decompilers to convert the app’s binary code back into human-readable source code. 2. **Analyzing code:** They analyze the decompiled code to understand its structure, logic, and functionality. 3. **Modifying code:** Attackers can then modify the code to remove licensing checks, add malicious code, or extract proprietary algorithms and assets. 4. **Repackaging:** The modified code is recompiled and repackaged into a new app that can be distributed as an unauthorized or pirated version. While [code obfuscation](https://www.guardsquare.com/what-is-code-obfuscation) is a common technique for safeguarding apps, it is insufficient as a standalone measure. Let’s explore why leading mobile app developers recognize that relying solely on code obfuscation techniques isn't sufficient and discover the [multi-layered approach to effectively protecting their apps](https://www.guardsquare.com/video/why-multi-layered-mobile-app-security-is-the-best-approach). The basics of code obfuscation ------------------------------ Code obfuscation involves making the source code difficult to read and be understood by humans. It typically includes renaming variables, classes, and methods to non-meaningful names. Many developers stop at [name obfuscation](https://www.guardsquare.com/blog/why-mobile-app-obfuscation-must-go-beyond-name-obfuscation), for example, turning a function name like \`calculateTotal\` into \`a1B2C3\`. While this method can deter casual scrutiny, it alone doesn't alter the underlying logic of the code, eventually leading to reverse engineering with slightly more effort. Hackers can still decompile and analyze the obfuscated code to understand its functionality. Here’s why: Despite obfuscation, the logical structure of the code remains intact. This is similar to changing the names of characters in a book without altering the plot. An experienced hacker can still follow the story. In addition, modern decompilers and reverse engineering tools can easily navigate obfuscated code. These tools are designed to understand code logic, regardless of naming conventions. iOS Code Obfuscation -------------------- **iOS code obfuscation** is the process of transforming code into a version that is functionally identical but remarkably difficult to reverse engineer. It protects mobile apps from tampering, analysis, and unauthorized access. This is especially important in native iOS applications where attackers may use decompilers or dynamic analysis tools to gain insights into an app’s inner workings. Guardsquare’s [iXGuard](https://www.guardsquare.com/ixguard) offers advanced iOS code obfuscation and runtime protections, designed to protect apps against reverse engineering, tampering, and dynamic analysis. Android code obfuscation ------------------------ **Android code obfuscation** transforms app code into a functionally equivalent version that is significantly more difficult to analyze, reverse engineer or tamper with. This helps safeguard sensitive business logic, proprietary algorithms, and security mechanisms from unauthorized access. Android apps are particularly vulnerable to reverse engineering through tools like APK decompilers and debuggers, making code obfuscation and encryption essential layers of defense. Guardsquare’s [DexGuard](https://www.guardsquare.com/dexguard) provides advanced Android code obfuscation and runtime protection. DexGuard is specifically designed to harden Android apps against static and dynamic analysis, helping developers maintain the integrity of their applications and the sensitive data that passes through them. The need for comprehensive code hardening ----------------------------------------- To truly protect a mobile app, developers must implement [multiple layers of security](https://www.guardsquare.com/defense-in-depth-layered-approach-to-mobile-app-security). A layered approach to [mobile app security](https://www.guardsquare.com/what-is-mobile-app-security) addresses multiple vulnerabilities, making it harder for attackers to exploit the app. Each layer provides a different type of protection, such as various obfuscation techniques and real-time threat detection, ensuring comprehensive defense. This multifaceted strategy significantly reduces the risks and enhances the overall security of the app. For example, beyond the basic name obfuscation technique described above, developers might employ a variety of [code hardening](https://www.guardsquare.com/code-hardening) techniques, such as: 1. **Control flow obfuscation:** This technique alters the code's control flow, making it harder for decompilers to understand the sequence of operations. It's like scrambling the chapters of a book, making it difficult to follow the narrative. 2. **Arithmetic obfuscation:** This involves replacing simple arithmetic operations with complex, equivalent expressions. This adds a layer of confusion, making it harder for bad actors to reverse engineer the calculations. 3. **String & class encryption:** Encrypting strings and class names adds another layer of security, making it difficult for attackers to decipher critical parts of the code. 4. **Resource encryption:** Encrypting resources such as images and configuration files protects against extraction and misuse. Let’s look at how mobile app developers at leading global organizations are using these techniques and more to protect their app code. A real-world approach to layering security protections ------------------------------------------------------ The most effective strategy for securing mobile apps involves layering various code hardening techniques and real-time defenses: * **Obfuscation:** Use advanced obfuscation methods described above, beyond simple name changes * **Encryption:** Encrypt sensitive parts of the code and resources * **RASP (Runtime Application Self-Protection):** Implement mechanisms that allow the app to detect and prevent real-time attacks. Combined with comprehensive [threat monitoring](https://www.guardsquare.com/threat-monitoring), development teams can defend their applications against even the most complex, emerging threats. Let’s look at how some of the leading developers are protecting their mobile applications using this approach. #### Protecting a leading banking app from malicious actors [Recent research by Guardsquare](https://www.guardsquare.com/report/mobile-application-security-report) found that, surprisingly, only 48% of organizations reported having up-to-date company policies that outlined security requirements. Organizations may focus on the minimum requirements due to a lack of time and available skills to create their desired security process for mobile apps. This is alarming in financial services apps, given the high stakes involved, including monetary fraud and reputational damage. Knowing the risks, one of the [50 largest U.S. banks](https://www.guardsquare.com/customer-story/top-bank-uses-guardsquare-to-ensure-mobile-banking-security) implemented a multi-layered security approach to protect its mobile app's intellectual property and customer data. Facing the challenges of securing their Android app against tampering, repackaging, and malicious code insertion, the bank's development team employed advanced security techniques. They used code hardening as the first line of defense, protecting their applications and libraries and making them difficult to tamper with. The bank also integrated RASP to detect and prevent real-time attacks, especially on rooted devices. Regularly updating security configurations, the development team ensured their app stayed resilient against new threats. This comprehensive security approach not only prevented reverse engineering but also helped the [bank meet compliance requirements for mobile payments](https://www.guardsquare.com/blog/the-impact-of-mobile-app-security-for-financial-services), providing peace of mind for both the bank and its customers. #### Safeguarding patented innovations for a leading Android application One of the [longest-maintained AI apps](https://www.guardsquare.com/advanced-ai-tool-provider-uses-dexguard-and-threatcast-to-secure-their-android-mobile-app) on Google Play, an award-winning Android app allows users to manage device settings automatically based on customizable conditions. Concerned about piracy and the security of the app, the developer implemented a multi-layered approach to protect both intellectual property and user data. The developer employed advanced code obfuscation, RASP, and real-time threat monitoring to secure the app against tampering, reverse engineering, and unauthorized modifications. These measures not only safeguarded the app’s four patented innovations, but also ensured a secure and seamless user experience. By stripping unnecessary code and monitoring threats, the developer maintained the app's performance and security, providing users with a reliable and privacy-focused solution. #### Keeping photo and video copyright pirates at bay A [leading software company](https://www.guardsquare.com/customer-story/video-software-company-trusts-guardsquare-to-prevent-mobile-app-piracy) designs top mobile video and photo imaging software for iOS and Android, widely used by artists in Hollywood and Bollywood. Their Android app faced continuous attacks aimed at pirating the paid app and distributing unauthorized copies, leading to revenue loss and brand damage. The existing Google Play licensing service was insufficient as attackers bypassed the licensing check to copy and pirate the app. To counter these threats, the development team adopted a multi-layered security approach, enhancing code obfuscation, encrypting assets, and implementing RASP. These measures significantly increased the difficulty for attackers to clone or repackage the app. By combining these advanced security techniques, the company effectively protected its intellectual property, maintained app stability, and ensured a secure and reliable user experience. This comprehensive approach not only safeguarded the app but also preserved the company's reputation and revenue stream. Obfuscation is only one part of comprehensive mobile app security ----------------------------------------------------------------- Relying solely on code obfuscation to [protect mobile applications](https://www.guardsquare.com/what-is-mobile-application-protection) might deter amateurs, but it won't stop determined intruders. The stories above demonstrate the effectiveness of implementing a layered security approach, combining multiple code hardening techniques with protections at runtime and real-time threat monitoring. Failing to protect mobile apps adequately from threats such as piracy, reverse engineering, and unauthorized modifications can lead to significant financial losses, damage to brand reputation, and compromise of user privacy. This approach is essential to safeguarding your app's integrity, ensuring that attackers can’t easily reverse-engineer and steal code or other proprietary assets. Keeping the right defenses in place for mobile apps can cement their position as a crucial part of business operations, preventing costly attacks and reputational damage. Quick Look: iOS Code Obfuscation Takeaways ------------------------------------------ * Obfuscation makes iOS app code harder to understand and exploit. * Code obfuscation is an essential defense against static analysis. * Tools such as iXGuard automate and enhance obfuscation in mobile applications. Summary: Android Code Obfuscation Highlights -------------------------------------------- * Obfuscation makes Android app code harder to understand and reverse-engineer. * Code obfuscation enhances security, protects against piracy, and safeguards sensitive logic. * Tools such as DexGuard automate and strengthen code obfuscation in Android apps. Tag(s): [Protection](https://www.guardsquare.com/blog/tag/protection) , [Dexguard](https://www.guardsquare.com/blog/tag/dexguard) , [iXGuard](https://www.guardsquare.com/blog/tag/ixguard) , [Thought leadership](https://www.guardsquare.com/blog/tag/thought-leadership) -------------------------------------------------------------------------------- title: "Key Features of an Effective RASP Solution | Guardsquare" description: "What is RASP security and what are key features of an effective runtime application self-protection solution? Learn what RASP protects against and more." source: "https://www.guardsquare.com/blog/rasp-solution-key-features" -------------------------------------------------------------------------------- August 13, 2024 Key Features of an Effective RASP Solution & What It Protects Against ===================================================================== Written by: Jija Bhattacharya - Product Marketing Manager [Runtime application self-protection (RASP)](https://www.guardsquare.com/runtime-application-self-protection-rasp) has emerged as a critical component in the array of various threats that mobile applications face. A robust RASP solution integrates seamlessly within the app to provide continuous protection against attacks in real-time. In this blog, we discuss the different RASP attack vectors in the context of mobile app protection and explore the essential features and qualities that define an effective RASP solution. Runtime application self-protection is a security technology that embeds protection mechanisms directly into an application, enabling it to detect and [defend against attacks in real time](https://www.guardsquare.com/blog/protecting-runtime-integrity-with-rasp-threat-monitoring). Unlike traditional security measures that focus on perimeter defenses (such as firewalls and intrusion detection systems), RASP works from within the mobile application itself. This internal positioning enables the possibility of extending it to offer a dynamic response to threats as they occur by monitoring the environment and application execution, detecting unusual behaviors, and responding to potential threats as they occur. This capability allows the application to respond in a timely manner, thwarting attacks. Often, attacks lead to activities like harvesting information or extracting sensitive intellectual property, which can have significant consequences. This is particularly crucial for mobile apps, given the diverse range of threats they face, from malware and data breaches to unauthorized access and [code tampering](https://www.guardsquare.com/blog/why-all-mobile-apps-need-anti-tampering-protection). How does RASP work? ------------------- Ideally, RASP checks are automatically injected into the application code. Here’s a closer look at how RASP functions: **Real-time monitoring:** RASP monitors the app's execution flow and the interactions it has with its environment. This includes system calls, data inputs, and other runtime activities. **Threat detection and mitigation:** When a potential threat is detected, RASP can help take various actions to protect the app. Reaction strategies can include: * Report the threat event to a server * Crash the application to prevent the attack * Invoke a custom callback to limit the user's ability to continue Common mechanisms for dynamic attacks that RASP helps mitigate -------------------------------------------------------------- #### Debuggers Debuggers are essential tools for developers, allowing them to monitor and control app execution to fix bugs. However, attackers can exploit debuggers to access an app’s internal state, including memory and registers, enabling them to modify the app’s behavior, inject malicious code, or extract sensitive data. #### Emulators and Simulators Emulators and simulators are used by developers to test apps on different platforms. Attackers can use these tools to observe how an app functions, authenticate to backend systems, and interact with the filesystem. By manipulating the operating system’s behavior, attackers can remove security controls and gain deeper access to the app. #### App repackaging App repackaging, or cloning, involves modifying a legitimate app’s code to add malicious elements before redistributing it. Users unknowingly download these infected apps, which can lead to data breaches and other security issues. #### Function or method hooking Function or method hooking is a technique where specific functions or methods in an app’s code are intercepted and altered dynamically, often at runtime. This allows attackers to modify or extend the behavior of existing functions without changing the source code. This technique can be used to tamper with an app to steal sensitive data, modify program output, or inject malware, giving attackers control over the app’s behavior. #### Dynamic binary instrumentation Dynamic binary instrumentation [(DBI) frameworks](http://www.ryantzj.com/introduction-to-dynamic-instrumentation-in-mobile-security.html) insert code into running programs to monitor or modify their behavior. While useful for legitimate purposes like debugging and performance analysis, attackers can use DBI to insert malicious code, bypass restrictions, and manipulate app functionality. #### Jailbreaking and rooting [Jailbreaking (iOS) and rooting (Android)](https://www.guardsquare.com/blog/what-rooting-and-jailbreaking) remove manufacturer-imposed restrictions on devices, granting attackers full access to the filesystem and operating system. This access allows them to install malware, steal sensitive data, and bypass security measures. Key features of an effective RASP solution for mobile apps ---------------------------------------------------------- #### Obfuscated RASP checks The injected runtime application self-protection checks within the code should be well obfuscated to hinder attackers from identifying and bypassing them. #### Polymorphic RASP injections In [dynamic attacks](https://www.guardsquare.com/blog/addressing-static-and-dynamic-attacks), app publishers use runtime application self-protection to detect and respond to tampering in real-time. However, malicious actors can identify and try to bypass these defenses. Polymorphism tackles this by automatically inserting RASP checks in different locations with each build, making it extremely challenging for attackers to create scalable attacks that persist against new versions of your application. This proactive strategy not only counters dynamic analysis attempts like debugger attachment or hooking but also strengthens security through real-time [threat monitoring tools](https://www.guardsquare.com/threat-monitoring). #### A guided approach to automatic RASP injections A guided approach to RASP injections measures the demand for every function while the application is running. It aids in profiling by automatically generating configuration rules to maintain performance while amplifying RASP capabilities. #### Tuning capabilities RASP is a set of integrity and environment checks that is added to your application (or a library). Every threat situation is expressed through many different isolated mini-checks embedded directly in your code. As a developer, you retain the flexibility to adjust the settings to find the right balance between performance and protection quality. #### Real-time threat detection and mitigation A good RASP solution must excel in real-time threat detection and mitigation. It should enable continuous monitoring of application behavior, detecting potential threats as they happen. Conclusion ---------- Failing to adequately [protect mobile apps](https://www.guardsquare.com/what-is-mobile-application-protection) from threats like piracy, reverse engineering, and unauthorized modifications can result in significant financial losses, damage to brand reputation, and compromised user privacy. Implementing a [multi-layered security approach](https://www.guardsquare.com/video/why-multi-layered-mobile-app-security-is-the-best-approach) is crucial, combining multiple [code hardening](https://www.guardsquare.com/code-hardening) techniques with runtime protections and real-time threat monitoring. Relying solely on [obfuscation](https://www.guardsquare.com/what-is-code-obfuscation) without incorporating runtime application self-protection leaves your app susceptible, as RASP provides essential runtime defenses necessary in today's fast-evolving threat landscape. **Learn how an effective RASP solution can protect your mobile apps from sophisticated threats.** [Connect with our experts.](https://www.guardsquare.com/request-pricing) Tag(s): [Protection](https://www.guardsquare.com/blog/tag/protection) , [Dexguard](https://www.guardsquare.com/blog/tag/dexguard) , [iXGuard](https://www.guardsquare.com/blog/tag/ixguard) , [Threat monitoring](https://www.guardsquare.com/blog/tag/threat-monitoring) , [General](https://www.guardsquare.com/blog/tag/general) -------------------------------------------------------------------------------- title: "4 iOS App Security Best Practices for Mobile | Guardsquare" description: "Explore mobile app security best practices for iOS, including secure coding, understanding jailbreaking threats, and managing third-party dependencies." source: "https://www.guardsquare.com/blog/ios-mobile-app-security-best-practices" -------------------------------------------------------------------------------- January 7, 2025 4 Mobile App Security Best Practices for iOS ============================================ Written by: Guardsquare With millions relying on iOS applications for sensitive tasks like banking, healthcare, and communication, [mobile app security](https://www.guardsquare.com/what-is-mobile-app-security) has never been more important. Apple’s strict App Store guidelines and the perception of iOS as a "walled garden" contribute to its reputation as a more secure platform. No system is impervious to threats. Developers can’t afford to assume Apple’s built-in protections are enough — proactive iOS app security measures are still essential. Instead of relying on OS-level protections alone, leading organizations should think of mobile app security as a [shared responsibility](https://www.guardsquare.com/blog/mobile-app-security-a-shared-responsibility-model) among developers, security teams, app publishers, device manufacturers and their associated operating systems, consumers, and app protection providers. [Like Android](https://www.guardsquare.com/blog/android-security-threat-best-practices), iOS apps face risks including man-in-the-middle attacks, reverse engineering, tampering, and more. Developers must adopt iOS app security best practices to protect their applications and users from potential threats such as reverse engineering, tampering, unauthorized access, and malicious attacks. Mitigating those risks includes implementing the right security controls, alongside ongoing threat monitoring and regular mobile application security testing throughout the app development lifecycle. Let’s dive into four proactive best practices to strengthen your [mobile iOS app security](https://medium.com/adessoturkey/ios-app-security-96c32ba4e036). 1\. Implement secure coding practices for iOS --------------------------------------------- [Creating a secure iOS app](https://www.guardsquare.com/blog/three-ios-app-security-tips-developers-can-implement-today) begins with [writing secure code](https://medium.com/@govindaraokondala/mastering-ios-app-security-essential-best-practices-and-guidelines-for-developers-secure-coding-b1edf14223bc). Even with iOS’s architecture, vulnerabilities can emerge if you don’t follow best practices. Here are some secure coding tips for iOS developers to ensure security for mobile apps: * **Use strong encryption to protect data at-rest:** If you need to store data on a device, be sure to encrypt it to prevent unauthorized access, especially in cases of device loss or compromise. Libraries like [CryptoKit or CommonCrypto](https://medium.com/swiftly-engineered-ios/encrypting-data-with-commoncrypto-and-cryptokit-in-swiftui-4c2aacc5b825) provide developers with frameworks to encrypt files, databases, or other sensitive information. By implementing strong encryption standards, such as [AES-256](https://medium.com/@vialyx/security-data-transforms-with-swift-aes256-on-ios-6509917497d), and [applying encryption in various layers](https://www.guardsquare.com/code-hardening), developers can protect data even if it’s accessed by unauthorized parties. * **Employ code obfuscation:** [Code obfuscation](https://www.guardsquare.com/what-is-code-obfuscation) transforms your app’s source code into a less human-readable format, making it harder for attackers to reverse engineer, analyze, and tamper. Obfuscation techniques can include renaming variables, altering control flows, and encrypting strings to hide logic and sensitive data. While obfuscation alone does not prevent reverse engineering, it adds an extra layer of complexity that deters many attackers from targeting the app. * **Apply runtime integrity checks:** Runtime integrity checks, such as [runtime application self protection (RASP)](https://www.guardsquare.com/runtime-application-self-protection-rasp) monitor the app’s environment for signs of tampering or compromise, such as being run on a jailbroken device (we’ll cover that in more detail next) or with modified code. These checks can detect unauthorized changes to important files or settings and respond accordingly — for example by disabling certain features or preventing the app from running. Integrating runtime integrity checks helps developers proactively address mobile app security threats and ensure the app operates in a secure environment. * **Limit permissions:** Permissions are high on the list of potential mobile app security threats. Minimizing the permissions an app requests reduces its attack surface and improves user trust. For instance, if your app does not need access to location, contacts, or photos, avoid requesting these permissions altogether. Implementing the principle of least privilege ensures the app only interacts with necessary resources, limiting the potential for misuse or exposure of user data in the event of a security incident. * **Avoid hardcoding sensitive data:** [Storing API keys](https://mas.owasp.org/MASWE/MASVS-STORAGE/MASWE-0005/), URLs, or other sensitive data directly in the source code creates a significant risk, as attackers can easily extract this information through reverse engineering. Instead, use secure storage solutions like the [iOS Keychain](https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web#:~:text=Keychain architecture in macOS macOS also provides,opening the Keychain Access app in /Applications/Utilities/) to dynamically fetch sensitive data as needed, ensuring it is not exposed in the application binary. By integrating these practices, [developers can harden their iOS apps](https://ied.eu/blog/building-secure-ios-apps-essential-security-practices-for-developers/) against threats while maintaining both performance and user experience. It’s important to note that developers don’t need to handle these security challenges alone. With the volume and pace of mobile app releases, it is important to balance iOS app security with speed. Using third-party tools and best practices can address the risks associated with unprotected mobile apps such as loss of IP, revenue, brand trust, and more. In fact, [recent research shows](https://www.guardsquare.com/quote-ppc?utm_source=adwords&utm_medium=ppc&utm_campaign=RL-Search-Brand-AllSolutions-AllGeos&utm_content=Guardsquare&utm_term=guardsquare&location=&device=c&hsa_acc=2411283683&hsa_mt=e&hsa_src=g&hsa_kw=guardsquare&hsa_cam=21072268955&hsa_tgt=kwd-372151275988&hsa_ver=3&hsa_ad=692566826077&hsa_grp=157444153097&hsa_net=adwords&gad_source=1&gbraid=0AAAAADf2IolrEgo4yFsxRG6HeiiKOvdbk&gclid=Cj0KCQiAgJa6BhCOARIsAMiL7V9Y3a8srAgxHaUSLuN107zebHzyhu9ySwV4_kn1nmv3E5nEvrX8KOYaAik_EALw_wcB) that 98% of organizations reported purchasing or considering purchasing additional protection solutions to augment limitations with time and talent. 2\. Stay ahead of jailbreaking risks ------------------------------------ [Jailbroken iOS devices](https://support.apple.com/guide/iphone/unauthorized-modification-of-ios-iph9385bb26a/ios) bypass system protections, exposing apps to potential malware and reverse engineering. Developers can detect these environments and take necessary actions on compromised devices. While Apple has made it increasingly difficult to jailbreak devices through kernel and hardware improvements, some users still opt for this practice, weakening their device’s protections. Fortunately, APIs can identify indications of a jailbreak, such as modified libraries or the presence of unauthorized tools. Apps can then take actions such as disabling certain features or refusing to run altogether. Despite jailbreak detections, developers need to stay updated on the latest techniques and tools. By incorporating mobile application security testing, such as runtime integrity checks and continuously monitoring apps for suspicious activity, they can reduce the risks associated with jailbroken devices. 3\. Manage third-party dependencies securely -------------------------------------------- While Apple’s iOS ecosystem provides most of the frameworks, services, and APIs developers need, some developers [turn to third-party libraries and frameworks](https://martiancraft.com/blog/2024/07/security-concerns-for-ios/) to enhance their apps. Even if they’re from trusted sources, these dependencies can introduce vulnerabilities if not properly managed. To secure mobile apps, developers should: * **Vet & minimize dependencies:** Choose only essential libraries, with a preference toward open-source options that allow code inspection, since this level of transparency enables you to verify the library’s security and quality. Additionally, check for active maintenance and a strong track record of addressing reported vulnerabilities. * **Regularly update libraries:** Ensure dependencies are up-to-date to address known vulnerabilities. Regularly updating dependencies ensures the app benefits from the latest security patches and improvements. Developers should establish a process for monitoring updates, such as subscribing to release notes or setting up automated alerts for changes in dependencies. * **Use dependency scanners:** Tools like Snyk, OWASP Dependency-Check, and GitHub’s Dependabot can identify risks in third-party code. These scanners can integrate directly into development workflows to flag outdated or insecure dependencies and suggest updated versions. By continuously scanning the codebase, teams can proactively address risks. 4\. Embrace security throughout the development lifecycle --------------------------------------------------------- As we’ve seen, developers play an essential role in securing their mobile apps. However, implementing mobile app security best practices shouldn’t be seen as a one-and-done task on the list. To be effective, organizations should embrace a multi-layered security approach, and integrate security throughout their development lifecycle. In addition to the secure coding best practices above, development teams can: * **Regularly test for vulnerabilities:** Testing the security for mobile apps can happen through manual code reviews, which require developers to go through the code line by line to spot potential issues. While this can take a lot of time, it is very thorough. Another approach is [mobile app security testing (MAST)](https://www.guardsquare.com/what-is-mobile-application-security-testing), which uses specialized tools to conduct static analysis, dynamic analysis at runtime, or interactive testing that instruments an application while it’s running to detect security risks and vulnerabilities. * **Monitor ongoing threats:** For real-time [threat monitoring](https://www.guardsquare.com/threat-monitoring), developers can use tools that continuously monitor the app for suspicious activity. These tools can help development teams gain intelligence into their apps’ biggest security gaps, and discover how to take the appropriate action. In addition, if you are using RASP checks and a mobile app security threat is detected, a threat monitoring tool can take immediate action, such as shutting down the app or alerting the user. Informed developers are an essential part of maintaining a proactive security posture for your iOS apps. Protecting your app includes a combination of leveraging secure coding best practices, being mindful of the potential risks, staying on top of third-party dependencies, and prioritizing mobile app security best practices throughout the development lifecycle. **Want to incorporate the best iOS protection for your mobile app?** [**Connect with our experts now**](https://www.guardsquare.com/request-pricing)**.**Tag(s): [iOS](https://www.guardsquare.com/blog/tag/ios) , [Protection](https://www.guardsquare.com/blog/tag/protection) , [Security testing](https://www.guardsquare.com/blog/tag/security-testing) , [iXGuard](https://www.guardsquare.com/blog/tag/ixguard) , [Thought leadership](https://www.guardsquare.com/blog/tag/thought-leadership) -------------------------------------------------------------------------------- title: "Securing Mobile APIs: A Developer-First Approach| Guardsquare" description: "Learn how to make mobile app API security accessible to every developer with these key strategies to integrate and automate security into your SDLC." source: "https://www.guardsquare.com/blog/securing-mobile-api" -------------------------------------------------------------------------------- November 4, 2025 Securing Mobile APIs: A Proactive, Developer-Centric Approach ============================================================= Written by: Michael Olechna - Product Marketing Manager The mobile application has become the primary battleground in the digital landscape. Today's apps are more than just user interfaces; they are distributed nodes of your business logic, constantly connecting to critical backend services. This connectivity has fundamentally shifted the security paradigm, making the mobile APIs a growing attack vector that demands a layered, proactive defense. The Mobile API Security Challenge: Speed vs. Protection ------------------------------------------------------- Mobile APIs are high-value targets. Attackers are exploiting poorly protected endpoints to extract data, manipulate app behavior, or impersonate users, often using readily available tools to disassemble or decompile apps. Threat actors reverse engineer mobile apps to learn the intricacies of the APIs within, and what data and secrets are communicated through the API. With this knowledge, threat actors are able to execute sophisticated API attacks. This constant threat coexists with immense pressure on development teams. In a study by Enterprise Strategy Group, 74% of organizations report that their app development teams are under pressure to accelerate release velocity. In the same survey, 71% acknowledge that this speed has compromised [mobile app security](https://www.guardsquare.com/what-is-mobile-app-security). This duality can create an unsustainable, reactive approach where security is seen as a roadblock. However, this perceived trade-off between speed and security is a false choice. What is truly needed is an integrated strategy where security is an enabler, not a hindrance. The solution is the adoption of a [Secure Software Development Lifecycle](https://www.guardsquare.com/blog/mobile-devsecops-lifecycle) (SDLC) model. This shift-left approach embeds security directly into the development cycle, reducing long-term costs, surfacing risks earlier, and creating closer alignment between engineering and security teams. This secure SDLC relies on a holistic, [multi-layered approach](https://www.guardsquare.com/blog/multi-layered-mobile-app-protection) that combines client-side protection via [code hardening](https://www.guardsquare.com/code-hardening) and [runtime application self-protection](https://www.guardsquare.com/runtime-application-self-protection-rasp) (RASP) with server-side validation through [mobile API security](https://www.guardsquare.com/blog/keeping-up-with-api-security-best-practices-guardsquare), also known as [app attestation](https://www.guardsquare.com/introducing-mobile-app-attestation). The Pillars of a Developer-Centric Secure SDLC ---------------------------------------------- For security to move at the speed of development, it must be accessible, automated, and deeply integrated. This is the foundation of a developer-centric approach. #### Mobile Automated Security Testing and Actionable Guidance Shifting security left in the development lifecycle is critical to making it more accessible. [Mobile Application Security Testing](https://www.guardsquare.com/what-is-mobile-application-security-testing) (MAST) that encompasses Static Analysis Security Testing (SAST) and Interactive Application Security Testing (IAST) is essential. Tools like [Guardsquare’s AppSweep](https://www.guardsquare.com/appsweep-mobile-application-security-testing) integrate seamlessly into CI/CD pipelines and automates the testing process, making it easier to identify vulnerabilities prior to release. Vulnerabilities like hardcoded keys are more common than many expect. A [recent study](http://dl.acm.org/doi/full/10.1145/3735968#:~:text=The complex design of security,cryptography API misuse [8].) of over 10,000 Android apps discovered nearly 95% contained misused cryptography APIs. [A different study](http://www.diva-portal.org/smash/get/diva2:1874555/FULLTEXT01.pdf) of health and fitness apps concluded all of the apps had insecure communication vulnerabilities, like inconsistent encryption use for network traffic. The complexity of security APIs and security skills gap between developers is a major factor for widespread API misuse among mobile apps. AppSweep helps developers quickly find and fix critical security issues like the examples above while providing actionable security recommendations. By mapping findings to standards like the [OWASP Mobile Application Security Verification Standard (MASVS)](https://www.guardsquare.com/owasp-masvs-better-protection-mobile-app), and providing remediation guidance, these tools save time and help bridge the security skill gap. This early detection is key, as fixing code issues early in the SDLC saves developers both time and money in the long run. #### The Zero Trust Foundation The [Zero Trust Architecture](https://www.guardsquare.com/blog/protect-mobile-apps-in-zero-trust-world) is no longer confined to enterprise networks; it is moving to mobile. On the mobile front, Zero Trust Architecture principles ensure that every access request—regardless of user, device, or location—must be verified in real time. This foundation mandates strict defensive principles for developers: * **Avoid Client-Side Secrets:** A common and dangerous mistake is the hardcoding of sensitive information, such as API keys, credentials, and tokens directly in the code. Even with code hardening techniques like obfuscation, these plain-text strings can be potentially exposed when an attacker decompiles the app. Developers must avoid client-side API key exposure as a top strategy. String encryption, a form of code hardening, ensures that critical information is protected and decrypted only at runtime. * **Principle of Least Privilege:** Apply the principle of least privilege to all API keys and tokens to minimize the impact of a leakage or breach. * **Secure Communication:** Enforce the use of TLS 1.2 or higher (HTTPS) for all API traffic, as mobile devices frequently connect on networks that are not secured, making communication susceptible to [Man-in-the-Middle (MITM) attacks](https://www.guardsquare.com/blog/how-to-avoid-mitm-attacks). Establish SSL/Certificate Pinning as an additional security layer for API communications, ensuring that communication cannot be intercepted by an MITM attack that presents a different, but otherwise valid, security certificate. The Role of Client-Side Protection: Defense in Depth ---------------------------------------------------- Once an app is launched on an app store and in the outside world, it becomes vulnerable to [tampering](https://www.guardsquare.com/blog/mobile-app-tampering) and dynamic analysis. The most resilient defenses are those built directly into the application code, creating a Defense-in-Depth strategy. #### Code Hardening: Obfuscating Business Logic and IP Code Hardening is the practice of implementing protective measures to increase the complexity of an app's code and prevent reverse engineering. [Obfuscation](https://www.guardsquare.com/what-is-code-obfuscation) increases the difficulty to decompile the source code of an application using static analysis. In turn, it protects APIs by rendering the code illegible for attackers, thus hiding business logic and key API functions of the app, as well as their location in the application. Guardsquare’s solutions, such as [DexGuard (Android)](https://www.guardsquare.com/dexguard) and [iXGuard (iOS)](https://www.guardsquare.com/ixguard), provide multiple layers that make the code illegible without affecting its functionality. Key hardening techniques include: * **Name Obfuscation:** The first line of defense, making function and class names a "meaningless mess" to make it harder for an attacker to extract sensitive information. * **Control Flow Obfuscation:** This alters the code’s logical flow, introducing artificial loops and branches that make it harder for an attacker to follow the original execution path and determine the app’s core functionality. * **Arithmetic Obfuscation:** This technique replaces arithmetic operations with more complex computations to confuse static analysis. * **Code Virtualization:** This technique transforms method bodies into custom virtual machine (VM) bytecode to prevent bad actors from recognizing the original code * **API Call Hiding:** This concept involves hiding direct API calls to increase difficulty when analyzing the code. * **Data and String Encryption:** This technique encrypts strings and class names to render them unusable for attackers without using the correct encryption key. * **Polymorphism:** This key concept continuously "[resets the clock](https://www.guardsquare.com/blog/why-resetting-the-clock-matters-for-mobile-app-security)" on attackers by automatically changing the placement of protective measures with every new build. This forces threat actors to repeatedly reverse engineer each iteration, negating any previously acquired knowledge. #### Runtime Application Self-Protection (RASP) To protect against dynamic analysis and runtime threats, code hardening should be combined with RASP. RASP brings real-time awareness of the app's operating environment, allowing the app to monitor its own integrity and the integrity of the environment in which it's running. RASP works by injecting runtime checks into the application’s code to detect code, environment, and application level threats. RASP detects mobile app security threats like code injection, hooking frameworks, or [rooted/jailbroken devices](https://www.guardsquare.com/blog/what-rooting-and-jailbreaking) at runtime. When a threat is detected, RASP features enable defensive actions such as shutting down the app, restricting functionality, or alerting the security team. By blocking unauthorized access through these checks and subsequent actions, RASP protects APIs from being misused by unauthorized threat actors. Detecting the presence of apps being run on emulators or jailbroken devices is critical as many API attacks are executed on such devices. This runtime protection is a necessary defense to ensure the application is running in a secure environment without being tampered by bad actors attempting to access the application’s APIs. The Final Layer of Trust: Server-Side App Attestation ----------------------------------------------------- Client-side protection is powerful, but an attacker can still attempt to impersonate a legitimate app from the server side. This is where App Attestation provides the definitive server-side layer of defense. At its core, App Attestation is a secure approach to verify that only your app can connect to your APIs. By adding server-side validation, App Attestation ensures only legitimate apps interact with a mobile app’s APIs, blocking bots or non-genuine apps that attempt to perform API scraping, credential stuffing, or fraud. Unlike client-side protection, App Attestation logic is enforced on the server, making it opaque to attackers. It gives security teams the control to instantly change security policies—such as revoking trust for a specific tampered version of an app—without requiring a new app deployment. This feature is paramount for managing risk and compliance at scale. When new threats are identified, developers can quickly enable instant security updates without requiring an app update. In a world where release velocity is paramount and security can take a backseat, this agile approach protects your application without impacting development. Security That Doesn’t Compromise Performance -------------------------------------------- The threats to the mobile APIs are real, immediate, and constantly evolving. Relying solely on platform guidelines or a single layer of defense is no longer sufficient. By adopting a comprehensive strategy that spans the entire SDLC—from using automated MAST to find vulnerabilities early to applying multi-layered, polymorphic code hardening and active RASP, and finally securing the backend with App Attestation—organizations can achieve the highest level of protection in the easiest possible way. Development teams can implement the maximum level of protection without compromising app performance, user experience, or time to market. This integrated, proactive security model enables teams to move fast, continuously deliver features, and maintain full confidence in the security of their mobile applications and the critical APIs they connect to. The Secure SDLC transforms security from a reactive burden into an intrinsic, powerful business enabler. To learn more about Guardsquare’s solutions and how they can assist your organization’s mobile app security strategy, [contact us here.](https://www.guardsquare.com/request-pricing?hsCtaTracking=646b0379-d596-4b1a-8526-2ccbdbb0f81b|e8809087-a83f-4476-8b22-34b9572013fd) Tag(s): [AppSweep](https://www.guardsquare.com/blog/tag/appsweep) , [Protection](https://www.guardsquare.com/blog/tag/protection) , [Dexguard](https://www.guardsquare.com/blog/tag/dexguard) , [iXGuard](https://www.guardsquare.com/blog/tag/ixguard) , [App attestation](https://www.guardsquare.com/blog/tag/app-attestation) -------------------------------------------------------------------------------- title: "Mobile App Security Needs Scanning and Protection | Guardsquare" description: "Discover how integrating both scanning and protection strengthens your mobile app security posture and safeguards against dynamic, ongoing threats." source: "https://www.guardsquare.com/blog/scanning-protection-mobile-app-security" -------------------------------------------------------------------------------- November 18, 2025 Why Mobile App Security Needs Both Scanning and Protection ========================================================== Written by: Jija Bhattacharya - Product Marketing Manager The uncomfortable truth about secrets in apps --------------------------------------------- Mobile apps need to talk to the world. They fetch maps, process payments, call APIs, and sync data to cloud services. To do that securely, they often rely on API keys, OAuth tokens, or cryptographic secrets to prove the authenticity of the app or user. The problem is that those keys are often hard-coded in the app. Once the app ships, anyone reverse engineering the app can find them. And attackers do. In the [2025 study](https://eprints.cs.univie.ac.at/8479/1/Secrets_Distributed_in_Android_and_iOS_Apps-1_David Schmidt.pdf) entitled “Leaky Apps: Large-scale Analysis of Secrets Distributed in Android and iOS Apps”, researchers from the University of Vienna unpacked 10,331 apps and discovered 416 valid credentials across 65 different services. They ranged from payment gateways, cloud APIs, and even Git repository tokens that exposed private source code. Even more striking, the team found that iOS apps leaked secrets slightly more often than Android apps. Additional [2025 research](https://www.arxiv.org/pdf/2510.18601), led by Alecci et al., tested whether large language models (LLMs) could detect secrets in Android apps. Their prototype, SecretLoc, scanned thousands of APKs and identified 4,800+ hidden secrets, many missed by traditional [regex](https://riyajn2001.medium.com/regex-a-great-tool-in-your-toolkit-791fb3e99bb1) scanners. The takeaway was that even modern apps with only basic obfuscation can be mined for credentials by anyone with the right tools and AI makes that process faster. Why do hidden secrets keep happening ------------------------------------ [Hardcoded secrets](https://www.guardsquare.com/blog/android-security-misconceptions) appear for two main reasons: 1. **Intentional inclusions:** * Some secrets are genuinely required like a Google Maps API key or a payment provider token that must reside within the app in order for it to function offline. Thus, purposely included to support required functionality, or added under the assumption that the associated risk is low. * Added on purpose, often because the developer doesn’t know there are safer ways to handle it, or simply assumes it’s secure. 2. **Accidental leakage.** More often, keys slip in by mistake, let’s say a developer leaves a test credential in the code, a build script pulls in an environment variable, or an unused config file containing internal keys is bundled into the final binary. The Leaky Apps team even found iOS apps shipping with .gitlab-ci.yml files and shell scripts that contained private tokens. In one case, a [mobile banking app](https://www.guardsquare.com/mobile-banking-finance-app-security) included its entire Swift source directory inside the production package. From an engineering-manager’s point of view, this is negligence. Modern mobile pipelines are complex, [third-party SDKs](https://www.guardsquare.com/blog/insecure-mobile-sdk-risks) are opaque, and release cycles are fast. Without explicit checks, secrets sneak in. That’s where scanning comes in. Scanning catches the secrets that shouldn’t be there ---------------------------------------------------- Scanning provides the answer to the question: “Does this app contain anything that doesn’t belong in the hands of the public?” Static scanners unpack the app (APK or IPA), extract text and code, and search for patterns that look like secrets, like AWS keys, JWT tokens, Google API keys, cryptographic material, and more. #### What the research shows * The study by Leaky Apps confirmed the existence of 416 secrets across more than 10k apps, including 13 Git credentials that opened access to 2,440 private repositories. * The LLM-based SecretLoc approach went further, finding 42 percent of Android apps contained at least one secret, many in formats no regex rule could match. These findings highlight two realities: 1. Attackers are already scanning public apps at scale. 2. Developers need to scan their apps before attackers do. #### Real-world perspective with AppSweep At Guardsquare, we have run automated analyses of 5,480 public Android apps through AppSweep, our iOS and Android app analysis product, since January 2025. We found 164 keys flagged as potential secrets. The dataset is skewed toward sensitive institutions given their reliance on AppSweep's auto-analysis pipeline. The security stakes for these organizations are already high and protections are common. Yet secrets still appeared. That mirrors the academic findings that even mature teams struggle to keep credentials out of release builds. All the above findings highlight that scanning isn’t just a compliance checkbox. The same automation that powers attackers’ discovery tools is available to you, but only if you build it into your process. Treat scanning as a continuous security feedback loop, not a one-off code audit. #### How to integrate application scanning * **Make it part of CI/CD.** Run a scan on every build, just like unit tests. * **Use multiple detectors.** Combine pattern-based scanners (Gitleaks, truffleHog, AppSweep) with AI-assisted tools as they mature. * **Review false positives but don’t ignore them.** It is worse to over-filter than to occasionally get noise. Scanning is about visibility. It ensures you know what’s in your app before the world does. But visibility alone doesn’t equal safety—some secrets can’t be removed. That’s where protection comes in. Under secure architecture practices, most mobile apps should not embed secrets at all. When exceptional cases require a client-side key, the aim is not to rely on obfuscation as a hiding mechanism, but to limit the key’s privileges, lifespan, and extractability. #### Why hiding isn’t enough Once an app is downloaded on a device, it’s in an attacker’s hands. They can decompile, debug, hook APIs, or inspect memory. Simple tricks to hide the keys, like Base64 encoding or string splitting, tend to delay rather than truly stop anyone. The goal isn’t to make reverse-engineering impossible (because it isn’t), but to make it difficult, time-consuming, and ultimately unattractive. One of the more sobering results from the SecretLoc paper was that its LLM easily decoded Base64-obfuscated keys. LLMs can identify secrets even when they don’t match known patterns. They detect intent and context, not just string shapes. This lets them uncover secrets that tools like LeakScope or traditional regex-driven scanners consistently miss. While scanning reduces the number of unnecessary secrets in the binary, it does not eliminate the need to embed certain operational secrets. These embedded credentials remain attractive targets and require strong in-app defenses. In practice, this means applying multiple complementary layers of protection. #### Layers of protection 1. [Code obfuscation.](https://www.guardsquare.com/what-is-code-obfuscation) While obfuscation is not a substitute for proper secret management, it directly impacts how easily secrets can be extracted from a deployed app. Advanced protection tools such as DexGuard(Android) and iXGuard(iOS) apply code-flow obfuscation, string encryption, and class renaming to ensure that any secrets present and the code paths that use them cannot be trivially located by static or dynamic analysis. 2. **Secure storage.** Tokens or encryption keys need to be stored in OS-level keystores (Android KeyStore, iOS Keychain), not plaintext constants. 3. **Runtime integrity checks.** Obfuscation increases the difficulty of static extraction, but attackers frequently pivot to runtime analysis to capture secrets as they are loaded into memory. [Runtime protections](https://www.guardsquare.com/runtime-application-self-protection-rasp) (RASP) detect debugging, hooking, and other forms of instrumentation, and can help take necessary actions when such activity is observed. This significantly constrains the feasibility of straightforward runtime secret extraction. 4. **Backend controls.** Limit what an embedded key can do: apply rate limits, IP restrictions, or tie keys to app signatures. 5. **Key rotation and monitoring.** Assume secrets will leak eventually. Track their use and revoke them quickly. #### The role of perception and policy Some developers sometimes assume iOS apps are inherently safer because IPAs are encrypted on the App Store. The Leaky Apps study proved otherwise, more iOS apps than Android ones contained live credentials. Security through obscurity, and security through Apple's encryption, isn't actual protection against this threat. Protection is about buying time and increasing the attacker's cost. You cannot make reverse-engineering impossible, but you can make it unprofitable. Scanning vs. protection isn’t a debate, it’s a duet --------------------------------------------------- Teams sometimes present this as a binary choice: “If we obfuscate the app, do we still need scanning?”“If we scan everything, do we still need to protect it?” This framing misses the point. These are not interchangeable strategies as they address different stages of mobile security, and you need all of them to build secure apps. **Scanning** identifies accidental issues: Hardcoded secrets that never should have been committed, leftover test files, configuration artifacts, or third-party SDK regressions. It makes sure the app is clean before release. **Architecture** minimizes inherent risk: Ideally, most mobile apps should not ship with secrets at all. By pushing sensitive logic to the backend, using short-lived tokens, or relying on hardware-backed storage, teams can reduce or eliminate the need for client-side secrets. When good architecture removes the secret entirely, the attack surface shrinks dramatically. **Protection** (obfuscation, encryption, RASP) serves a different purpose. It hardens the delivered app against reverse engineering and manipulation. Even when all secrets are handled correctly on the server, attackers can still target the app’s logic, API flows, or client-side checks. Protection ensures it is significantly harder to analyze, tamper with, or repurpose the app in ways that undermine backend security. A useful way to understand the relationship is offense and defense: * **Offense:** scanning finds vulnerabilities early and keeps mistakes from reaching production. * **Design:** strong architecture removes the need for secrets on-device and reduces what must be protected. * **Defense:** protection hardens the running app, ensuring that even if something does slip through or if attackers target logic instead of secrets it’s far more difficult to exploit. Relying on scanning alone is insufficient. Even with scans on every build, developers may need to include a limited-scope key for a legitimate use case, or attackers may go after the app’s logic rather than its secrets. Likewise, relying only on protection is flawed. Obfuscation and runtime checks cannot compensate for fundamentally insecure architectural decisions. The healthy pipeline does all three, It scans continuously to catch mistakes early, architects to avoid shipping secrets whenever possible, and protects the final binary to resist tampering and reverse engineering. These layers reinforce each other and create genuine defense-in-depth. Lessons from the research ------------------------- Both academic papers offer insights worth repeating for anyone managing [mobile app security](https://www.guardsquare.com/what-is-mobile-app-security) programs. #### From Leaky Apps (University of Vienna, 2025): * The paper found 416 functional credentials across 65 services, including 13 Git credentials that grant access to 218 public and 2,440 private repositories. * Secrets aren’t limited to code—they lurk in configs, scripts, and even docs inside app bundles. * Developers often removed secrets in later versions but didn’t revoke them on the backend, leaving them exposed in older builds. * iOS apps leaked slightly more than Android apps, challenging assumptions about platform security. #### From Evaluating LLMs in Detecting Secrets (Alecci et al., 2025): * LLM-powered scanners dramatically outperformed pattern-based tools, discovering new secret types like OpenAI API keys and JWT tokens. * 42% of newly analyzed Android apps contained at least one secret. * The same AI capability can be used by attackers to automate secret discovery across app stores. Together, these studies make an uncomfortable but constructive point: the ecosystem leaks. Every app store contains hundreds of live secrets. Attackers don’t need zero-days;they can simply harvest misconfigurations. For developers and engineering managers, the response shouldn’t be fear, but process: adopt continuous scanning and robust protection so your app isn’t one of the easy targets. Practical best practices for teams ---------------------------------- Below are nine practical recommendations distilled from research, industry experience, and AppSweep data. 1. **Integrate scanning early and often**Add a secret-scan stage to every [CI/CD pipeline](https://www.guardsquare.com/blog/how-appsweep-integrates-with-devops-processes). Treat failures like build breakers. 2. **Re-scan release artifacts**Scan the compiled APK/IPA, not just source code. Secrets often slip in through third-party SDKs. 3. **Externalize configuration**Keep secrets off the device when possible. Use backend-issued tokens or configuration services. 4. **Apply least privilege to all keys**Narrow their scope, add quotas, restrict origins, and monitor usage anomalies. 5. **Obfuscate aggressively**Commercially available advanced obfuscation products with string encryption, resource hiding, and class renaming. 6. **Use the platform’s secure storage**Android KeyStore and iOS Keychain exist for a reason. Let them hold your sensitive material. 7. **Enable runtime self-protection (RASP)**Detect tampering, rooting, and debugging. Consider terminating sessions or disabling functionality if the app environment looks hostile. 8. **Plan for rotation and revocation**Keep an inventory of secrets per release. Practice revoking a key and pushing a patched build quickly. 9. **Educate and codify**[Train developers](https://www.youtube.com/watch?v=A8rS6APV6PA) that “compiled” doesn’t mean “hidden.” Publish internal guidelines on secret handling and scanning procedures. When teams adopt these habits, scanning and protection stop being bolt-ons and become invisible hygiene, just part of shipping a secure app. Why this matters for engineering managers and skeptics ------------------------------------------------------ Security teams often face skepticism from product or engineering leaders: “Our app doesn’t handle sensitive data.”“Nobody would bother reverse-engineering us.” The research proves otherwise. Attackers don’t need your user data; they can exploit your backend through an exposed API key or abuse your paid services using a leaked token. The Leaky Apps team found that a single Git credential in a single app granted access to more than 1,000 private repositories. Moreover, these issues aren’t limited to giant enterprises. The dataset included small startups and hobby apps—anyone can leak secrets, and anyone’s secrets can be valuable. By embedding scanning and protection into normal development workflows, you’re not adding bureaucracy—you’re reducing future firefights. The cost of adding one scanning step is negligible compared to the disruption of an unplanned, emergency key rotation after a leak. Final takeaway -------------- Every mobile app carries a small universe of data inside it—code, assets, and sometimes secrets. Attackers know this and have automated ways to dig them out. The 2025 academic research and the findings from AppSweep results both tell the same story: * Secrets are still leaking into production. * Basic obfuscation no longer fools modern scanners. * Teams that pair continuous scanning with secure-by-design architecture and strong app protection dramatically reduce their attack surface. If you’re leading an engineering or security team, the path forward is clear: 1. **Detect what shouldn’t be there.** Run scanners as part of your standard CI. 2. **Defend what must be there.** Obfuscate, encrypt, and limit its blast radius. 3. **Monitor and rotate.** Assume every secret is temporary. #### TL;DR * Recently, research on more than 10,000 Android and iOS apps found hundreds of live API keys and credentials hidden inside production builds. * Scanning and protection solve different problems. Scanning finds secrets that shouldn’t be there; protection defends the app’s logic and behavior against tampering. Each covers what the other cannot. * Guardsquare’s AppSweep automatically analyzed 5,480 Android apps (mostly financial) and detected 164 hardcoded keys, a proof that even security-aware teams slip up. * Best practices include integrating proactive scanning into CI/CD, minimize what you embed, harden what remains, and plan for rotation and incident response. -------------------------------------------------------------------------------- title: "Code Hardening Explained | Guardsquare" description: "Learn about code hardening, how it protects software from tampering, and key techniques like obfuscation and encryption used for mobile code protection." source: "https://www.guardsquare.com/code-hardening" -------------------------------------------------------------------------------- **Code hardening:** Mobile code protection ========================================== Code hardening is the process of protecting software from reverse engineering, tampering, and any unauthorized access by making the underlying code difficult to read, analyze or modify.Increase your mobile code protection, secure sensitive information and prevent IP theft. [Connect with an expert](https://www.guardsquare.com/request-pricing) What is **mobile code protection?** ----------------------------------- **Mobile code protection** defends mobile app code against reverse engineering and tampering. This includes techniques such as code obfuscation, encryption, and ensuring mobile app integrity. Mobile code protection helps developers safeguard their app’s code and prevents unauthorized access. What is **static analysis?** ---------------------------- Using decompilers or disassemblers, threat actors can expose your mobile app’s internal logic and gain insight into its functionality. With this knowledge, threat actors can reverse engineer your app, steal your IP or sensitive data and identify ways to break down related systems’ and apps’ security. Why is static analysis **a threat?** ------------------------------------ After they’ve uncovered your app's internal logic, an attacker can do a lot of damage. They can steal proprietary information, extract credentials and API keys that will give them access to other systems and apps, unlock premium portions of the app, and more. Leveraging mobile application code hardening provides protection against static analysis to prevent these outcomes and preserve your app's integrity, your data and your brand’s reputation. Why dedicated **mobile code protection solutions** are needed ------------------------------------------------------------- Research shows that despite developers' priorities, mobile apps still aren't secure enough. 81%**of developers believe iOS standard security isn't sufficient.** 84%**of developers believe Android standard security isn't sufficient.** 96%**of developers still rely on operating system security.** 24%**of apps use code hardening.** **Code hardening** essentials ----------------------------- Code hardening techniques render your code illegible without affecting its functionality, ensuring that malicious users who decompile your app won’t be able to easily interpret its internal logic. This category of mobile app security includes strategies such as encryption, removing certain metadata, renaming classes and variables, adding ancillary code, altering the structure of the code and more — all without altering the function of the code or the end user experience in a meaningful way. Less than 10% of the top 3,000 financial services Android apps use additional code protection techniques beyond name obfuscation, leaving them open to reverse engineering. Source: [Report: Most mobile financial apps fall short of security best practices](https://www.guardsquare.com/financial-app-security-report) **Code hardening** techniques ----------------------------- ObfuscationEncryption ### Obfuscation **Obfuscation** refers to rendering code illegible without affecting its functionality. The techniques used to obscure code in this manner vary considerably. They range from the replacement of readable names in the code by difficult to decipher alternatives (**name obfuscation**) to the modification of the logical structure of the code to make it less predictable and traceable (**control flow obfuscation**). Another obfuscation technique consists of the conversion of simple arithmetic and logical expressions into complex equivalents (**arithmetic obfuscation**) [What is code obfuscation?](https://www.guardsquare.com/what-is-code-obfuscation) ### Encryption **Encryption** ensures the code of the application and the data it contains cannot be accessed while the application is at rest. The encrypted code is decrypted on-the-fly when the application is executed guaranteeing that it functions as intended. To be effective, the encryption must be applied in various layers. Essential encryption techniques include **string encryption, class encryption, asset encryption and resource encryption.** Security for **every stage** of the software development lifecycle. ------------------------------------------------------------------- Too often delayed to the end of the development lifecycle, application hardening security needs to be considered right from the start. As your app development progresses, testing, feedback and monitoring help you to ensure the highest possible level of mobile code protection. **DevelopProtectTestMonitor** ### Develop [Mobile app security](https://www.guardsquare.com/what-is-mobile-app-security) is most effective when it’s considered from the outset of the development lifecycle, which includes making informed design choices, following best practices as well as early rounds of testing and refinement. Ultimately, engaging in secure software development practices identifies security risks early, when they’re quick and cheap to fix, rather than after deployment. Guardsquare Customer stories and **resources** ---------------------------------------------- [View All Resources](https://www.guardsquare.com/resources) Mobile app **code hardening** FAQs ---------------------------------- **What is mobile application code hardening?** Mobile application code hardening is crucial in delaying tampering and reverse engineering attempts. It aims to create a robust defense against various security threats, including unauthorized access, data breaches, and the introduction of malicious code. **How to protect with mobile app encryption** Protecting data with mobile app encryption is crucial for ensuring the confidentiality and integrity of sensitive information stored or transmitted by your mobile application. Encryption refers to the process of converting understandable data into a coded or unreadable form. What is code hardening? **Code hardening** is the process of strengthening an application’s code against reverse engineering, tampering, and exploitation by adding multiple layers of protection techniques embedded in the code. Why is code hardening important? **Code hardening** is important because it makes apps more resistant to reverse engineering and tampering, protecting sensitive data, intellectual property, brand reputation and user trust. How does code hardening work? **Code hardening** works by applying techniques like obfuscation, encryption, runtime checks, and integrity verification to make code difficult to analyze or modify. What are examples of code hardening techniques? Examples of **code hardening** techniques include different types of obfuscation techniques, string and class encryption and runtime protections. Discover how Guardsquare provides industry-leading **code hardening protection for mobile apps.** ------------------------------------------------------------------------------------------------- [Connect with an expert](https://www.guardsquare.com/request-pricing) -------------------------------------------------------------------------------- title: "Building Security in the Mobile App Lifecycle | Guardsquare" description: "Mobile app security must be built in, not added on. Protect every layer with a comprehensive framework tailored to your app and the mobile ecosystem." source: "https://www.guardsquare.com/blog/security-in-mobile-app-lifecycle" -------------------------------------------------------------------------------- September 23, 2025 Security by Design Across the Mobile App Lifecycle ================================================== Written by: Jija Bhattacharya - Product Marketing Manager From [mobile banking](https://www.guardsquare.com/blog/mobile-banking-app-best-practices) to telemedicine, e-commerce, and even industrial IoT control, apps are no longer just an extension of business, they are the business. Yet, with this critical role comes an amplified attack surface. CISOs, security officers, and developers must recognize that mobile applications are not merely pieces of software; they are digital gateways that, if not adequately secured, expose organizations to reputational damage, regulatory penalties, and financial loss. What many overlook is that [mobile app security](https://www.guardsquare.com/what-is-mobile-app-security) requires a fundamentally different lens than traditional enterprise security. Unlike servers locked down behind firewalls, apps run on devices beyond organizational control, communicate over hostile networks, and interact with third-party services. Security can’t be a bolt-on; it has to be architected into every layer of the application lifecycle. To achieve this, organizations need a comprehensive security framework tailored to mobile ecosystems, more specifically tailored to your app. 1\. Shifting the security paradigm: From code to context -------------------------------------------------------- Most developers think of app security as [code hardening](https://www.guardsquare.com/code-hardening)—[obfuscation](https://www.guardsquare.com/what-is-code-obfuscation), encryption, or [secure APIs](https://www.guardsquare.com/blog/keeping-up-with-api-security-best-practices-guardsquare). While these are essential, true security requires context. Mobile apps exist in an environment where: * Devices may be [jailbroken or rooted](https://www.guardsquare.com/blog/what-rooting-and-jailbreaking). * Users can install malicious apps. * Network traffic is constantly exposed to interception. * Supply chains introduce [vulnerable SDKs](https://www.guardsquare.com/blog/insecure-mobile-sdk-risks) or third-party libraries. This means developers and security officers must broaden their perspective beyond just the app’s codebase. The framework for mobile app security should consider the device state, user behavior, and external ecosystem in which the app operates. 2\. The pillars of a mobile security framework ---------------------------------------------- A robust mobile security framework must rest on four interdependent pillars: a) Secure by Design: Security begins not in post-production testing but in the requirements phase. [Threat modeling](https://www.guardsquare.com/blog/what-is-threat-modeling-guardsquare) for mobile is critical: developers must map attack vectors specific to mobile contexts, such as insecure data storage, unintended permissions, or weak session management. Key practices: * Threat modeling with tools like STRIDE adapted for mobile. * Privacy by design, ensuring GDPR, CCPA, or HIPAA considerations are baked in. * Least privilege principles applied to permissions. **Code and data protection:** Mobile code is uniquely vulnerable because it is distributed openly via app stores. [Reverse engineering](https://www.guardsquare.com/blog/protecting-against-reverse-engineering) is a constant risk. Key practices: * Obfuscation of code to slow down reverse engineering. * Encryption of sensitive data at rest and in transit. * Runtime checks for tampering, debugging, or emulator use. * Zero-trust data flow, ensuring no sensitive data is stored unencrypted on the device. [Runtime Application Self-Protection (RASP)](https://www.guardsquare.com/runtime-application-self-protection-rasp): Mobile apps can’t assume the device or OS is secure. Embedding runtime defenses enables apps to detect and respond to threats in real-time. Key practices: * Detecting jailbroken/rooted devices. * Identifying malicious injections or API hooking. * Blocking execution when tampering is detected. * Ability to respond, such as shutting down sensitive functions. **Continuous monitoring and response:** Security doesn’t end at deployment. Apps must be continuously monitored for emerging threats and vulnerabilities. Key practices: * Mobile DevSecOps practices that integrate testing into CI/CD. * [Threat monitoring](https://www.guardsquare.com/threat-monitoring) for anomaly detection. * Security updates and patching pipelines. 3\. Beyond the checklist: Building trust through security --------------------------------------------------------- It’s easy to reduce mobile security to a compliance checklist, but in reality, users equate security with trust. Compliance standards are often minimum requirements; CISOs must ensure that the organization not only avoids fines but also cultivates user confidence. Transparency, including clear privacy policies and visible security features (such as biometrics), enhances brand credibility. An often-overlooked aspect is that secure apps can serve as a competitive differentiator. For example, a banking app that proactively warns users of a rooted device isn’t just mitigating risk, it’s demonstrating care for the customer’s financial safety. 4\. Integrating security into the developer workflow ---------------------------------------------------- Security often fails because it is seen as a burden rather than an enabler. Developers must be empowered with tools and automation that make security seamless: * Training developers in secure coding tailored to mobile. * Infrastructure as code scanning to ensure secure continuous testing, with the possibility of recommendations from the tool. * A fully guided platform to help developers configure static and dynamic protections, integrated into CI/CD. * Infrastructure supporting monitoring and attestation under the same platform to ensure runtime stability post app publication. The key is to avoid bottlenecks. Security gates should be guardrails, not roadblocks. 5\. The human factor: Users as the final security layer ------------------------------------------------------- Even the most secure app is only as strong as its user base. [Phishing](https://www.guardsquare.com/blog/phishing-attacks-mobile-banking-apps), weak passwords, and poor security hygiene remain the top entry points for attackers. Forward-looking frameworks must account for (to list a few): * Frictionless MFA, using device biometrics and adaptive authentication. * Fail-safe defaults, such as auto-logout or encrypted local caches. By designing with the end-user in mind, developers can turn the human factor from a liability into an asset. For CISOs and developers, the challenge is to align on a shared vision, not just to protect the app, but to leverage security as a foundation for new digital services. [Building secure mobile apps](https://www.guardsquare.com/blog/mobile-app-security-strategy-guide) requires moving beyond code hardening toward a holistic, context-aware security framework. By embedding security into design, protecting code and data, enabling runtime defenses, and embracing continuous monitoring, organizations can build apps that not only survive but thrive in hostile environments. The goal for organizations isn’t simply to mitigate risk; it’s to build digital trust. And, in an era where the mobile app is the business, trust is the most valuable asset of all. Get the holistic picture with Guardsquare ----------------------------------------- In conclusion, navigating the ever-expanding landscape of mobile app security demands a strategic mindset. As attackers grow more sophisticated and the knowledge gap widens, [CISOs must resist the extremes](https://www.guardsquare.com/blog/role-ciso-securing-mobile-applications) of attempting to build competencies in-house or surrendering entirely to vendors. The smarter path lies in owning the strategy while empowering trusted partners to execute tactics, supported by real-time visibility and actionable data. By collecting and analyzing their own intelligence and ensuring vendors provide tools that enable immediate, controlled responses, organizations can move from a state of helplessness to one of resilience. Security isn’t about knowing everything. It’s about making the right choices quickly and decisively across the app lifecycle. Own the strategy for mobile app security across the app lifecycle by partnering with Guardsquare. [Connect now](https://www.guardsquare.com/request-pricing). Tag(s): [Android](https://www.guardsquare.com/blog/tag/android) , [iOS](https://www.guardsquare.com/blog/tag/ios) , [Protection](https://www.guardsquare.com/blog/tag/protection) , [Security testing](https://www.guardsquare.com/blog/tag/security-testing) , [Threat monitoring](https://www.guardsquare.com/blog/tag/threat-monitoring) -------------------------------------------------------------------------------- title: "Secure Embedded Finance for Mobile App Developers | Guardsquare" description: "Embedded finance delivers value across the mobile ecosystem, benefiting consumers, banks, and mobile app developers. Discover how to leverage it securely." source: "https://www.guardsquare.com/blog/embedded-finance-for-mobile-apps" -------------------------------------------------------------------------------- February 18, 2025 Secure Embedded Finance: What SDK and Mobile App Developers Must Know ===================================================================== Written by: Dario Dallefrate - Product Marketing Manager Mobile apps are an integral part of daily life, powering shopping, travel, entertainment, and social interactions. Increasingly, they are also transforming financial services. Embedded finance, which refers to the integration of financial services into non-financial products and services, enables mobile app publishers to offer financial services and products to their customers without having to build their own financial infrastructure. This seamless integration enhances user engagement by allowing financial transactions without users needing to leave the app.Embedded finance is more than just a convenience; it’s reshaping customer engagement, revenue models, and financial inclusion. For banks, it presents an opportunity to expand their reach through Banking-as-a-Service by providing [SDKs](https://www.guardsquare.com/mobile-sdk-protection) to mobile app publishers willing to integrate such services.While there are many advantages, embedding financial services into non-financial apps introduces security risks. To fully leverage embedded finance, app developers need to prioritize security while also ensuring compliance and delivering an optimal user experience.This blog helps mobile app developers mitigate security risks and maximize the benefits of embedded financial services. Specifically, you will learn: * the benefits of embedded finance for customers, banks, fintechs, and mobile app publishers. * the security risks associated with embedded finance in mobile apps with a focus on embedded payments. * best practices for securely integrating SDKs into apps offering embedded finance. **The benefits** of embedded finance for the mobile app ecosystem ----------------------------------------------------------------- Embedded finance delivers value across the mobile ecosystem, benefiting consumers, banks, and mobile app publishers. Here’s how different stakeholders gain from this integration: #### Enhanced user experience for consumers For consumers, embedded finance simplifies transactions, reducing friction and making financial actions seamless. Users can access relevant financial services within the context of their transactions. For example, they can choose a "Buy Now, Pay Later" (BNPL) option at checkout or purchase travel insurance while booking airline tickets. AI-driven insights further enhance personalization, ensuring financial offerings align with user preferences and behaviors. This level of contextual and frictionless integration improves a customer’s experience and can lead to stronger brand loyalty. #### Expanding financial services beyond traditional channels [Traditional banks are evolving](https://www.guardsquare.com/blog/importance-of-mobile-banking-app-protection) as financial services become increasingly more digital. Embedded finance allows banks to integrate directly into everyday consumer experiences, extending their reach beyond traditional banking channels. Banks can seamlessly integrate their services into e-commerce, ride-sharing, travel, and social platforms. Instead of requiring users to leave an app to complete a transaction, banks can provide services at the point of need, whether it’s a loan, instant payments, or insurance. **New revenue streams for banks** Banks can monetize embedded finance by charging transaction fees on in-app payments, earning interest from in-app loans, or by offering white-label banking solutions for third-party apps. **Strengthening customer engagement & partnerships** By embedding financial services within high-engagement apps, banks remain top-of-mind while delivering personalized solutions that meet individual customer needs. Additionally, rather than competing with fintechs, banks can partner with them to scale their services while leveraging fintech innovation. For example, recently, Klarna [partnered with JPMorgan to offer its BNPL technology to JPMorgan Payments network of merchants.](https://fintechmagazine.com/articles/how-jpmorgan-klarna-forged-bnpl-partnership-for-merchants) #### Seamless financial integrations for mobile app publishers For mobile app publishers, embedded finance enhances user experience, increases revenue, and boosts customer retention. Apps across industries—e-commerce, ride-sharing, gaming, and social media— can benefit from seamless financial integrations. **Increased customer retention & lifetime value** Users engage more when financial services are seamlessly integrated. Frictionless in-app payments, embedded credit options, and personalized financial services enhance trust and satisfaction, keeping users within the platform longer. Unlocking new revenue streams Mobile app publishers can generate revenue through transaction fees from payments, BNPL, and peer-to-peer transfers, affiliate earnings from banking and insurance partners, commissions-based revenue from loans, insurance, and investment products. Enhancing user experience across industries Embedded finance improves mobile app user experience across multiple industries: * E-commerce: One-click payments, BNPL, instant credit * Ride-hailing & delivery: Integrated wallets, instant payouts, tipping * Food delivery: Loyalty rewards, meal financing, automatic tipping * Travel apps: Built-in insurance, foreign exchange, installment bookings * Social media: In-app purchases, creator tipping, peer-to-peer payments Strengthening brand loyalty & differentiation Seamless financial services create a unique competitive advantage, differentiating businesses in crowded markets. Personalized financial offerings further increase engagement and long-term loyalty. **Using SDKs** to securely embed finance in mobile apps ------------------------------------------------------- Embedding financial services into mobile apps requires SDKs, which provide pre-built tools and APIs for easy integration. Instead of building financial infrastructure from scratch, here's what mobile app developers can leverage SDKs for: * Streamlining payment processing: Enable digital wallets, credit cards, and BNPL. * Facilitating secure transactions: Ensure encryption, tokenization, and fraud prevention. * Accessing financial data: Connect to banking APIs for balance checks, transfers, and lending. * Ensuring compliance: Implement industry standards such as PSD2, PCI DSS, and GDPR. Using financial services or banking SDKs accelerates time-to-market, reduces development complexity, and enhances security. However, poorly protected SDKs can expose apps to [fraud and cyber threats.](https://www.guardsquare.com/blog/insecure-mobile-sdk-risks) **Security risks** of embedded finance in mobile apps ----------------------------------------------------- One of the most common embedded finance use cases is in-app payments. Financial transactions are a prime target for attackers, who aim to steal card data, PINs, encryption keys, and [Track2](https://en.wikipedia.org/wiki/Digital_card) information. #### Common attack methods * [Reverse engineering](https://www.guardsquare.com/blog/protecting-against-reverse-engineering)**:** Threat actors analyze the mobile app code to find vulnerabilities. * App instrumentation: After finding vulnerabilities, threat actors manipulate the app while running to extract payment data. * Intercepting sensitive data: Other threat vectors exploited by bad actors are Malware using overlay attacks or Man-in-the-middle attacks to intercept data in transit on the network or while users input it in the app. #### Real-world security risks * Misconfigured SDKs may unintentionally expose payment data. * Weak mobile app security can allow attackers to manipulate SDK functions and compromise transactions. How developers can **secure embedded finance** in mobile apps ------------------------------------------------------------- Security must be a top priority when integrating financial services into apps. Both payment SDK developers and mobile app developers play a role in protecting transactions from cyber threats. #### Security recommendations for payment SDK developers To prevent data leaks and [code manipulation:](https://www.guardsquare.com/blog/obfuscation-in-mobile-app-protection) * Secure sensitive data: Implement encryption and protect against memory dumps. * Defend against code tampering: Use runtime protection to block debugging and unauthorized modifications. * Implement app attestation: Use Play Integrity, App Attest to validate the integrity of your app before your server provides access to sensitive data * Secure communications: Enforce mutual TLS (mTLS) and datagram encryption to protect data in transit. * Detect overlay attacks: Identify malware and screen overlays to prevent PIN theft. Even with a secure SDK, app developers must: * Apply layered security: Use code obfuscation and runtime protection to prevent reverse engineering and tampering. * Ensure proper SDK design: Follow PCI DSS and other security standards. By following these best practices, both SDK developers and app publishers can create a secure embedded finance ecosystem, protecting financial data and maintaining user trust. Conclusion ---------- As mobile ecosystems evolve, embedded finance is becoming essential for digital businesses. Companies that securely integrate financial services will drive growth, customer loyalty, and new revenue streams.For banks, offering SDKs enables them to embed financial services into mobile apps, extending their reach and unlocking new revenue opportunities. For developers, implementing layered security is crucial to protecting financial data. Need guidance on how to secure embedded finance in your mobile app? [Talk to our mobile app security experts today.](https://www.guardsquare.com/request-pricing) Tag(s): [Protection](https://www.guardsquare.com/blog/tag/protection) , [Financial services](https://www.guardsquare.com/blog/tag/financial-services) , [Thought leadership](https://www.guardsquare.com/blog/tag/thought-leadership) -------------------------------------------------------------------------------- title: "Preventing Fake Mobile App Proliferation | Guardsquare" description: "Discover the dangers and mobile app security risks associated with mobile app cloning and learn how Guardsquare can help prevent fake mobile apps." source: "https://www.guardsquare.com/blog/prevent-cloning-mobile-apps" -------------------------------------------------------------------------------- April 29, 2025 Attack of the Clones: Preventing Fake Mobile App Proliferation ============================================================== Written by: Jason Cortlund - Technical Marketing Writer Somewhere in the world, you might have an evil twin that steals money, abuses the innocent, and brings shame to your name. But while most ordinary citizens don’t have to worry about this seemingly far-fetched dilemma, the “evil twin” problem is an increasingly common issue for mobile application developers. Recent headlines show how cloned apps are being widely used to spread malware, [perpetrate fraud](https://www.bbc.com/news/articles/cn05d58jwvdo), [steal private information](https://thehackernews.com/2025/04/chinese-android-phones-shipped-with.html), and even [generate ad revenue](https://www.adweek.com/media/google-pulled-200-apps-android-ad-fraud/) for cybercriminals. Without proper protections in place, the process of creating a fake mobile application is much less involved than printing counterfeit paper currency or manufacturing an ersatz Rolex watch. And the potential for criminal exploitation reaches far wider than hand-to-hand transactions. Attackers don’t even need to steal user credentials if they can convincingly impersonate a legitimate application with a cloned version. Faking it: Reverse engineering, modding, and repackaging -------------------------------------------------------- For both iOS and Android applications, piracy typically starts with [reverse engineering](https://mas.owasp.org/MASTG/0x04c-Tampering-and-Reverse-Engineering/). A legitimate mobile application is first decompiled (reversing the compiled binary into human-readable code) in order to analyze it – including its security features. An attacker can then extract sensitive information or IP from the app or SDK, such as proprietary algorithms, secrets, and keys. A malicious actor can also make sophisticated code modifications. Modding or tampering involves techniques like patching to change a mobile app and dynamically alter its behavior. One outcome could be creating a version of the app with bypassed restrictions. For example, in a [mobile gaming app](https://www.guardsquare.com/mobile-game-security), the goal may be to unlock resources (such as unlimited lives or weapons). For other types of applications, the goal is often to access paid features or premium content. Another common modding technique is code injection to insert malicious content (i.e., [malware](https://www.guardsquare.com/mobile-app-security-research-center/malware/overview)) or to bypass mobile app security features, such as adding backdoors or altering how the app communicates with backend systems. The final step in the process is repackaging the modified clone version of an app for distribution, typically aiming for one of two different malicious outcomes: * The user willingly downloads or sideloads the cloned app in order to unlock premium content for free or to bypass advertisements – as was the case with the [YouTube Vanced malware attacks](https://thecyberexpress.com/youtube-vanced-android-app-nexus-malware/). * The user unintentionally installs a corrupted mobile app in response to sophisticated social engineering, as seen in several recent [phishing attacks](https://www.securityweek.com/new-phishing-technique-bypasses-security-on-ios-and-android-to-steal-bank-credentials/). In both cases, once the user installs the corrupted clone app, it can lead to credential theft and other security issues. Stopping your mobile app “clone war” before it starts ----------------------------------------------------- Defending mobile applications against “evil twin” app impersonation requires a robust, multi-layered solution that can prevent reverse engineering and tampering. An effective software protection scheme starts with a [compiler-based solution](https://www.guardsquare.com/blog/compiler-based-mobile-app-security-vs-app-shielding) that integrates encryption and [code obfuscation](https://www.guardsquare.com/what-is-code-obfuscation), which help prevent IP theft. Obfuscation techniques scramble the code in different ways, making it difficult for the reverse engineer attacker to understand how the app functions. The addition of [runtime application self-protection (RASP)](https://www.guardsquare.com/runtime-application-self-protection-rasp?utm_source=adwords&utm_medium=ppc&utm_campaign=RL-Search-Brand-AllSolutions-AllGeos&utm_content=DexGuard&utm_term=dexguard rasp&location=&device=c&hsa_acc=2411283683&hsa_mt=p&hsa_src=g&hsa_kw=dexguard rasp&hsa_cam=21072268955&hsa_tgt=kwd-2303058245274&hsa_ver=3&hsa_ad=714755231202&hsa_grp=157444153137&hsa_net=adwords&gad_source=1&gbraid=0AAAAADf2Ion3xnveUC8vubyOWF6P8bQge&gclid=Cj0KCQjwmOm3BhC8ARIsAOSbapUR5XVxbkKeqHFy_7DIzJ7-9UviqCdIMcU6FPy26CSfaIcyKPcJE-4aAqniEALw_wcB) can dynamically monitor the app’s behavior in real time and detect tampering, modding, or jailbreak attempts. Anti-debugging capabilities can respond to an attack by terminating the app or restricting its functionality. RASP also ensures that each new build of the app has a unique set of security checks injected into different places within the code, making it much harder for a cloning threat actor to expand upon or apply any knowledge gained from previous attack attempts on newer app versions. This is a key advantage that a compiler-based approach offers over single-layer wrapper-based solutions. This kind of [multi-layered mobile app security](https://www.guardsquare.com/blog/multi-layered-mobile-app-protection) ensures that protections are constantly evolving, which provides resilience by “resetting the clock” on malicious actors. When an attacker is forced to continuously adapt to new configurations, it frustrates their ability to understand anything useful about your application. #### How Guardsquare can help Guardsquare provides [comprehensive mobile application security](https://www.guardsquare.com/what-is-mobile-app-security) across all stages of the software development lifecycle (SDLC) through products like [DexGuard](https://www.guardsquare.com/dexguard) and [iXGuard](https://www.guardsquare.com/ixguard). Many of our customers specifically chose Guardsquare to help them address problems associated with app impersonation. * A [top commercial and real estate bank](https://www.guardsquare.com/reports/pakistani-commercial-retail-bank-achieves-compliance-with-guardsquare) faced a variety of risks (financial losses, regulatory fines, brand damage) due to cloned and modified apps that enabled things like credential theft, transaction fraud, and account take-overs. * An [advanced AI tool provider](https://www.guardsquare.com/reports/advanced-ai-tool-provider-achieves-security-with-dexguard-threatcast) discovered a doppelganger app that was using their patented IP to steal private customer information. * A [video software company](https://www.guardsquare.com/reports/video-software-company-prevents-mobile-app-piracy-with-guardsquare) struggled with malicious actors copying their code and distributing an unauthorized (and unstable) free version of their app. * Developers of a popular [religious lifestyle app](https://www.guardsquare.com/reports/apac-religious-lifestyle-app-prevents-attack-with-dexguard) were losing revenue to a modified clone that let users bypass their paywall and access premium features for free. Want to learn more? [Contact us today](https://www.guardsquare.com/request-pricing). Tag(s): [Android](https://www.guardsquare.com/blog/tag/android) , [iOS](https://www.guardsquare.com/blog/tag/ios) , [Protection](https://www.guardsquare.com/blog/tag/protection) , [Thought leadership](https://www.guardsquare.com/blog/tag/thought-leadership) , [General](https://www.guardsquare.com/blog/tag/general) -------------------------------------------------------------------------------- title: "Preventing Fake Mobile App Proliferation | Guardsquare" description: "Discover the dangers and mobile app security risks associated with mobile app cloning and learn how Guardsquare can help prevent fake mobile apps." source: "https://www.guardsquare.com/blog/prevent-cloning-mobile-apps" -------------------------------------------------------------------------------- April 29, 2025 Attack of the Clones: Preventing Fake Mobile App Proliferation ============================================================== Written by: Jason Cortlund - Technical Marketing Writer Somewhere in the world, you might have an evil twin that steals money, abuses the innocent, and brings shame to your name. But while most ordinary citizens don’t have to worry about this seemingly far-fetched dilemma, the “evil twin” problem is an increasingly common issue for mobile application developers. Recent headlines show how cloned apps are being widely used to spread malware, [perpetrate fraud](https://www.bbc.com/news/articles/cn05d58jwvdo), [steal private information](https://thehackernews.com/2025/04/chinese-android-phones-shipped-with.html), and even [generate ad revenue](https://www.adweek.com/media/google-pulled-200-apps-android-ad-fraud/) for cybercriminals. Without proper protections in place, the process of creating a fake mobile application is much less involved than printing counterfeit paper currency or manufacturing an ersatz Rolex watch. And the potential for criminal exploitation reaches far wider than hand-to-hand transactions. Attackers don’t even need to steal user credentials if they can convincingly impersonate a legitimate application with a cloned version. Faking it: Reverse engineering, modding, and repackaging -------------------------------------------------------- For both iOS and Android applications, piracy typically starts with [reverse engineering](https://mas.owasp.org/MASTG/0x04c-Tampering-and-Reverse-Engineering/). A legitimate mobile application is first decompiled (reversing the compiled binary into human-readable code) in order to analyze it – including its security features. An attacker can then extract sensitive information or IP from the app or SDK, such as proprietary algorithms, secrets, and keys. A malicious actor can also make sophisticated code modifications. Modding or tampering involves techniques like patching to change a mobile app and dynamically alter its behavior. One outcome could be creating a version of the app with bypassed restrictions. For example, in a [mobile gaming app](https://www.guardsquare.com/mobile-game-security), the goal may be to unlock resources (such as unlimited lives or weapons). For other types of applications, the goal is often to access paid features or premium content. Another common modding technique is code injection to insert malicious content (i.e., [malware](https://www.guardsquare.com/mobile-app-security-research-center/malware/overview)) or to bypass mobile app security features, such as adding backdoors or altering how the app communicates with backend systems. The final step in the process is repackaging the modified clone version of an app for distribution, typically aiming for one of two different malicious outcomes: * The user willingly downloads or sideloads the cloned app in order to unlock premium content for free or to bypass advertisements – as was the case with the [YouTube Vanced malware attacks](https://thecyberexpress.com/youtube-vanced-android-app-nexus-malware/). * The user unintentionally installs a corrupted mobile app in response to sophisticated social engineering, as seen in several recent [phishing attacks](https://www.securityweek.com/new-phishing-technique-bypasses-security-on-ios-and-android-to-steal-bank-credentials/). In both cases, once the user installs the corrupted clone app, it can lead to credential theft and other security issues. Stopping your mobile app “clone war” before it starts ----------------------------------------------------- Defending mobile applications against “evil twin” app impersonation requires a robust, multi-layered solution that can prevent reverse engineering and tampering. An effective software protection scheme starts with a [compiler-based solution](https://www.guardsquare.com/blog/compiler-based-mobile-app-security-vs-app-shielding) that integrates encryption and [code obfuscation](https://www.guardsquare.com/what-is-code-obfuscation), which help prevent IP theft. Obfuscation techniques scramble the code in different ways, making it difficult for the reverse engineer attacker to understand how the app functions. The addition of [runtime application self-protection (RASP)](https://www.guardsquare.com/runtime-application-self-protection-rasp?utm_source=adwords&utm_medium=ppc&utm_campaign=RL-Search-Brand-AllSolutions-AllGeos&utm_content=DexGuard&utm_term=dexguard rasp&location=&device=c&hsa_acc=2411283683&hsa_mt=p&hsa_src=g&hsa_kw=dexguard rasp&hsa_cam=21072268955&hsa_tgt=kwd-2303058245274&hsa_ver=3&hsa_ad=714755231202&hsa_grp=157444153137&hsa_net=adwords&gad_source=1&gbraid=0AAAAADf2Ion3xnveUC8vubyOWF6P8bQge&gclid=Cj0KCQjwmOm3BhC8ARIsAOSbapUR5XVxbkKeqHFy_7DIzJ7-9UviqCdIMcU6FPy26CSfaIcyKPcJE-4aAqniEALw_wcB) can dynamically monitor the app’s behavior in real time and detect tampering, modding, or jailbreak attempts. Anti-debugging capabilities can respond to an attack by terminating the app or restricting its functionality. RASP also ensures that each new build of the app has a unique set of security checks injected into different places within the code, making it much harder for a cloning threat actor to expand upon or apply any knowledge gained from previous attack attempts on newer app versions. This is a key advantage that a compiler-based approach offers over single-layer wrapper-based solutions. This kind of [multi-layered mobile app security](https://www.guardsquare.com/blog/multi-layered-mobile-app-protection) ensures that protections are constantly evolving, which provides resilience by “resetting the clock” on malicious actors. When an attacker is forced to continuously adapt to new configurations, it frustrates their ability to understand anything useful about your application. #### How Guardsquare can help Guardsquare provides [comprehensive mobile application security](https://www.guardsquare.com/what-is-mobile-app-security) across all stages of the software development lifecycle (SDLC) through products like [DexGuard](https://www.guardsquare.com/dexguard) and [iXGuard](https://www.guardsquare.com/ixguard). Many of our customers specifically chose Guardsquare to help them address problems associated with app impersonation. * A [top commercial and real estate bank](https://www.guardsquare.com/reports/pakistani-commercial-retail-bank-achieves-compliance-with-guardsquare) faced a variety of risks (financial losses, regulatory fines, brand damage) due to cloned and modified apps that enabled things like credential theft, transaction fraud, and account take-overs. * An [advanced AI tool provider](https://www.guardsquare.com/reports/advanced-ai-tool-provider-achieves-security-with-dexguard-threatcast) discovered a doppelganger app that was using their patented IP to steal private customer information. * A [video software company](https://www.guardsquare.com/reports/video-software-company-prevents-mobile-app-piracy-with-guardsquare) struggled with malicious actors copying their code and distributing an unauthorized (and unstable) free version of their app. * Developers of a popular [religious lifestyle app](https://www.guardsquare.com/reports/apac-religious-lifestyle-app-prevents-attack-with-dexguard) were losing revenue to a modified clone that let users bypass their paywall and access premium features for free. Want to learn more? [Contact us today](https://www.guardsquare.com/request-pricing). Tag(s): [Android](https://www.guardsquare.com/blog/tag/android) , [iOS](https://www.guardsquare.com/blog/tag/ios) , [Protection](https://www.guardsquare.com/blog/tag/protection) , [Thought leadership](https://www.guardsquare.com/blog/tag/thought-leadership) , [General](https://www.guardsquare.com/blog/tag/general) -------------------------------------------------------------------------------- title: "Security Implications of Mobile App Permissions | Guardsquare" description: "Learn how developers use mobile app permissions to enhance usability while protecting the user’s privacy and trust, and the result of improper use." source: "https://www.guardsquare.com/blog/implications-of-mobile-app-permissions" -------------------------------------------------------------------------------- March 11, 2025 Security Implications of Mobile App Permissions: A Developer's Guide ==================================================================== Written by: Guardsquare How can developers responsibly and securely take advantage of permissions to improve their apps’ usability — without sacrificing user trust? On one hand, permissions allow your application to access the device's data or hardware, making the features you design functional and intuitive. Yet, when permissions are misused or over-requested, they can become a gateway to security risks, loss of user trust, and even regulatory compliance violations. The functional role of permissions in mobile app development is undeniable. For example, if you’re developing a social media platform, camera and microphone access are important for users to record videos, take photos, or connect through video calls. Permissions like these make an app feel intuitive and fully integrated into the user’s life. Others, like location data for targeted advertising, serve business interests beyond functionality. In general, developers should exercise caution when using permissions that toe the line between usefulness and invasiveness. Let’s explore some of the hidden risks of overarching permissions, along with [mobile app security best practices](https://www.guardsquare.com/blog/mobile-app-security-strategy-guide) any developer can use to mitigate these risks. **The hidden risks** of overreaching mobile app permissions ----------------------------------------------------------- While permissions may seem like technical necessities, their overuse can inadvertently expose users to privacy and security risks. One of the most prominent examples is the [Facebook-Cambridge Analytic scandal](https://www.nytimes.com/2018/04/04/us/politics/cambridge-analytica-scandal-fallout.html), where a seemingly innocuous quiz app harvested massive amounts of user data that was sold and weaponized for political profiling. Another example is the [2020 controversy surrounding TikTok](https://arstechnica.com/gadgets/2020/06/tiktok-and-53-other-ios-apps-still-snoop-your-sensitive-clipboard-data/). By requesting permissions that included clipboard access, the app drew global scrutiny over its data practices, raising questions about how much access is too much. #### Risks of specific mobile app permissions Developers should be aware of the risks of specific types of permissions. For instance, location access can, if handled poorly, reveal a user's daily patterns or physical whereabouts. This misuse has the potential to expose users to stalking or surveillance. Permissions for cameras and microphones can also lead to alarming exposures if not properly managed. Imagine a malicious actor exploiting an app with unrestricted microphone access to eavesdrop on conversations or using a camera without consent to spy on users. Similarly, contact access, which helps messaging or social networking apps function smoothly, has been misused to send spam or phishing messages to users’ entire address books. Permissions for SMS and call logs have historically been exploited to intercept two-factor authentication codes or trick users into subscribing to premium services. A prominent example of this technique is the Android [malware Joker](https://usa.kaspersky.com/resource-center/threats/joker-virus?srsltid=AfmBOopmpM-QzWZybSK1rxq5GkUq7hDTIcwjrKQjuXztGMe1RQuQRbui), which bad actors use to exploit SMS permissions to silently enroll users in premium services. #### Risks of third-party SDKs Beyond the permissions you explicitly design into your app, [third-party SDKs](https://www.guardsquare.com/blog/insecure-mobile-sdk-risks) integrated into your app can add another layer of risk. Many SDKs, such as those for analytics, advertising, or social login, introduce their own permissions or data collection practices. These SDKs may collect data beyond what is outlined in your app’s privacy policy, creating compliance risks and eroding user trust. For instance, an analytics SDK might gather location data even if your app doesn’t explicitly need it. Outdated or insecure SDKs can also create risks, leaving your app susceptible to attacks or unauthorized data access. As a developer, it’s important to ask not only whether your app’s permissions are truly necessary for its core functionality but also whether third-party SDKs you include in your app might introduce unnecessary risks. Mobile app **security best practices** to avoid permissions risks ----------------------------------------------------------------- To avoid these types of risks and more, developers play an important role in maintaining responsible permissions design and following [mobile app security](https://www.guardsquare.com/what-is-mobile-app-security) best practices. Here are a few ways to keep your apps compliant and your users safe: * Adhere to the principle of least privilege: Only request permissions essential to your app’s functionality. For example, if you’re developing a photo editing app, it doesn’t need access to call logs or contacts to perform its core tasks. * Implement granular permissions: Modern APIs now allow you to implement granular permissions, where requests are made incrementally and contextually. Instead of asking for every permission upfront, you can prompt users only when a feature requiring that permission is actively being used. * Educate users: Provide in-app prompts, onboarding tutorials, and clear, concise privacy policies to educate users about why your app needs certain permissions. * Use operating system tools: If you’re working with Android, the [Google Play Console](https://play.google.com/console/about/whats-new/?_gl=1*1lea8wb*_up*MQ..&gclid=CjwKCAiAkc28BhB0EiwAM001TaIkMQKxF_uKci1OOKzwgLq2LfGvVSLn7PYgaB-a6K37Nc6EJrZSyxoCN10QAvD_BwE&gbraid=0AAAAACbC-VJWrKdZfh76PfhZX83Z6hcYv) provides insights into permission usage over time. On iOS, [privacy reports](https://support.apple.com/en-us/102188#:~:text=In Settings, tap Privacy & Security,report data from your device.) offer a way to analyze how your app accesses sensitive data. * Audit and check permissions risks: [Lint tools](https://en.wikipedia.org/wiki/Lint_(software)) can identify unnecessary permissions in your code. Static analysis tools can also identify risks related to permissions. * Improve your app’s overall security: Use the [OWASP](https://www.guardsquare.com/owasp-masvs-better-protection-mobile-app) Mobile Security Testing Guide ([MASTG](https://mas.owasp.org/MASTG/)) as a framework for assessing your app’s security. Third-party [mobile app security testing](https://www.guardsquare.com/what-is-mobile-application-security-testing) tools like [AppSweep](https://www.guardsquare.com/appsweep-mobile-application-security-testing) from Guardsquare map closely to OWASP guidelines, reducing the overall risk of tampering and reverse engineering. In addition, a combination of [code hardening](https://www.guardsquare.com/code-hardening), [runtime application self-protection](https://www.guardsquare.com/runtime-application-self-protection-rasp) (RASP), and ongoing [threat monitoring](https://www.guardsquare.com/threat-monitoring) can keep your app secure throughout the entire development lifecycle. **The future** of mobile app permissions and security ----------------------------------------------------- As privacy regulations like GDPR and CCPA become more stringent, app developers are under increasing pressure to design systems that prioritize user privacy. These regulations emphasize data minimization, requiring apps to collect only the information they absolutely need to function. Non-compliance can lead to steep fines, but more importantly, it can erode user trust and damage your brand reputation. Looking to the future, trends such as adaptive permissions and privacy dashboards are also emerging as best practices. Adaptive permissions dynamically adjust based on user behavior, offering a more tailored and secure experience. Privacy dashboards, now commonplace on both Android and iOS, provide real-time insights into how permissions are being used, empowering users and developers alike to make informed decisions. Zero-permission apps are also gaining traction. These rely on [secure APIs](https://www.guardsquare.com/blog/keeping-up-with-api-security-best-practices-guardsquare) to access data without requiring direct permissions from users, reducing the risk of misuse. Decentralized data storage is another innovative approach, keeping sensitive user information out of app ecosystems entirely. Regardless of the approach you choose to adopt, the permissions your app requests should be carefully considered, transparently explained and securely managed. In addition, by improving your app’s overall risk of reverse-engineering or tampering, you can create trustworthy apps that users love. Ultimately, responsible and secure design isn’t just about compliance—it’s about building a foundation of trust with your users. In a world where privacy concerns run rampant, your app can stand out from the competition by demonstrating that end-to-end security is a core value. Want to learn more about preventing mobile app security risks? Get the report: [Assessing Mobile App Security](https://www.guardsquare.com/report/mobile-application-security-report) Tag(s): [Android](https://www.guardsquare.com/blog/tag/android) , [iOS](https://www.guardsquare.com/blog/tag/ios) , [Compliance](https://www.guardsquare.com/blog/tag/compliance) , [Thought leadership](https://www.guardsquare.com/blog/tag/thought-leadership) -------------------------------------------------------------------------------- title: "A Shift in the Mobile App Security Mindset from Reactive to Proactive | Guardsquare" description: "Shift from reactive to proactive mobile app security with Guardsquare’s guided workflow & compiler-based approach. Explore the new era of mobile AppSec." source: "https://www.guardsquare.com/blog/a-shift-in-mobile-app-security-mindset-from-reactive-to-proactive-guardsquare" -------------------------------------------------------------------------------- April 8, 2025 A Shift in the Mobile App Security Mindset from Reactive to Proactive ===================================================================== Written by: Jija Bhattacharya - Product Marketing Manager In an era where mobile applications power our daily lives, from seamless financial transactions to safeguarding personal health data and enabling secure communications, their importance is undeniable. Yet, with this growing reliance comes an ever-increasing threat landscape. Cybercriminals are adapting at an alarming rate, leveraging new techniques to take advantage of security gaps faster than developers can patch them. The battle for mobile app security is no longer just a technical challenge; it’s a high-stakes race against evolving cyber threats, where the cost of failure is steep and the margin for error is limited. Security is no longer an afterthought or an optional add-on. The demand for proactive fraud prevention is surging, with [82.4%](https://www.guardsquare.com/report/mobile-application-security-report) of consumers preferring robust security measures over post-breach remedies. Users no longer trust businesses that scramble to fix vulnerabilities after an attack—they expect security to be ingrained from the outset. This shift in expectations has put immense pressure on developers and security teams to deliver airtight protection without compromising app performance or the development timeline. However, the challenge remains: how can development teams—many of whom lack deep cybersecurity expertise—implement robust security measures without slowing down innovation? Guardsquare has answered this call with a [guided workflow](https://www.guardsquare.com/mobile-app-protection-guided-workflow) that transforms [mobile app security](https://www.guardsquare.com/what-is-mobile-app-security) from a complex burden into a seamless, intuitive process. Security without compromise in less than a day ---------------------------------------------- Traditionally, [mobile application protection](https://www.guardsquare.com/what-is-mobile-application-protection) has often required developers to make trade-offs between security, performance, and ease of integration. Some solutions rely on [third-party SDKs](https://www.guardsquare.com/blog/insecure-mobile-sdk-risks) that can introduce serious security gaps, while others encrypt the entire codebase into a binary blob, essentially wrapping your code with a single layer of protection, leaving a single point of failure to be easily exposed to the attacker. Guardsquare’s compiler-based approach eliminates these concerns by embedding security directly into an application’s code at the compilation stage. A [compiler-based approach](https://www.guardsquare.com/blog/multi-layered-mobile-app-protection) is crucial for implementing effective [code obfuscation](https://www.guardsquare.com/what-is-code-obfuscation). Guardsquare’s method mirrors the functionality of a compiler by directly modifying the code rather than encapsulating the code with a simple layer of protection. Because compilers inherently regenerate an application's code, they offer an optimal foundation for seamlessly integrating security measures. This enables sophisticated code analysis and transformation techniques, making it a key component of modern software protection. One of the primary benefits of compiler-based obfuscation is its ability to introduce randomized variations in code semantics, structure, and placement with minimal developer effort. This technology enables implementing multiple layers of protection, ensuring: * **Resilience against reverse engineering with adaptive protection:** By applying polymorphic obfuscation, every build is unique, making it significantly harder for attackers to analyze and manipulate code. * **Defense in depth:** Various security measures, including obfuscation techniques and automatic [runtime application self-protection (RASP)](https://www.guardsquare.com/runtime-application-self-protection-rasp), work together to provide holistic security coverage. * **Seamless performance:** Unlike traditional security methods that may impact app speed or responsiveness, Guardsquare’s compiler-based approach ensures that security does not come at the cost of performance. But the most groundbreaking aspect of the guided workflow is its ease of implementation - in less than a day, organizations can achieve market-leading protection. Simplifying security with the guided workflow --------------------------------------------- One of the biggest obstacles to implementing robust mobile app security has historically been complexity. Even seasoned developers often struggle to configure security settings optimally, leading to gaps in protection. Guardsquare’s guided workflow changes the game by providing an intuitive experience that simplifies security implementation while maintaining flexibility. #### How the guided configuration works: 1. **Instrument and profile for precision** * Before applying protection, Guardsquare’s guided workflow helps developers instrument their app to collect critical metadata about your application (e.g. names of classes, methods, strings). Unlike other solutions that require uploading your unprotected app to external servers, Guardsquare’s processing occurs entirely within your local development environment or CI system, ensuring your source code and sensitive binaries remain secure and private. * This profiling phase identifies performance-sensitive areas and ensures that security measures do not introduce unintended instability or slowdowns. 2. **Apply layered security without guesswork** * Developers can select protection settings based on real insights rather than trial and error. * The guided workflow helps ensure the proper security techniques are applied exactly where they are needed, removing the need to compromise on security and performance. 3. **Gain continuous visibility and threat intelligence** * Guardsquare provides clear visibility into security implementations and past builds, allowing developers to track protection history. * Integrated [threat monitoring](https://www.guardsquare.com/threat-monitoring) ensures that security remains an ongoing, proactive process rather than a one-time implementation. By taking the guesswork out of security, Guardsquare enables development teams to focus on what they do best—building high-performing apps while ensuring their applications are protected against emerging threats. Stability meets security without compromise ------------------------------------------- A common concern among developers is that rigorous security measures could introduce performance issues or app instability. Reflection-heavy code, in particular, is notoriously susceptible to problems when subjected to aggressive obfuscation. Guardsquare addresses this challenge head-on through meticulous instrumentation and profiling. By analyzing an app’s execution paths and identifying reflection-heavy areas, Guardsquare ensures that security measures do not interfere with the app’s core functionality. This means developers no longer have to choose between stability and security—they can have both. Moreover, runtime protection techniques such as RASP can be fine-tuned to avoid unnecessary strain on an application. By leveraging profiling data, Guardsquare ensures that runtime security mechanisms do not disrupt performance-critical sections of the app. This tailored strategy guarantees that security remains effective without compromising user experience and is unique to your app. RASP: The final line of defense ------------------------------- While obfuscation strengthens an app’s defenses against static analysis and reverse engineering, runtime protections are essential to combat dynamic attacks. Guardsquare’s [automatic RASP capabilities](https://www.guardsquare.com/blog/rasp-solution-key-features) take this defense a step further by actively monitoring the app’s execution environment and suspicious activity in real time, strengthening your mobile app’s defenses and building a proactive security ecosystem. Through Guardsquare’s guided workflow, developers can: * **Enable a wide range of runtime protections:** detect debuggers, hooking frameworks, and emulators among others, that attackers may use. * **Customize threat responses:** Decide whether to terminate the app, log the incident, or alert a backend monitoring system. * **Gain actionable insights:** Use threat intelligence to understand attack patterns and reinforce defenses over time. By integrating RASP seamlessly into the development workflow, Guardsquare ensures that mobile apps are protected not only at the code level but also in live execution environments. From complexity to confidence: How Guardsquare’s guided workflow is redefining mobile app security -------------------------------------------------------------------------------------------------- For too long, mobile app security has been reactive—addressing breaches after they occur rather than deterring them. Guardsquare’s guided workflow marks a shift toward a proactive security mindset, making it easier than ever for developers to build secure applications from the ground up. The guided workflow benefits businesses and consumers alike: * **For developers:** It reduces the learning curve associated with security implementation, allowing teams to deploy the best mobile app protection in the market in less than a day. * **For security teams:** It provides visibility into security measures and threat activity, enabling better collaboration between development and security functions. * **For consumers:** It delivers the peace of mind that comes with knowing their data is protected by security measures that are integrated, tested, and continuously monitored. Secure by design, ready for the future -------------------------------------- As mobile threats continue to evolve, app security can no longer be an afterthought. Guardsquare’s guided workflow ensures that security is not only robust but also accessible, enabling every developer—regardless of their security expertise—to build secure applications with confidence. With a compiler-based approach, instrumentation-driven stability, and seamlessly integrated obfuscation techniques and RASP protections, Guardsquare is redefining mobile app security. It’s not just about adding security features; it’s about embedding security into the very fabric of mobile applications. Developers no longer need to choose between ease of use and the highest level of security. With Guardsquare, they can have both effortlessly. Ready to make mobile app security effortless? [Start with Guardsquare today](https://www.guardsquare.com/request-pricing). Tag(s): [Android](https://www.guardsquare.com/blog/tag/android) , [iOS](https://www.guardsquare.com/blog/tag/ios) , [Protection](https://www.guardsquare.com/blog/tag/protection) , [Dexguard](https://www.guardsquare.com/blog/tag/dexguard) , [iXGuard](https://www.guardsquare.com/blog/tag/ixguard) -------------------------------------------------------------------------------- title: "Is Your Mobile App Secure? | Guardsquare" description: "A secure backend server does not equate to a secure mobile app. Discover the mobile app security threats risking your application's environment." source: "https://www.guardsquare.com/blog/secure-mobile-app-server" -------------------------------------------------------------------------------- Your Server May Be Secure, but Is Your Mobile App? ================================================== Written by: Guardsquare You’ve locked down your backend - authentication is solid, APIs are protected, and your latest pentest came back clean. From a server-side perspective, everything looks secure. But there’s a critical blindspot that many development teams overlook: the mobile app itself. Today’s mobile apps are a front door to your system, and attackers know it. In fact, mobile apps are often the weakest link in otherwise robust security environments. Why? Because they sit in the hands of users, not in your data center. Unlike your backend infrastructure, your mobile app security relies on an untrusted environment - devices you don’t control, exposed to tools and techniques specifically designed to exploit them. From [reverse engineering to malicious app clones](https://www.guardsquare.com/mobile-sdk-protection), mobile app threats are rising fast. And while these attacks may not make the headlines like massive data breaches, they can silently expose sensitive data, compromise trust, and erode business value. Let’s explore why hardened servers aren’t enough, and what it really takes to protect your mobile app in the wild. Why server-side mobile application security isn’t the whole story ----------------------------------------------------------------- Authentication and authorization are foundational. They protect your APIs, validate users, and gate access to sensitive data. But they assume the client — the app itself — is trustworthy. That assumption doesn’t hold in today’s mobile landscape. Your mobile app runs in unpredictable environments. It’s downloaded to personal devices, modified by users, and [targeted by attackers](https://www.guardsquare.com/blog/four-phases-of-a-mobile-application-attack) looking for ways to bypass your controls. Even when the server is secure, the app becomes an easy entry point. What’s often overlooked is this: every user action begins and ends on the mobile app. That makes the front-end not just a feature delivery vehicle — but a live, vulnerable interface to your entire system. Mobile apps are prime targets: Here’s why ----------------------------------------- Mobile apps combine valuable data with limited defenses. Unlike servers protected by firewalls and monitored 24/7, mobile apps live outside the corporate perimeter. Here are just a few reasons they attract attackers: * **User diversity:** From tech-savvy teenagers to less experienced users, mobile apps must serve everyone. That opens the door to social engineering. * **Client-side control:** Apps handle decrypted data, interface logic, and inputs — often without runtime protections. * **Limited security investment:** Security teams focus on infrastructure. Mobile is often treated as a product feature, not an attack surface. The result? A perfect storm of access, oversight, and opportunity for attackers. Real-world mobile app attacks ----------------------------- Server breaches may grab headlines, but some of the most damaging attacks today begin at the app level. Below are real-world examples that show how malicious actors exploit mobile apps — and what businesses stand to lose when [mobile app security](https://www.guardsquare.com/what-is-mobile-app-security) is an afterthought. 1. Modified versions of legitimate mobile apps often start as harmless enhancements. Users seek out ad-free experiences or to unlock premium features for free.But these "mods" can:A popular example is [YouTube Vanced](https://arstechnica.com/gadgets/2022/03/google-shuts-down-youtube-vanced-a-popular-ad-blocking-android-app/), a modded version of the YouTube app that removes ads and unlocks premium features for free. It gained millions of users before being shut down. While the mod offered users a better experience, it undercut YouTube’s monetization model and opened users to potential malware hidden in unofficial distributions.What seems like a win for the user is a loss for the business — revenue, security, and user trust all take a hit. * Introduce [malware](https://www.guardsquare.com/mobile-app-security-research-center/malware/overview) * Steal user credentials * Undermine monetization models 2. Clones of popular mobile apps appear nearly identical to the real thing. Distributed through unofficial channels like messaging apps or rogue websites, they:For example, clones of legitimate fintech and mobile banking apps — often distributed via messaging apps — collect sensitive user data like passwords or crypto wallet keys. One [real-world case](https://www.guardsquare.com/webinar/on-demand/my-server-is-secure-why-should-i-bother-protecting-my-mobile-app) involved clones of a popular mobile wallet that looked identical to the original. Users entered their credentials, unknowingly handing access to attackers.Since many are built by [tampering](https://www.guardsquare.com/blog/mobile-app-tampering) with the original app, clones behave normally until they steal what they came for. The impact of mobile app security threats on your business can include brand damage, loss of user trust, and customer churn. * Harvest login credentials * Capture crypto wallet keys * Relay sensitive inputs to attackers 3. Without code hardening, bad actors can decompile and analyze your mobile app. Attackers use this to:Some even automate API calls for data scraping or abuse premium services, costing you control and increasing infrastructure strain.For example, an open-source alternative Instagram client gained popularity by offering enhanced features and cross-platform compatibility. However, it scraped user data and violated API terms. [Meta responded](https://www.nixonpeabody.com/insights/articles/2021/12/23/meta-attempts-to-stop-scraping-of-instagram-user-data) with bans and legal action — but only after significant reputational and technical damage. * Discover private APIs * Reconstruct communication protocols * Build unauthorized third-party clients 4. Mobile authentication isn’t foolproof. With deepfakes and operating system tampering, attackers can:The device may think it’s verifying a legitimate user when it’s not. Some mobile app attackers now combine [AI deepfake technology](https://www.forbes.com/sites/daveywinder/2024/12/04/ai-bypasses-biometric-security-in-1385-million-financial-fraud-risk/) with OS-level tampering to fool facial recognition systems. In one scenario, a spoofed biometric scan allowed unauthorized access to a banking app, bypassing identity checks entirely. If your business is exposed to this type of attack, you risk reputational damage, regulatory exposure, and user churn. * Spoof facial recognition systems * Trick biometric checks * Circumvent identity-based security Best practices to protect your mobile app ----------------------------------------- You can’t completely secure what you don’t control, but you can significantly reduce the risk. Here's how to build a stronger mobile app security posture: 1. Attackers often start by trying to understand how your mobile app works. If they can reverse engineer your app, they can extract secrets, understand API calls, bypass security controls, or even create counterfeit versions of your application.To prevent this, developers need to apply [code hardening](https://www.guardsquare.com/code-hardening) techniques — security measures that make your code more difficult to analyze or manipulate, even if an attacker gains access to the application package (APK or IPA, depending on your mobile OS). Here are a few key techniques to consider: * Obfuscation: [Code obfuscation](https://www.guardsquare.com/what-is-code-obfuscation) transforms your source code into a version that’s functionally identical but difficult to interpret. This includes renaming classes, methods, and variables into meaningless strings, removing structure, and flattening logic. * Encryption: Encryption ensures the code of the application and the data it contains cannot be accessed while the application is at rest. The encrypted code is decrypted on-the-fly when the mobile application is executed ensuring that it functions as intended. To be effective, the encryption must be applied in various layers. 2. Even the most secure mobile apps can be compromised once they’re running on a device. That’s where [Runtime application self-protection (RASP)](https://www.guardsquare.com/runtime-application-self-protection-rasp) comes in. RASP operates from within the app itself, monitoring for suspicious activity and responding in real time.RASP is essential because mobile apps run in untrusted environments — on devices you don’t control, across countless OS versions, with varying levels of security hygiene. Without runtime protection, your app is blind to active threats like debugging, hooking, or root-level tampering.Here’s how RASP helps: * **Debugging attempts:** RASP detects when someone tries to [attach a debugger](https://www.guardsquare.com/blog/addressing-static-and-dynamic-attacks) to your running app, which is a common technique used to analyze behavior or bypass controls. * **Hooking frameworks:** [Hooking tools](https://www.guardsquare.com/video/what-is-hooking) (like Frida or Xposed) allow attackers to intercept and manipulate function calls at runtime. * **Rooted or jailbroken environments:** RASP identifies when your app is running on a [rooted (Android) or jailbroken (iOS) device](https://www.guardsquare.com/blog/what-rooting-and-jailbreaking), where OS-level protections have been removed. 3. Many mobile app attacks piggyback on [insecure SDKs](https://www.guardsquare.com/blog/insecure-mobile-sdk-risks). Ensure every library is vetted, necessary, and maintained. Even if your app is secure, a vulnerable or outdated SDK can create a backdoor for attackers. These libraries often have access to network, storage, and permissions — meaning their weaknesses become your liabilities. 4. Security isn’t just about systems. It’s about people, devices, and the entire operational flow. [Real-time threat monitoring](https://www.guardsquare.com/threat-monitoring) and [regular mobile app security testing](https://www.guardsquare.com/what-is-mobile-application-security-testing) can proactively mitigate mobile app security incidents — protecting both your business and your users. Securing your server isn’t enough: Secure the experience -------------------------------------------------------- Attackers aren’t trying to beat your backend, they’re going around it. Mobile apps represent a direct line to the user and to your system. Unprotected mobile applications become the weakest link. Yes, server-side security matters, but it’s just the beginning. You need to extend your mobile app protection to the devices in your users’ hands. That means thinking beyond authentication and investing in runtime defense, code hardening, and threat-aware development practices. In mobile environments, trust is earned through experience. If your app feels vulnerable, your brand does too. **Want to learn more about protecting against these mobile app security threats?** [**Watch our Dark Reading webinar on-demand**](https://www.guardsquare.com/webinar/on-demand/my-server-is-secure-why-should-i-bother-protecting-my-mobile-app)Tag(s): [Android](https://www.guardsquare.com/blog/tag/android) , [iOS](https://www.guardsquare.com/blog/tag/ios) , [Protection](https://www.guardsquare.com/blog/tag/protection) , [Financial services](https://www.guardsquare.com/blog/tag/financial-services) , [Thought leadership](https://www.guardsquare.com/blog/tag/thought-leadership) -------------------------------------------------------------------------------- title: "How to Complement Mobile Application Pentesting | Guardsquare" description: "Discover how to complement mobile application pentesting with other strategies to maintain regulation compliance and improve your mobile app security." source: "https://www.guardsquare.com/blog/complement-mobile-app-pentesting" -------------------------------------------------------------------------------- February 4, 2025 How to Complement Mobile Application Pentesting to Maintain Compliance ====================================================================== Written by: Michael Olechna - Product Marketing Manager Governments and industries have set up regulations and requirements to protect consumers’ and application data from increasing malicious attacks. Some, like GDPR, have been around for years, while others, like the [Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act), have gone into effect as recently as last year. Security analysts create detailed requirements based on regulations, including best practice recommendations from organizations like [OWASP](https://www.guardsquare.com/owasp-masvs-better-protection-mobile-app). These requirements are then passed to development teams, who must ensure compliance while building secure mobile apps. At the same time, development teams face mounting pressure to deliver timely releases in an ever-evolving threat landscape. To address the need for security, compliance, and speed, many teams are adopting a “shift-left” approach, integrating security testing earlier into the software development lifecycle (SDLC). However, they must still comply with regulatory requirements. This is why mobile application penetration testing plays a crucial role. In short, a penetration test, or pentest, simulates a real-world attack on your mobile app. It is usually performed by a security researcher that will conduct a review of your app and employ sophisticated attacks to identify weaknesses and vulnerabilities in your mobile application. Many regulatory bodies will require a pentest to maintain compliance, but it is a general rule to conduct pentesting on an annual or semi-annual basis, or prior to a significant release. So, we know pentesting mobile apps helps identify weaknesses and vulnerabilities before they can be exploited by malicious actors. But where does pentesting fall short? What doesn’t it cover? We’ll discuss that and more, like how to achieve compliance using a combination of pentesting, [mobile application security testing](https://www.guardsquare.com/what-is-mobile-application-security-testing), and monitoring. **What** is pentesting for mobile apps? --------------------------------------- [Mobile app pentesting](https://www.guardsquare.com/blog/the-difference-between-mobile-app-security-testing-and-pen-testing-and-why-you-need-both) is a testing method to identify security vulnerabilities in mobile applications that could potentially be exploited by threat actors. When threat actors exploit these vulnerabilities, they’re able to access sensitive data or tamper with an application. After gaining access, these malicious actors can use the data to accomplish their nefarious intentions. The goal of pentesting is to identify, analyze, and fix these weaknesses or vulnerabilities before they are exploited by malicious actors. Some common vulnerabilities that a pentest may check are improper credential usage, insecure communication, and inadequate privacy controls. The [OWASP Top 10 Mobile Risks for 2024](https://owasp.org/www-project-mobile-top-10/) is a great starting point to begin understanding the vulnerabilities you should be seeking to uncover during your pentests. The exact scope of your pentest should be based on establishing a clear definition of the kind of risks you are looking to mitigate. **Why** conduct pentesting? --------------------------- Not all mobile apps require pentesting, but many should strongly consider it. Especially those in well-regulated industries. Apps that handle financial or sensitive personal data - such as [mobile health apps](https://www.guardsquare.com/mobile-appsec-for-healthcare), [financial services](https://www.guardsquare.com/mobile-appsec-for-healthcare), insurance apps, and retail apps that process payments - are prime candidates. The industries these apps fall under often will have their own standards and regulations, which may require security protections for the app such as [anti-tampering](https://www.guardsquare.com/blog/why-all-mobile-apps-need-anti-tampering-protection) and [obfuscation](https://www.guardsquare.com/what-is-code-obfuscation) requirements. But, they’re not the only ones that should embrace pentesting. Similar to regulations, some apps may need to achieve certain certifications to compete in the market. Payment acquisition applications are a great example. Certain industry groups like PCI or EMVCo require developers of these apps to undergo a security evaluation with [compliance requirements](https://www.guardsquare.com/blog/navigate-pci-mpoc-compliance) in order to go to market. Another common driver for mobile app pentesting is cyber insurance requirements. The rise of cyber attacks has spurred the adoption of cyber insurance protection. In order to obtain their cyber insurance, these firms require app developers to conduct pentesting to identify security vulnerabilities and risks. Which brings us to our last common driver of pentesting: identifying risks and security vulnerabilities, including a privacy and security evaluation of an app. We’ll discuss this driver in greater detail later on, but one of the main benefits of pentesting is staying ahead of cyber threats. Preemptive testing can identify potential risks and vulnerabilities prior to release, preventing monetary losses, damaged brand reputation, regulatory fines, and development setbacks. Pentesting **costs & scope** ---------------------------- After identifying the drivers, the next step is to begin the pentesting process. The first step is examining the ways and means of how to go about your pentest. You can go with a pentesting service, which is quite common but can get expensive quickly, since these testing efforts involve manual effort, writing reports and are done on a periodic basis. [Average estimates range from $5,000 to $15,000](https://www.securitymetrics.com/blog/how-much-does-pentest-cost#:~:text=A high-quality, professional penetration,can easily reach beyond $30,000.) per pen test, with some tests surpassing $30,000. You can also go with a Do It Yourself approach by bringing your pentests in-house, but this should be reserved for those with past experience or extensive resources. Even with past experience, the DIY cost savings may not cover the time and effort to build then carry out pentests compared to a reputable pentesting service. For instance, if you do not have an internal pentesting team, you’ll have to hire an experienced security researcher. The security researcher will also need an extensive tool suite to conduct proper analysis, further increasing costs. While over time you may come out ahead, the length of time to achieve these savings may be impractical, especially when working within a short timeframe. As price depends on several factors, so does the level of pentesting your app may require. The complexity of your app is a major cost driver. A simpler app with only a few functions is much easier to test than an intricate app that has many integrations and connects with other systems. Other cost drivers include the depth of the analysis done by the pentesters and their expertise. In-depth tests will mimic [real-world attack scenarios](https://www.guardsquare.com/blog/four-phases-of-a-mobile-application-attack) of malicious actors trying to break your application. Meanwhile, a test that does a few quick checks is much easier to build, and, therefore, less expensive, but is also much less thorough. Finally, this all comes to the level of expertise of the pentester. While more costly, a reputable pentesting firm will have experience with many different scenarios and varying levels of complexity. If your app requires a complicated test, these high-expertise firms are your best bet. What are **the goals** of pentesting? ------------------------------------- Pentesting seeks to pinpoint vulnerabilities within mobile apps prior to release. But there are other goals developers seek by pentesting their apps. For one, it is a great way to stay one step ahead of cyber threats. Conducting a pen test also helps assess the damage that could occur from a potential breach. Just as pentesting can identify potential threats, it also tells teams where high-risk areas exist so they can bolster their mobile app’s defenses. Finally, one of the most common goals for pentesting is to achieve compliance for your mobile app. In short, teams will engage specialized pentesting firms who are trained and approved to perform compliance or certification efforts on behalf of industry or regulatory bodies. There are many regulatory bodies with specific requirements for apps within their jurisdiction. We mentioned some above (EMVco, PCI). These bodies will often have vulnerability assessment and penetration testing as a requirement listed in their compliance regulatory framework, with certification typically only performed by approved labs. Pentesting **methodology** -------------------------- The methodology of pentesting can be broken down into a four step process: reconnaissance, analysis and evaluation, exploitation, and reporting. #### Reconnaissance Reconnaissance, or discovery, is the base for the entire pentesting process. This can be thought of as intelligence gathering. Typically the pen tester will decompile your mobile application binary to the original source code to perform static analysis. By using various tools and techniques, they can pinpoint vulnerabilities like insecure coding practices or hardcoded credentials in-app. They’ll also check to see if data is properly encrypted and stored to avoid data leaks. #### Analysis & evaluation The next step is to begin assessing the application before and after installation on to the device. The pentesting firm will review interactions with your mobile app. This includes communication with backend servers as well as sending and receiving data through HTTP requests. Their analysis will be more in-depth at this stage, examining how your app handles data in transit or interacts with other apps on the mobile device. #### Exploitation Next, the pentesting service will move from reviewing mobile app interactions to testing app interactions. Using the vulnerabilities that have been identified, the pentesters will simulate further real-world attacks on the application. [Attacks like injecting malicious payloads](https://www.guardsquare.com/blog/guardsquare-reveals-security-vulnerabilities-from-penetration-testing-several-pix-enabled-mobile-apps-guardsquare) using rooting or shell exploits are performed on the application. Other parts of the app that may be tested are authentication flaws, any cloud misconfigurations, or issues with access control. The response of the app and its behavior will inform the pentester how the mobile app handles these types of attacks. #### Reporting After a pen test, security experts will prepare a pen test report. The report will document any vulnerabilities identified during the test and provide recommendations for next steps. This is an opportunity to identify where the app needs improvements and close security gaps. Without doing so, it is unlikely the app will achieve the necessary compliance requirements. A good quality pentest report will not just demonstrate that a vulnerability exists, but will also explain the consequences and why it is relevant to your app or business. **Benefits** of pentesting -------------------------- As you’ve probably guessed by now, there are many benefits to pentesting, one of which is achieving compliance requirements. With pentesting, weaknesses in your mobile app security can be identified and made secure before a malicious actor has a chance to exploit it. Developers and security teams alike are able to [optimize security systems](https://www.guardsquare.com/blog/three-tips-optimize-your-security-risk-assessments). This is critical as not only new regulations come into law, but also helps fight the constantly evolving digital threat landscape. #### Optimized security Carrying out regular pentests helps organizations stay one step ahead of threats and bad actors. Pentesting on a regular basis makes it easier to pinpoint weaknesses and vulnerabilities in an evolving threat landscape. #### Fix security weaknesses & vulnerabilities Identifying weak points and vulnerable areas of your app is one thing. A pentest report will deliver additional context and details so you can prioritize fixing these areas of your app first. Strengthening these areas will boost [mobile app security](https://www.guardsquare.com/what-is-mobile-app-security) and optimize your apps defenses. #### Prep for security audits Finally, many of the regulations we have mentioned require a security audit by law. You can think of this as the “big exam”. The healthcare and finance industries are two of the primary industries that will require a security audit. Failing an audit can come with negative ramifications, such as non-compliance fines. Pen tests not only prepare for the audit, but helps orgs know where potential failure may occur so they can avoid any fines. You can see the benefits to pentesting are apparent. But what about the app security pentesting doesn’t cover? And what should you do when a pen test fails? Where pentesting **falls short** -------------------------------- Pentesting offers significant benefits, but it has limitations. A primary challenge is its reliance on seasoned security experts to conduct tests and analyze results. Unfortunately, not all organizations have access to such resources, and hiring a third party can be costly. The costs of pentesting can rise quickly over time due to reliance on external teams and resources. It may also drag out tests as scheduling and coordination difficulties may arise. Add in new test iterations and review cycles, and we can clearly see the exposure to costly delays. This raises a key question: how can organizations meet compliance goals without relying solely on expensive, expert-driven testing? The answer lies in adopting low-barrier security protocols across development teams. For many development teams, security expertise isn’t readily available. Mobile app development is prioritized above all else, which can lead to security protocols being overlooked until critical moments- like an audit or release- trigger a last-minute scramble for compliance. Rather than focusing on a specific event at a moment in time, adding multiple layers of protection throughout your app’s code and testing each layer as you build is preferable. [Mobile app security testing, or MAST](https://www.guardsquare.com/blog/mobile-application-security-testing-for-developers), is an example of continuous testing. It involves a series of automated techniques and tools to assist development teams in their quest to discover broad, scalable security vulnerabilities. When paired with pentesting, this approach creates a comprehensive and balanced [mobile app security strategy](https://www.guardsquare.com/blog/mobile-app-security-strategy-guide), addressing both broad vulnerabilities and specific threats. **A comprehensive approach** to mobile app security --------------------------------------------------- Pentesting and having dedicated security experts are invaluable, but coupled with a MAST tool can elevate the security expertise of the entire development team. With MAST, developers gain actionable metrics to evaluate their mobile apps independently, reducing overreliance on security experts. This shift makes it much easier to identify and fix potential security risks, creating a [proactive approach](https://www.guardsquare.com/blog/3-essential-stages-for-shifting-mobile-app-security-from-reactive-to-proactive), rather than reacting to security issues after they occur. MAST can also integrate into your development workflow. Many MAST tools have integrations with [Github](https://www.guardsquare.com/blog/integrating-appsweep-and-github-to-automate-your-mobile-app-security-testing) and similar platforms. Developers can integrate security protocols across their development lifecycle, which makes it easier to achieve compliance and not be blindsided by the results of failed pentest or audit. It is also very easy to get started, with plenty of external resources readily available. The [OWASP MAS](https://mas.owasp.org/), which has openly shared security standards, is a fantastic place to begin when looking for guidance. While pentesting simulates real-world attacks, it typically occurs infrequently - maybe once per year. In contrast, MAST offers continuous testing, identifies vulnerabilities before each release, integrates directly into the development lifecycle and attempts to catch issues prior to release. A best practice is to conduct annual pentesting and implement MAST before each release of your app. #### Pentesting for optimized mobile app security Pentesting mobile apps is a necessary and important part of mobile app security. For apps in industries like healthcare and financial services, it is an essential part of obtaining compliance from regulatory bodies. For others, it is a fantastic way to identify and fix security risks in your apps and systems before bad actors have a chance to exploit them. But, as stated above, pentesting may not be accessible to everyone. A pen test report also gives the status of your mobile app at a particular point in time, rather than providing real-time security vulnerabilities that can be achieved via automated testing or [threat monitoring](https://www.guardsquare.com/threat-monitoring). To achieve a broader, more scalable approach, pentesting is best when paired with these tactics. Learn more about developer-focused tools like Guardsquare’s [AppSweep](https://www.guardsquare.com/appsweep-mobile-application-security-testing), a free mobile testing solution that can be integrated into your development lifecycle. Tag(s): [AppSweep](https://www.guardsquare.com/blog/tag/appsweep) , [Healthcare](https://www.guardsquare.com/blog/tag/healthcare) , [Security testing](https://www.guardsquare.com/blog/tag/security-testing) , [Financial services](https://www.guardsquare.com/blog/tag/financial-services) , [Compliance](https://www.guardsquare.com/blog/tag/compliance) -------------------------------------------------------------------------------- title: "SSL Pinning in iOS: Prevent Bypassing | Guardsquare" description: "Learn the techniques used by hackers to bypass SSL pinning in iOS and which countermeasures can be taken to secure your applications with SSL pinning." source: "https://www.guardsquare.com/blog/ios-ssl-certificate-pinning-bypassing" -------------------------------------------------------------------------------- February 27, 2021 How to Prevent SSL Pinning Bypass in iOS Applications ===================================================== Written by: Dennis Frett - Software Engineer One of the first things an attacker will do when reverse engineering a mobile application is to bypass the SSL/TLS (Secure Sockets Layer/Transport Layer Security) protection to gain a better insight in the application’s functioning and the way it communicates with its server. In this blog, we explain which techniques are used to bypass SSL pinning in iOS and which countermeasures can be taken. What is iOS SSL pinning? ------------------------ When mobile apps communicate with a server, they typically use SSL to protect the transmitted data against eavesdropping and tampering. By default, SSL implementations used in apps trust any server with certificate trusted by the operating system’s trust store. This store is a list of certificate authorities that is shipped with the operating system. With SSL pinning iOS, however, the application is configured to reject all but one or a few predefined certificates. Whenever the application connects to a server, it compares the server certificate with the pinned certificate(s). If and only if they match, the server is trusted and the SSL connection is established. Why do we need SSL pinning? --------------------------- Setting up and maintaining SSL sessions is usually delegated to a system library. This means that the application that tries to establish a connection does not determine which certificates to trust and which not. The application relies entirely on the certificates that are included in the operating system’s trust store. A researcher who generates a self-signed certificate and includes it in the operating system's trust store can set up a man-in-the-middle attack against any app that uses SSL. This would allow him to read and manipulate every single SSL session. The attacker could use this ability to reverse engineer the protocol the app uses or to extract API keys from the requests. Attackers can also compromise SSL sessions by tricking the user into [installing a trusted CA through a malicious web page](https://sensepost.com/blog/2016/too-easy-adding-root-cas-to-ios-devices/). Or the root CAs trusted by the device can get compromised and [be used to generate certificates](https://threatpost.com/final-report-diginotar-hack-shows-total-compromise-ca-servers-103112/77170/). Narrowing the set of trusted certificates through the implementation of iOS SSL pinning effectively protects applications from the described remote attacks. It also prevents reverse engineers from adding a custom root CA to the store of their own device to analyze the functionality of the application and the way it communicates with the server. SSL pinning implementation in iOS --------------------------------- iOS SSL pinning is implemented by storing additional information inside the app to identify the server and ensure that no man-in-the-middle attack is being carried out. ##### What to pin? Either the actual server certificate itself or the public key of the server is pinned. You can opt to store the exact data or a hash of that data. This can be a file hash of the certificate file or a hash of the public key string. The choice between pinning the certificate or the public key has a few implications for security and maintenance of the application. This lies outside the scope of this blog, but more information can be found [here](https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning). ##### Embedding pinned data The data required for SSL pinning iOS can be embedded in the application in two ways: in an asset file or as a string in the actual code of the app. If you pin the certificate file, the certificate is usually embedded as an asset file. Each time an SSL connection is made, the received server certificate is compared to the known certificate(s) file(s). Only if the files match exactly, the connection is trusted. When pinning the public key of the server, the key can be embedded as a string in the application code or it can be stored in an asset file. Whenever an SSL connection is made, the public key is extracted from the received server certificate and compared to the stored string. If the strings match exactly, the connection is trusted. ##### Popular Options The following libraries are popular options for implementing SSL pinning in Swift and Objective-C iOS applications. **NamePinning implementationLanguageTypeLink**NSURLSessionCertificate file, public keyObjective-CApple networking library[Link](https://developer.apple.com/documentation/foundation/nsurlsession)AlamoFireCertificate file, public keySwiftNetworking library[Link](https://github.com/Alamofire/Alamofire)AFNetworkingCertificate file, public keyObjective-CNetworking library[Link](https://github.com/AFNetworking/AFNetworking)TrustKitPublic keyObjective-CSSL pinning[Link](https://github.com/datatheorem/TrustKit) NSURLSession is Apple’s API for facilitating network communication. It is a low-level framework, so implementing iOS SSL pinning with it is hard and requires a lot of manual checks. TrustKit, AlamoFire and AFNetworking are widely used frameworks built on top of NSURLSession. Both AFNetworking and AlamoFire are full-fledged networking libraries that support SSL pinning checks as part of their API. TrustKit is a small framework that only implements SSL pinning checks. AFNetworking for Objective-C apps or AlamoFire for Swift apps are good choices when you are looking for a complete network library. If you only need SSL pinning, TrustKit is a good option. Bypass SSL pinning protection ----------------------------- iOS SSL pinning bypass can be achieved in one of two ways: 1. By avoiding the SSL pinning check or discarding the result of the check. 2. By replacing the pinned data in the application, for example the certificate asset or the hashed key. In the next sections, we will demonstrate both methods using a sample application and provide some suggestions on how to prevent tampering attempts. #### Test setup and goal We will show how to bypass TrustKit SSL pinning in the [TrustKit demo application](https://github.com/datatheorem/TrustKit/tree/master/TrustKitDemo) running on a jailbroken iPhone. We will be using the following tools. * [mitmproxy](https://mitmproxy.org/) is used to analyze what data is being sent over the network. Alternative tools would be [Burp Suite](https://portswigger.net/burp) or [Charles](https://www.charlesproxy.com/). * [Frida](https://www.frida.re/) is used for hooking and patching methods. Other popular hooking frameworks are [Cydia Substrate](http://www.cydiasubstrate.com/), [Cycript](http://www.cycript.org/) or [Substitute](https://github.com/comex/substitute). * To replace strings in the binary, we will use the [Hopper disassembler](https://www.hopperapp.com/). The TrustKit demo application has minimal functionality. It only tries to connect to [https://www.yahoo.com/](https://www.yahoo.com/) using an invalid pinned hash for that domain. ``` let trustKitConfig: [String: Any] = [ kTSKSwizzleNetworkDelegates: false, kTSKPinnedDomains: [ "yahoo.com": [ kTSKEnforcePinning: true, kTSKIncludeSubdomains: true, kTSKPublicKeyAlgorithms: [kTSKAlgorithmRsa2048], // Invalid pins to demonstrate a pinning failure kTSKPublicKeyHashes: [ "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=", "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=" ], kTSKReportUris:["https://overmind.datatheorem.com/trustkit/report"], ], … ``` Note that even if the supplied hashes would be valid for the yahoo.com domain, SSL pinning validation should still fail as long as we’re using a man-in-the-middle proxy. When connecting to yahoo.com, mitmproxy shows us that the domain is not actually visited. Only the report of the SSL pinning verification is sent to the configured servers. The device itself displays a message that the pinning validation failed. All of this is expected behavior since SSL pinning is enabled. Avoiding the SSL pinning check ------------------------------ We will explain how to bypass the iOS SSL pinning check with Frida. Before we can try to bypass it, we need to find out where in the code the actual SSL pinning check is performed. **Finding the check** Since TrustKit is open source, we can easily find out where the actual certificate validation logic takes place: -\[TSKPinningValidator evaluateTrust:forHostname:\]. In cases in which the source code is not available, a good look at the API of the SSL pinning library will usually reveal where the actual validation work is done. The signature of evaluateTrust:forHostname: contains a lot of information about the method. ``` - (TSKTrustDecision)evaluateTrust:(SecTrustRef _Nonnull)serverTrust forHostname:(NSString * _Nonnull)serverHostname ``` The method is passed 2 arguments, including the hostname of the server that is being contacted, and it returns a TSKTrustDecision. The TSKTrustDecision type is a simple enum. ``` /** Possible return values when verifying a server's identity against a set of pins. */ typedef NS_ENUM(NSInteger, TSKTrustEvaluationResult) { TSKTrustEvaluationSuccess, TSKTrustEvaluationFailedNoMatchingPin, TSKTrustEvaluationFailedInvalidCertificateChain, TSKTrustEvaluationErrorInvalidParameters, TSKTrustEvaluationFailedUserDefinedTrustAnchor, TSKTrustEvaluationErrorCouldNotGenerateSpkiHash, }; ``` The source code documents each of these fields, but it is clear that the most interesting value is TSKTrustEvaluationSuccess. **Bypassing the check** To bypass the TrustKit SSL pinning check, we will hook the -\[TSKPinningValidator evaluateTrust:forHostname:\] method using Frida and ensure it always returns the required value. First, we create a Frida instrumentation script and save it as disable\_trustkit.js. ``` var evalTrust = ObjC.classes.TSKPinningValidator["- evaluateTrust:forHostname:"]; Interceptor.attach(evalTrust.implementation, { onLeave: function(retval) { console.log("Current return value: " + retval); retval.replace(0); console.log("Return value replaced with (TSKTrustDecision) \ TSKTrustDecisionShouldAllowConnection"); } }); ``` This script will attach Frida to the evaluateTrust:forHostname: instance method in the TSKPinningValidator interface and execute the given code each time this method returns. The code replaces the return value with 0 (TSKTrustEvaluationSuccess) regardless of its previous value and logs this. We launch Frida and attach to the TrustKitDemo process on our device, executing our script: frida -U -l disable\_trustkit.js -n TrustKitDemo-Swift. If we try to load [https://www.yahoo.com](https://www.yahoo.com/) now, we see in mitmproxy suite that the URL was loaded successfully. The device also shows that the pin validation succeeded. Locally, Frida returns the following output showing that the hook did what we expected. ``` [iPhone::TrustKitDemo-Swift]-> Current return value: 0x1 Return value replaced with (TSKTrustDecision) TSKTrustDecisionShouldAllowConnection Current return value: 0x1 Return value replaced with (TSKTrustDecision) TSKTrustDecisionShouldAllowConnection ``` We have now successfully bypassed TrustKit SSL pinning and are able to view and modify all web requests. Of course, this is only a very basic example of bypassing a single SSL pinning implementation through changing a return value. **Off-the-shelf tools** Bypassing SSL can be accomplished even easier using existing tweaks for jailbroken devices. [SSL Kill Switch 2](https://github.com/nabla-c0d3/ssl-kill-switch2), for example, patches the low-level iOS TLS stack, disabling all SSL pinning implementations that use it. The [Objection SSL Pinning disabler](https://github.com/sensepost/objection/blob/8974d37733d108762184bb41fe8d0a4f1fffb591/objection/hooks/android/pinning/disable.js) for Frida implements the low-level checks of SSL Kill Switch 2 and extends these with a few framework-specific hooks. The following table outlines the methods that can be hooked for some SSL pinning frameworks. libcoretls\_cfhelpers.dylibtls\_helper\_create\_peer\_trustNSURLSession-\[\* URLSession:didReceiveChallenge:completionHandler:\]NSURLConnection-\[\* connection:willSendRequestForAuthenticationChallenge:\]AFNetworking-\[AFSecurityPolicy setSSLPinningMode:\]-\[AFSecurityPolicy setAllowInvalidCertificates:\]+\[AFSecurityPolicy policyWithPinningMode:\]+\[AFSecurityPolicy policyWithPinningMode:withPinnedCertificates:\] **Mitigation: detect hooking** Before verifying the SSL pin, we can verify the integrity of the above functions. As an example, we’ll use SSL Kill Switch 2 which is built on top of the ‘Cydia Substrate’ framework, a commonly used library for writing runtime hooks. Hooking in this framework is done through the [MSHookFunction API](http://www.cydiasubstrate.com/api/c/MSHookFunction/). The method explained here is a proof-of-concept. Don’t use this hook detection code in production software. It is a very basic and only detects a specific kind of hook on ARM64. Using this check without any additional obfuscation would also make it very easy to remove. A common way of hooking native functions is to overwrite their first couple of instructions with a ‘trampoline’, a set of instructions responsible for diverting control flow to a new code fragment to replace or augment the original behavior. Using [lldb](https://lldb.llvm.org/), we can see exactly what this ‘trampoline’ looks like. First 10 instructions of the unhooked function: ``` (llb) dis -n tls_helper_create_peer_trust libcoretls_cfhelpers.dylib`tls_helper_create_peer_trust: 0x1a8c13514 <+0>: stp x26, x25, [sp, #-0x50]! 0x1a8c13518 <+4>: stp x24, x23, [sp, #0x10] 0x1a8c1351c <+8>: stp x22, x21, [sp, #0x20] 0x1a8c13520 <+12>: stp x20, x19, [sp, #0x30] 0x1a8c13524 <+16>: stp x29, x30, [sp, #0x40] 0x1a8c13528 <+20>: add x29, sp, #0x40 ; =0x40 0x1a8c1352c <+24>: sub sp, sp, #0x20 ; =0x20 0x1a8c13530 <+28>: mov x19, x2 0x1a8c13534 <+32>: mov x24, x1 0x1a8c13538 <+36>: mov x21, x0 ``` First 10 instructions of the hooked function: ``` (llb) dis -n tls_helper_create_peer_trust libcoretls_cfhelpers.dylib`tls_helper_create_peer_trust: 0x1a8c13514 <+0>: ldr x16, #0x8 ; <+8> 0x1a8c13518 <+4>: br x16 0x1a8c1351c <+8>: .long 0x00267c2c ; unknown opcode 0x1a8c13520 <+12>: .long 0x00000001 ; unknown opcode 0x1a8c13524 <+16>: stp x29, x30, [sp, #0x40] 0x1a8c13528 <+20>: add x29, sp, #0x40 ; =0x40 0x1a8c1352c <+24>: sub sp, sp, #0x20 ; =0x20 0x1a8c13530 <+28>: mov x19, x2 0x1a8c13534 <+32>: mov x24, x1 0x1a8c13538 <+36>: mov x21, x0 ``` In the hooked function, the first 16 bytes form the trampoline. The address 0x00000001002ebc2c is loaded into register x16 after which it jumps to that address (BR X16). This address refers to SSLKillSwitch2.dylib\`replaced\_tls\_helper\_create\_peer\_trust, which is SSL Kill Switch 2’s replaced implementation ``` (lldb) dis -a 0x00000001002ebc2c SSLKillSwitch2.dylib`replaced_tls_helper_create_peer_trust: 0x1002ebc2c <+0>: sub sp, sp, #0x20 ; =0x20 0x1002ebc30 <+4>: mov w8, #0x0 0x1002ebc34 <+8>: str x0, [sp, #0x18] 0x1002ebc38 <+12>: strb w1, [sp, #0x17] 0x1002ebc3c <+16>: str x2, [sp, #0x8] 0x1002ebc40 <+20>: mov x0, x8 0x1002ebc44 <+24>: add sp, sp, #0x20 ; =0x20 ``` If a function’s implementation is known in advance, the first few bytes of the found function can be compared to the known bytes, effectively ‘pinning’ the function implementation. For Cydia Substrate, we see the function being patched with an unconditional branch to a register (BR Xn), so we can check if we find such an instruction in the first few bytes. If a branch instruction is found, we assume the function is hooked, otherwise we assume it is valid. For demonstration purposes, this simplified assumption will suffice. To find a good mask to detect branch instructions, we had a look at the opcode tables in the [GNU Binutils source code](https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git). The aarch64\_opcode\_table table contains ARM64 opcodes and a mask for the opcode. ``` struct aarch64_opcode aarch64_opcode_table[] = { ... /* Unconditional branch (register). */ {"br", 0xd61f0000, 0xfffffc1f, branch_reg, 0, CORE, OP1 (Rn), QL_I1X, 0}, {"blr", 0xd63f0000, 0xfffffc1f, branch_reg, 0, CORE, OP1 (Rn), QL_I1X, 0}, {"ret", 0xd65f0000, 0xfffffc1f, branch_reg, 0, CORE, OP1 (Rn), QL_I1X, F_OPD0_OPT | F_DEFAULT (30)}, ... ``` The entries are [aarch64\_opcode structs.](https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=include/opcode/aarch64.h;h=a94d7792814f05fdfdd0bc7bc126261bb2a2d63d;hb=HEAD#l662) From the opcode mask (0xfffffc1f) and the instruction representations, we can deduce that the opcode for unconditional branch to register value instructions must match 0xD61F0000. ``` // Only valid for ARM64. int isSSLHooked() { void* (*createTrustFunc)() = dlsym(RTLD_DEFAULT, "tls_helper_create_peer_trust"); if(createTrustFunc == 0x0){ // Unable to find symbol, assume function is hooked. return 1; } unsigned int * createTrustFuncAddr = (unsigned int *) createTrustFunc; // Verify if one of first three instructions is an unconditional branch // to register (BR Xn), unconditional branch with link to register // (BLR Xn), return (RET). for(int i = 0; i < 3; i++){ int opCode = createTrustFuncAddr[i] & 0xfffffc1f; if(opCode == 0xD61F0000){ // Instruction found, function is hooked. return 1; } } // Function is not hooked through a trampoline. return 0; } ``` We can call this function before an SSL pinning check is done, for example in loadUrl, and only start an SSL session if the checked function is not hooked. **Mitigation: name obfucation** With iOS SLL pinning bypass, the attacker first needs to find out which method he has to hook . By using a tool to obfuscate Swift and Objective-C metadata in their iOS app, developers can make it much more difficult for the attacker to determine which methods to hook. Name obfuscation will also throw off all automated tools that look for a known method name. An obfuscator can rename methods in a different way in each single build of the application, forcing an attacker to search the actual name in each new version. It is important to note that name obfuscation only protects against tools that bypass SSL checks implemented in the code of applications or in libraries included in the application. Tools that work by hooking system frameworks won’t be deterred by it. #### Replacing SSL pinning data The other way to bypass SSL pinning is to replace the pinned data inside the application. If we are able to replace the original pinned certificate file or public key string with one that belongs to our man-in-the-middle server, we would be pinning our own server. Replacing an embedded certificate file can be as easy as swapping a file in the IPA package. In implementations that pin a hash of the server public key, we can replace the string with the hash of our own public key. The screenshot below shows the TrustKit demo application loaded into Hopper. Hopper allows us to replace strings in the MachO file and reassemble it into a valid executable. Once the file or the string is replaced, the directory needs to be resigned and zipped as an IPA. This lies outside the scope of this blog, but more information can be found [here](https://coderwall.com/p/cea3fw/resign-ipa-with-new-distribution-certificate). **Mitigation: string encryption** When pinning certificates with a list of hard-coded public key hashes, it is a good idea to encrypt the values. This doesn’t protect against hooking, but makes it much more difficult to replace the original hashes with those of an attacker certificate since these would have to be correctly encrypted as well. **Mitigation: control flow obfuscation** A reverse engineer can analyze the control flow of the application to find the location where the actual hash is verified. If he succeeds in finding it, he can see which strings are used and find out the location of the hash string in the binary. By obfuscating the control flow of the application, the app developer makes it much more difficult to perform a manual analysis of the code. [Click here to learn more about how Guardsquare’s iXGuard protects iOS apps.](https://www.guardsquare.com/ixguard) Tag(s): [iOS](https://www.guardsquare.com/blog/tag/ios) , [Technical](https://www.guardsquare.com/blog/tag/technical) , [Protection](https://www.guardsquare.com/blog/tag/protection) , [iXGuard](https://www.guardsquare.com/blog/tag/ixguard)[](https://www.guardsquare.com/factsheet-ixguard) -------------------------------------------------------------------------------- title: "Android Overlay Attacks: Protect Your App | Guardsquare" description: "Learn how to prevent Android overlay attacks, use overlay detection on Android, and secure your app from being an android overlay target." source: "https://www.guardsquare.com/blog/protecting-against-android-overlay-attacks-guardsquare" -------------------------------------------------------------------------------- March 28, 2023 How to Detect and Prevent Android Overlay Attacks ================================================= Written by: Sander Smets - Security Researcher Modern Android overlays increase usability for mobile apps, but they can also be exploited, making your app and an Android overlay target. Understanding Android overlay detection techniques is key to protecting sensitive data. As mobile apps handle increasingly important tasks, like banking, authentication, or personal messaging, defense against overlay attacks is no longer optional. The Android overlay is a feature used by an app to appear on top of another app. Overlays are commonly used to display floating views such as the chat bubbles in Facebook Messenger or to display a temporary message or alert. They are often used to provide a more convenient user experience by allowing users to access certain features or information without leaving the app they are currently using. However, the benefits of this feature come with a big risk as Android overlays can, unfortunately, be used for malicious purposes. Privilege escalation and theft of sensitive data are often the results of successful overlay attacks. Android overlays can draw a full window on top of a legitimate app, the overlay target, to impersonate the specified app and increase its chance of performing a successful phishing attack. Additionally, malicious overlays can cover partial, but critical, areas of the screen, such as the text in a message box which indicates what permissions are requested by the app. While covering the legitimate app permissions text, the malicious app requests higher privileges, making the user intentionally unaware of what is happening. The image below illustrates two different Android overlay malware attack scenarios. Image B shows a partial screen overlay attack as a malicious view is being drawn on top of a specific location to trick the user. Image C is a full overlay covering the full screen to ask for sensitive user information. This type of overlay is often well-timed (eg. creating the overlay when the user starts a specific banking application) to trick the user into believing a legitimate application is asking for sensitive information. In this post, we will guide you towards some easy steps that you can take to protect against Android overlays, knowing that the Android SDK improvements eventually make these steps redundant. #### [Seamlessly protect against malware with DexGuard’s built-in malware protection feature >](https://www.guardsquare.com/blog/dexguard-android-malware-protection) How do you **protect against an Android Overlay** as a developer? ----------------------------------------------------------------- Starting at API 31 (Android 12), Android introduced a definitive feature to protect against malicious overlays. To use this feature, you call the method "setHideOverlayWindows(true)" on your specified activity windows. Developers should apply this to every activity view that requests sensitive information from the user, such as pin codes, passwords, credit card details, etc. Doing so will prevent non-system overlays from obscuring such views on recent android versions. ``` Button detectOverlayButton = (Button)findViewById(R.id.btnDetect); detectOverlayButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { MainActivity.this.getWindow().setHideOverlayWindows(true); } }); ``` For applications below API 31, the alternative option is to check whether a touch event has been obscured by an overlay. There are two types of obscured touches, named 'partially obscured' and 'obscured'; the latter is true if an overlay is located at the touch location. When an overlay is present but does not cover a touch this will be seen as a partially obscured touch. Android API 9 (Android 2) added three valuable methods for detecting overlay malware based on touch events. The methods onTouch, onFilterTouchEventForSecurity, and setFilterTouchesWhenObscured are made available in API 9 and higher and can be used to detect obscured touch events. ``` ViewGroup view = findViewById(R.id.main_view); view.setOnTouchListener(new View.OnTouchListener() { @Override public boolean onTouch(View v, MotionEvent event) { Boolean badTouch = ((event.getFlags() & FLAG_WINDOW_IS_OBSCURED) != 0) // do not consume event if obscured return badTouch; } }); ``` The setFilterTouchesWhenObscured can be used as a method to filter obscured touches specifically. Another way to apply this method to a view is by adding the 'android:filterTouchesWhenObscured' to the layout attribute. ``` ViewGroup view = findViewById(R.id.main_view); view.setFilterTouchesWhenObscured(true); ``` The onFilterTouchEventForSecurity can also be used to filter specific MotionEvents to prevent obscure touches. ``` @Override public boolean dispatchTouchEvent(MotionEvent event) { return onFilterTouchEventForSecurity(event); } @Override public boolean onFilterTouchEventForSecurity(MotionEvent event) { // Add custom security check int flags = event.getFlags(); Boolean badTouch = (((flags & FLAG_WINDOW_IS_PARTIALLY_OBSCURED) != 0) || ((flags & FLAG_WINDOW_IS_OBSCURED) != 0)); if (badTouch) { // consume touch event to block touch return false; } return super.onFilterTouchEventForSecurity(event); } ``` Furthermore, the onTouch can use the FLAG\_WINDOW\_IS\_OBSCURED flag to detect obscured touches in a specified view. Another onTouch flag has been added in API 29 (Android 10), introducing FLAG\_WINDOW\_IS\_PARTIALLY\_OBSCURED for more precise detection of partially obscured touches. ``` ViewGroup view = findViewById(R.id.main_view); view.setOnTouchListener(new View.OnTouchListener() { @Override public boolean onTouch(View v, MotionEvent event) { int flags = event.getFlags(); Boolean badTouch = (((flags & FLAG_WINDOW_IS_PARTIALLY_OBSCURED) != 0) || ((flags & FLAG_WINDOW_IS_OBSCURED) != 0)); // do not consume event if obscured return badTouch; } }); ` ``` Check out our [Android Overlay Malware Detection Example repo](https://github.com/Guardsquare/android-overlay-detection-poc) on GitHub which uses all said techniques. #### [Learn how to defend against malware in our Mobile Application Security Research Center >](https://www.guardsquare.com/mobile-app-security-research-center) Quick Tips to Prevent Android Overlay Attacks as a Developer ------------------------------------------------------------ * Restrict Overlay Capabilities: Avoid using SYSTEM\_ALERT\_WINDOW or TYPE\_APPLICATION\_OVERLAY unless absolutely necessary and fully justified, and monitor third-party libraries for any use of these APIs. * Enable Obfuscation and Code Hardening: Use tools like ProGuard or R8, and consider runtime application self-protection (RASP) to make your code harder to reverse-engineer. * Use Biometric or System-Level Authentication: Rely on platform-provided authentication methods instead of custom UI screens that are more easily spoofed. * Detect Overlay Attempts at Runtime: Regularly check for active overlays using Settings.canDrawOverlays() and alert the user or block sensitive actions accordingly. ### Comprehensive Evaluation of said techniques On API 31+, you are fully protected against any non-system overlay for every view on which we apply "setHideOverlayWindows(true)". However, any API below API 31 might be vulnerable to being an Android overlay target for overlays that do not pass through touch events. The obscure touch event detections won't work for overlays that block touch events from going to the view, making the onTouch ineffective against a particular set of Android overlay malware attacks, known as full overlay phishing attacks. These phishing attacks work by posing as legitimate applications as they initiate a full overlay at the same time the user launches a legitimate application, tricking the user into entering sensitive information into the malicious application instead. In light of the gaps found prior to API 31, using Multi-Factor Authentication makes it possible to provide additional security against such phishing attacks. For example, adding e-mail or SMS verification to authenticate a new device is a good start. Aiming for a more robust solution like Google Authenticator on every login attempt would be ideal from a security point of view as well. Additionally, API 23 (Android 6) introduced a new overlay permission flag named ACTION\_MANAGE\_OVERLAY\_PERMISSION, which is required for any app to draw an overlay. This overlay permission is automatically granted when an app is installed from the Official Google Play Store. Fortunately, apps installed from other sources will prompt an explicit message requesting overlay permissions, slightly reducing the risk of an Android overlay attack. ### Protect your app against Android Overlay attacks In modern Android versions, developers can successfully block any non-system Android overlay to protect against overlay attacks. Developers that target systems below API 31 still have an alternative technique available that can determine if the application interaction has been influenced by any overlay, allowing developers to take action by potentially restricting certain touch events, resulting in an application that can reduce the risk of malicious overlays for as low as target API 9. If you are unsure if your mobile app is susceptible to being an Android overlay target, you may want to consider scanning it using a mobile application security testing tool such as AppSweep. [AppSweep is a free service](https://appsweep.guardsquare.com/) that you can utilize to quickly identify and fix security issues in your application. Tag(s): [Android](https://www.guardsquare.com/blog/tag/android) , [Technical](https://www.guardsquare.com/blog/tag/technical) , [Dexguard](https://www.guardsquare.com/blog/tag/dexguard) , [Security research](https://www.guardsquare.com/blog/tag/security-research) -------------------------------------------------------------------------------- title: "How to Improve SaMD App Security | Guardsquare" description: "Software as a Medical Device (SaMD) app security is critical for healthcare apps. Learn how to achieve compliance with strong security controls." source: "https://www.guardsquare.com/blog/samd-mhealth-app-security" -------------------------------------------------------------------------------- March 4, 2025 Achieve Regulatory Compliance by Improving Security for Your SaMD Apps ====================================================================== Written by: Michael Olechna - Product Marketing Manager Mobile health (mHealth) app use is exploding around the world. In 2024, [43% of the United States](https://www.statista.com/topics/2263/mhealth/#topicOverview) used mHealth apps in some fashion; in India use was as high as 70%. And there’s still room for growth: by 2032, the market is expected to be worth [almost 90 billion dollars](https://www.fortunebusinessinsights.com/mhealth-apps-market-102020). The rise of smartphones globally also presents ample opportunity: in 2022, smartphone penetration of mHealth apps was [only 76](https://www.grandviewresearch.com/industry-analysis/mhealth-app-market)%. This is projected to rise to 92% in 2030. Millions of patients rely on [mHealth applications](https://www.guardsquare.com/mobile-appsec-for-healthcare) to track key health metrics. Some common uses include glucose monitoring, medication reminders, and help managing chronic conditions. Medical device manufacturers now offer apps that sync with patient devices and act as a medical device itself. Patients can download these apps on their phones to easily monitor and share vital data with their care provider. The FDA terms these apps as [“Software as a Medical Device”, abbreviated as SaMD](https://www.fda.gov/medical-devices/digital-health-center-excellence/software-medical-device-samd). The International Medical Device Regulators Forum defines SaMD as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device." The IMDRF has a [complete guide](https://www.imdrf.org/sites/default/files/docs/imdrf/final/technical/imdrf-tech-131209-samd-key-definitions-140901.pdf) with more information about the definition of a SaMD and its associated use cases. These revolutionary medical innovations dramatically improve the quality of patient care. Yet, while these innovations are exciting, they are not risk-free. A great deal of sensitive patient information is being stored and exchanged via these applications. Additionally, many SaMD applications have built-in integrations with other components of the healthcare system. Thus, SaMD app developers must meet strict regulations and compliance requirements, like what’s demanded of healthcare providers to ensure the safety and privacy of patients using their apps. Some example regulations include [FDA healthcare requirements](https://www.guardsquare.com/blog/mobile-app-security-fda-approval) in the US or EU-MDR regulations in the EU. The risk of sabotage or tampering is specifically mentioned in section D.3.2.3 of EU-MDR regulations. This requirement gives guidance to assess unforeseen risks that cannot be estimated based on harm alone, and only applies to SaMD. Therefore, proper security controls must be implemented to drastically reduce risk probability as much as possible. Developers of SaMD apps are advised to install strong security measures throughout the SDLC to mitigate risk as much as possible, [like the risk of tampering threats](https://www.guardsquare.com/blog/move-fast-break-nothing-how-to-protect-your-mhealth-apps-from-tampering-risks) from malicious actors. For the best defense against outside threats such as these, developers must keep security in mind throughout the development lifecycle. Incorporating security into development alleviates compliance challenges and offers a multitude of benefits. We’ll go through in detail what proper security measures look like, how to implement them, and why they’re important to achieving compliance goals. Which mHealth apps require regulatory approval? ----------------------------------------------- Not all mHealth apps are created equal. For instance, a calorie tracking app on your smartphone is not the same as a glucose monitoring app for a diabetic patient that syncs with the data provided by the glucose monitor itself. Thus, the FDA and other regulations, like EU-MDR, treat both very differently when it comes to regulatory requirements and enforcement. You might think ALL mHealth apps that handle personal data and have access to personal health records are subject to regulatory approval. Surprisingly, this is not the case. In general, the FDA regulates a small subsegment of mHealth apps, which are medical devices. SaMD apps that must meet FDA approval requirements include apps that meet the definition of a medical device or pose a risk to patient safety. One example is [FibriCheck](https://www.fibricheck.us/), which uses the camera of your smartphone to detect heart rhythms and identify any irregularities. FDA approval is also required for apps that are an accessory to regulated medical devices, like SaMD mobile apps. A recent SaMD success story is [Dexcom, the first FDA-approved over-the-counter glucose monitor](https://www.fda.gov/news-events/press-announcements/fda-clears-first-over-counter-continuous-glucose-monitor). Dexcom pairs its glucose monitor with an app that can be downloaded on user’s smartphones to monitor and track their glucose levels. Because Dexcom’s glucose monitor and app adhere to FDA regulations, patients can feel confident in the safety and efficacy of Dexcom’s technology as well as the security of Dexcom’s associated mobile application when storing their personal data. Each type of app referenced above requires strong security measures to be in place to ensure the data provided, collected, and transmitted by the application and / or embedded technology in the app is secure. In order for these apps to hit the market, regulatory bodies like the FDA or EU lay out specific security requirements they must meet. #### What are the regulatory requirements for SaMD applications? Strict requirements outlined by regulatory bodies like the FDA must be met by SaMD developers prior to going to market and maintained afterwards. This is not limited to just the FDA. EU-MDR and other regulatory agencies and regulations lay out specific requirements that SaMD publishers must comply with in order to go to market in their respective regions. Some relevant examples are: IEC 62304 An international standard regarding medical software development, including SaMD. It details lifecycle requirements when developing medical software and SaMD, and includes a framework that outlines software development, validation, and maintenance. ISO 13485 The international standard for a Quality Management System (QMS) when designing and manufacturing medical devices. To comply, an SaMD developer must demonstrate successful implementation of an effective QMS. This includes a continuous improvement process as well as meeting customer and regulatory requirements for SaMD certification. ISO 14971 This international standard outlines proper risk management application to medical devices, including SaMD. It includes a framework to identify potential hazards, risk estimation and evaluation, and implementing risk controls. ISO 27001 The international standard for an Information Security Management System (ISMS). This is particularly important to SaMDs that deal in sensitive health data. The standard assists organizations in managing asset security, including financial information, IP, and employee data (login credentials, etc.). IEC 62366 The process for usability engineering in medical device development. For SaMD developers, it highlights how to optimize interactions between a system and its users, which directly impacts software efficacy and safety. Complying with these regulatory standards is an absolute must. Not doing so represents significant consequences for SaMD developers. Yet, significant roadblocks exist in the mHealth app development process that delay compliance. The following section discusses in detail the specific consequences of not achieving compliance, as well as the challenges facing mHealth app publishers. #### Consequences of not achieving compliance Significant penalties exist for applications that do not achieve compliance with regulatory bodies. Fines are steep, financially damaging, and grind development cycles to a halt. According to the FDA, app publishers can be fined up to $15,000 for each violation found, and multiple violations can be pursued simultaneously. There are similar financial penalties for failure to meet EU-MDR compliance requirements, including product recalls and even legal action. App development for these healthcare applications is extremely costly and time consuming. The compliance strategy has to be well thought-out and present at each stage of development. Any delays or regulatory roadblocks will not only increase costs, but also negatively impact time to market. Innovation evolves at a rapid pace in this industry. Every second counts and to be late to market due to regulatory delays is a bitter pill to swallow with damaging ripple effects. SaMD developers cannot ignore the consequences of poor security posture and lack of compliance either. The healthcare industry remains the industry with the highest cost of a data breach, [averaging $9.77 million in 2024](https://www.chiefhealthcareexecutive.com/view/healthcare-data-breaches-remain-most-expensive-of-any-industry). But it’s not just the financial repercussions of the data breach itself. The damage to brand reputation cannot be overstated. Applications that experience breaches experience the ire of their customers and lose trust from the market. These effects are much longer lasting and more difficult to recover from. #### Challenges to achieving regulatory compliance SaMD developers continue to face expanding and increasingly strict regulatory requirements. The evolving regulatory environment presents unique challenges that must be tackled head on. Recently, the National Library of Medicine conducted a systematic review of the challenges that face mHealth app developers. The [review](https://pmc.ncbi.nlm.nih.gov/articles/PMC8277314/#sec22) identified nine primary challenges facing mHealth app developers based on an analysis of 32 primary studies published between 2008 and 2020. Overall, the top challenge facing developers was lacking security guidelines and regulations regarding [secure mHealth app development](https://www.guardsquare.com/blog/mitigating-mhealth-apps-security-risks). A complex regulatory landscape with a myriad of regulations can be quite cumbersome to the development process. Thus, the importance of a well-communicated compliance strategy cannot be overstated. The second most common challenge was developers not possessing the knowledge nor expertise required to develop secure mHealth apps. It takes a great deal of expertise to develop mHealth and, specifically, SaMD applications. However, the skillset is not a 1:1 transfer to developing security protections. A solution that can make security an integrated part of the development process will greatly ease the burden facing these developers. Rounding out the top three was a lack of stakeholder involvement during the development process. For strong security posture, it’s critical that a clear line of communication is established early in development between security analysts and software engineers. Without a streamlined method of communication, discrepancies will exist and manifest setbacks to development. Are mHealth apps secure? ------------------------ Threat actors and the necessity for [mobile app protection](https://www.guardsquare.com/what-is-mobile-application-protection) are not exclusive to mHealth or SaMD app developers. Healthcare app security should be a top priority for developers. What is unique to mHealth and SaMD apps is the type of data they store and handle. mHealth apps store personal identifiable information (PII) and protected health information (PHI), which is protected by laws like HIPAA or GDPR. This sensitive data is part of what makes mHealth apps a ripe target for malicious actors. These organizations must combat a [wide range of threats and security risks](https://www.guardsquare.com/blog/mitigating-mhealth-apps-security-risks). The National Library of Medicine [conducted a study](https://pubmed.ncbi.nlm.nih.gov/34338763/) to analyze the security risks of 20,000 mHealth apps on the Google Play Store. Among the most impactful security risks were unencrypted communication (45% of apps), sending personal data on unsecured traffic (23%), and packaging suspicious codes (1.8%). All of these practices pose substantial risks to users of these apps and to the app publishers themselves. But there are measures to identify risks, increase app resilience and strengthen security posture. #### The STRIDE framework The FDA recommends the STRIDE threat modeling framework for SaMD app developers to segment security risks, and features it in the FDA’s [playbook for threat modeling in medical devices](https://www.mitre.org/news-insights/publication/playbook-threat-modeling-medical-devices). Both resources give organizations a practical guide to help ease the burden of compliance and mitigate security risks. Below is a description and application of the STRIDE framework letter by letter. **S**poofing The act of spoofing is defined as deceiving a system into identifying a falsified entity as a true entity. Think of it as using another’s login credentials to gain access into a healthcare system the perpetrator normally would not be able to access. **T**ampering [Tampering is a persistent and significant security risk](https://www.guardsquare.com/blog/move-fast-break-nothing-how-to-protect-your-mhealth-apps-from-tampering-risks) for mobile applications, especially in mHealth apps. When a system or environment is intentionally modified to change its intended behavior without authorization, that is considered tampering. The rise of telehealth has exposed new tampering risks, such as chat functions with medical providers. Communication functions within the app can be maliciously manipulated, which may cause patient harm. Because tampering is easier to scale than other types of attacks, it is quite difficult to reign in once it has begun. Shifting security left in the development lifecycle, ideally at the beginning of app development, builds tampering protections into the application right at the start. **R**epudiation Bad actors may manipulate an app so it disputes the authenticity of actions taken by its users. For example, an app that contains prescription order information can be manipulated to deny a prescribed treatment has been transmitted to the patient. This poses a serious medical risk to patients treating all kinds of conditions and can become life-threatening. **I**nformation Disclosure Data leaks and breaches are, unfortunately, all too common in the healthcare industry. Many reasons exist as to why, but poor healthcare app security measures are a common denominator. The HIPAA journal identified in a 2024 report that [58 million patients](https://www.hipaajournal.com/august-2024-healthcare-data-breach-report/) had their records exposed through August. Insecure data storage practices are a main culprit for these breaches, which have plagued the healthcare industry since 2020. **D**enial of Service (DoS) Malicious actors will often deploy malware to facilitate distributed denial of service (DDoS) attacks. DDoS blocks legitimate access or system functionality from the organization and users. By deploying these attacks, bad actors can declare a ransom in order to grant access back. The Health Sector Cybersecurity Coordination Center noticed in Q1 of 2023 that ransom [DDoS attacks are increasing their frequency](https://www.hipaajournal.com/hc3-issues-ddos-guide-for-the-healthcare-sector/), growing by 24% quarter-over-quarter and 67% year-over-year. **E**levation of Privilege (EoP) Individuals carrying out mobile attacks will grant themselves access to functions that would normally be prevented by security protocols. In relation to mHealth apps, a threat actor may grant themselves administrator status to access all patient data records, including PII and PHI, financial information, etc. Security controls for mHealth application protection ---------------------------------------------------- Organizations inside and outside mHealth must incorporate security controls to boost protection against threats and mitigate risks. Some controls exist to primarily protect the flow of information into and out of the app. Others examine and protect the code of the app itself. The best approach is a multi-layered mobile app protection strategy. We’ll dive into some specific measures below. #### Mobile application security testing [Mobile Application Security Testing (MAST)](https://www.guardsquare.com/what-is-mobile-application-security-testing) tools perform tests that measure security risks and identify app vulnerabilities prior to release. Security testing throughout the development lifecycle gives developers actionable insights into security risks and dependencies, like improper credential usage or inadequate privacy controls. These are two of the risks featured on the [OWASP Mobile Top 10](https://owasp.org/www-project-mobile-top-10/), a list of the top ten security risks facing mobile apps, including SaMD applications. MAST tools like [AppSweep](https://www.guardsquare.com/appsweep-mobile-application-security-testing) integrate directly with developer tools like Github so teams can practice CI/CD workflows. By leveraging these tools developers are able to shift left security development and implement protections for known and unknown vulnerabilities prior to publishing their apps. As a result, malicious actors are never given the chance to exploit these weaknesses. #### Code hardening & Obfuscation techniques [Static analysis](https://www.guardsquare.com/blog/addressing-static-and-dynamic-attacks) is the examination of an app’s resources and source code. Threat actors will use static analysis to analyze the source code of an application. These actors will use tools like decompilers to unlock the internal logic of your application in order to steal sensitive information, like PII, or to extract login credentials. Once the logic is unlocked, threat actors have the ability to reverse engineer your application or gain access to tertiary systems. [Code hardening](https://www.guardsquare.com/code-hardening) is a layer of protection against static analysis to prevent these negative outcomes. There are several popular techniques and practices to implement code hardening. Some common examples include code virtualization, call hiding your API keys, and code obfuscation. [Code obfuscation](https://www.guardsquare.com/what-is-code-obfuscation) hides the internal logic of your app’s code from bad actors. Classes, fields, and entire libraries are renamed, among other actions, to conceal the code. Essentially, the code becomes randomized, significantly increasing the difficulty for malicious actors attempting to tamper with your code. #### Runtime application self-protection (RASP) On the other side of static analysis is dynamic analysis. Dynamic analysis examines the app’s behavior during runtime. [Jailbreaking, hooking, and rooting](https://www.guardsquare.com/blog/what-rooting-and-jailbreaking) are common examples of dynamic attacks on your application. Threat actors will use these techniques to intercept communication to servers, steal decryption keys, and more. For complete mobile app protection, an application requires strong defenses against both static and dynamic analysis. A key component of protecting against dynamic analysis is [runtime application self-protection (RASP)](https://www.guardsquare.com/runtime-application-self-protection-rasp) checks. RASP checks prevent app tampering during runtime by monitoring both the app and the environment it runs within. RASP checks are injected into the application for specific detection of malicious actions. Some example detections that might be implemented via RASP checks are jailbreak detection, debugger detection, repackaging detection, code tracing detection, and hook detection. The RASP checks will identify these threats and take pre-programmed actions set by the app developer. For instance, if a jailbreak attempt is detected, the application can be set to respond accordingly with a range of responses. An example of the most significant response would be automatically crashing the session, immediately preventing any negative outcomes from being achieved by the threat actor. #### Real-time threat monitoring Implementing security into your code during the development lifecycle is essential to strong mobile app protection. But what about after your app is released? This is where [threat monitoring](https://www.guardsquare.com/threat-monitoring) tools come into play. Threat monitoring increases security posture by monitoring your application for threats like hooking or jailbreak detection amongst your userbase across different geos, app versions, and devices. These tools include vital metadata with each threat to understand the full context and make it easier to know the appropriate course of action to remediate the threat. Tools like [ThreatCast](https://www.guardsquare.com/threatcast-mobile-threat-defense) deliver real-time custom alerts and notifications when a breach does occur. Security and development teams alike are able to leverage threat monitoring solutions to streamline communication against threats, stay vigilant, and take action in real-time. How a leading SaMD developer meets regulatory compliance -------------------------------------------------------- [A leading SaMD developer](https://www.guardsquare.com/samd-provider) came to Guardsquare with the challenges outlined earlier in this blog. This SaMD developer specialized in developing Android and iOS apps for medical devices and their connected systems. Thousands of patients across various clinical domains rely on their applications. Facing strict regulatory requirements and lacking a standardized security solution, they were in search of a tool that would meet their compliance needs. The tool also needed to be easy to implement and protect sensitive patient data. The SaMD developer understood that poor app security could expose their patient’s sensitive data, threatening their privacy and wellbeing. In extreme instances, it could even become life threatening. Thus, the app developer required that the solution offered robust security protection of their apps and SDKs, particularly against reverse engineering and tampering. During their examination of different solutions, the development team discovered [DexGuard](https://www.guardsquare.com/dexguard) and [iXGuard](https://www.guardsquare.com/ixguard). Both tools offer advanced code obfuscation, which the SaMD found invaluable for protecting their assets and sensitive data against tampering and reverse engineering. These advanced code hardening and code obfuscation techniques supported consistent and reliable operations. The company also leveraged the built-in RASP checks in DexGuard and iXguard to protect their apps from dynamic analysis. By implementing RASP checks, the mHealth app developer protected their app from attackers using debuggers, code tracing tools, or hooking frameworks. After installing DexGuard and iXGuard, the SaMD developer was able to stay multiple steps ahead of attackers, thanks to multi-layer polymorphic protection. This technique gives each app build different code hardening and RASP configurations. RASP checks are also placed in different locations, significantly increasing the difficulty for attackers to break into the app. Attackers are unable to leverage prior knowledge to facilitate attacks. Essentially, the clock resets each time an attack is attempted. And, because they were able to build a comprehensive, more holistic protection strategy, the SaMD developer eliminated redundant and less effective security tools. In the Chief Solutions Officer’s own words, “we’re able to stay on top of cornerstone regulatory mandates from the FDA such as 13485, 62304 and HIPAA (as well as emerging guidance) and, European Union such as GDPR & EU-MDR, without compromising performance”. Take the first steps towards meeting SaMD regulatory compliance --------------------------------------------------------------- Mobile health applications represent a market full of innovation and opportunity. But with that opportunity comes significant risks. mHealth app providers, particularly those developing SaMD apps, must remain vigilant and steadfast when it comes to protecting their apps and patient data. They also cannot afford to lose their focus on meeting strict compliance regulations in a fast-moving landscape. A comprehensive approach that offers complete protection and integrates into each stage of the development lifecycle is the best path forward. Not only does such an approach streamline communication, it also eases the regulatory burden that faces SaMD app developers. To learn more about complete mobile app protection from Guardsquare and how its products can assist you in meeting your regulatory needs, [speak with our mobile app security experts today](https://www.guardsquare.com/request-pricing). Tag(s): [Healthcare](https://www.guardsquare.com/blog/tag/healthcare) , [Compliance](https://www.guardsquare.com/blog/tag/compliance) , [Dexguard](https://www.guardsquare.com/blog/tag/dexguard) , [iXGuard](https://www.guardsquare.com/blog/tag/ixguard) -------------------------------------------------------------------------------- title: "Leader In Mobile App Security | Guardsquare" description: "Guardsquare is the leader in mobile application security, with multi-layered protection for your Android and iOS apps. Learn more." source: "https://www.guardsquare.com/" -------------------------------------------------------------------------------- **The highest level of mobile app security with ease** ====================================================== Multilayered protection unified with automated security testing. Detect threats in real-time and trust that it’s your app interacting with your APIs. All in a single, intuitive platform. [Request pricing](https://www.guardsquare.com/request-pricing)[Discover the guided workflow](https://hubs.la/Q02-cz190) Why Guardsquare is **different** -------------------------------- Protection and testing combined * Continuous mobile app security testing combined with multiple reinforcing layers of code hardening techniques delivers comprehensive protection. * Testing provides in-depth code analysis for relevant and actionable insights to fix issues early in the development lifecycle. * Automatically injected RASP checks within the code itself help monitor for suspicious behavior when the app is running. Ease of integration #### Seamless implementation * Guardsquare’s innovative, guided approach to implementing comprehensive mobile app security ensures ease and efficiency. * Fine-tune advanced protection settings so security-sensitive code and assets are fully protected. [Discover our guided workflow](https://www.guardsquare.com/mobile-app-protection-guided-workflow) Security without compromise * Designed specifically for mobile applications. * Continuous testing and compiler-based protections weave security throughout the development process. * Apply comprehensive security without disrupting mobile app performance, UX, or delivery cycles. [Connect with an expert](https://www.guardsquare.com/request-pricing) **Innovative guided workflow** for seamless integration ------------------------------------------------------- Our guided workflow simplifies mobile app protection for teams, ensuring top-tier, multi-layered, compiler-based, polymorphic protection without compromising performance or UX. Amid an evolving threat landscape and cybersecurity skills gap, this capability enables the highest level of app protection in less than a day. With Guardsquare, every developer is a secure developer. [Learn more](https://www.guardsquare.com/mobile-app-protection-guided-workflow) **Infographic:** The Changing State of Mobile App Security ---------------------------------------------------------- 62% of organizations have experienced a mobile applications security incident within the last 12 months. Is your app protected? [Access the infographic](https://www.guardsquare.com/the-changing-state-of-mobile-app-security) Our **products** ---------------- ### Browse our [mobile app security](https://www.guardsquare.com/what-is-mobile-app-security) products to learn more about how they can help secure your iOS and Android apps and SDKs. [**DexGuardANDROID**Protect native Android & cross-platform apps with DexGuard's multilayered, polymorphic, obfuscation, optimization, & Runtime Application Self-Protection (RASP).**Learn more**](https://www.guardsquare.com/dexguard)[**iXGuardiOS**Secure native iOS & cross-platform apps and SDKs with iXGuard, offering multilayered, polymorphic obfuscation & built-in Runtime Application Self-Protection (RASP).**Learn more**](https://www.guardsquare.com/ixguard)[**AppSweepANDROID & iOS**Find & address security issues in mobile apps and SDKs with AppSweep, our app security testing product. Designed for developers, ready for enterprise needs.**Learn more**](https://www.guardsquare.com/appsweep-mobile-application-security-testing)[**ThreatCastANDROID & iOS**Monitor threats to mobile apps & SDKs in real time, adapt security configurations & identify security gaps & vulnerabilities post-publication.**Learn more**](https://www.guardsquare.com/threatcast-mobile-threat-defense)[**ProGuardJAVA & KOTLIN**Use Guardsquare's open source optimizer, ProGuard, to shrink & obfuscate Java & Kotlin apps.](https://www.guardsquare.com/proguard)