Mobile App Security with Ryan Lloyd

0:00Mobile apps have become a primary interface for critical services, including banking, payments, and healthcare. Unlike web applications, much of the logic and intellectual property in a mobile app lives directly on the user's device, which is an environment the developer doesn't control. That makes mobile apps uniquely exposed to reverse engineering, runtime manipulation, and fraud. As more critical functionality shifts to mobile, the need to harden apps against sophisticated attackers continues to grow. GuardSquare builds tools to protect and test mobile applications against both static and dynamic threats.

0:38Its platform has features including layered code obfuscation, runtime application self-protection, mobile-specific security testing, threat monitoring, and API attestation. Ryan Lloyd is the Chief Product Officer at GuardSquare. In this episode, he joins Gregor Vand to discuss why mobile security differs from desktop and web security, how reverse engineering tools have evolved, the role of compiler-based obfuscation and runtime protections, common mobile app vulnerabilities, and how LLMs are reshaping the attacker landscape. Gregor Vand is a security-focused technologist, having previously been a CTO across cybersecurity, cybersecurity, cyber insurance, and general software engineering companies.

1:25He is based in Singapore and can be found via his profile at van.hk or on LinkedIn.

1:44Hello and welcome to Software Engineering Daily. My guest today is Ryan Lloyd. Hi there. Great to be here. Yeah, great to have you here, Ryan. So you're the Chief Product Officer of GuardSquare. We're going to be hearing all about GuardSquare through the episode and everything mobile app security. Not a topic that we've covered in much depth before, so this is going to be an interesting one. But as we like to do on SE Daily, just what was your path to GuardSquare, I guess, and becoming the CPO at GuardSquare? Yeah, so for 20, 25 years now, I've been working for a series of companies that provide software developer tools.

2:25So in early 2000, I started with a company that built version control and issue tracking software, predating Git and Jira and those kinds of things. And then eventually moved into a company called SmartBear, where we focused on software test automation and quality assurance tools. And then more recently, I spent a bit of time at a company called Veracode, which is my first foray into the world of security and application security specifically, which has a lot of similarities to automated testing. Scanning apps to find vulnerabilities is not that different than testing apps to find bugs and defects.

3:04And then the last five years I've been here at GuardSquare. So throughout my journey, I've been focused on product management and really on tools for developers and then more recently around security. And now here at GuardSquare, it's all about mobile app security. So an even more narrow and specialized space within security. But yeah, all about focusing on our customers who are app developers and supporting them in how they secure their mobile applications. Yeah, nice. So then I guess GuardSquare as a company, what's the origin story there? Yeah, it's an interesting one. So the original founder of the company started an open source project called ProGuard.

3:46And that open source project was initially focused on optimizing and shrinking Java applications, just making them smaller, more efficient, things like that. and eventually it became a really popular tool for Android developers to shrink and optimize Android apps. So it became so popular it became bundled into the Google developer toolkit as a default and the interesting thing was in shrinking and optimizing applications it would decompile the binary and then it would apply these transformations to the code to shorten all the names and references to illegible names that just took up less characters.

4:28And if you do this enough times through a whole binary, eventually you shrink it down much smaller. And then we did some optimization passes to make the app start up faster. So that was kind of the way the company got started. And then what we noticed is some people were starting to use this tool, ProGuard, because of this feature of renaming all the names for security purposes. They thought, well, if it makes the code less legible, that's a security benefit. And once we started recognizing that this was a recurring and common pattern, we decided to pull on that thread further. And we created a parallel tool called DexGuard, which applied this and many other concepts to obfuscate and secure mobile application code.

5:11And that all took place around 2014 when the company was formalized and incorporated and moved out of just being an open source tool to a formal company. And since then, we've just been on a journey to add more capabilities and tools and sophisticated functionality to help companies that are trying to secure mobile apps. Yeah. And I mean, we're also going to get into the kind of the technicals of what the product does and I guess how it does it as well, but maybe just to set the scene, like what's the typical size of company or like any names of like obvious customers, I guess, just sort of what's the kind of scale here of how this is being used?

5:48Yeah. So we have around a thousand paying customers. And they're protecting apps across a range of industries. So around 40 % of our customers are in the finance vertical, right? So mobile banking applications, fintech, card payment, SDKs and software, crypto apps, things of that nature. That's around 40 % of our customers. And then we have a long tail of customers across quite a wide variety of industries. I mean, you think of mobile apps these days and they do just about everything. So we've got customers that have mobile games that they try and protect from cheating. We've got streaming media platforms that are trying to make sure that the digital rights kind of protections they have built into the application are secure and can't be bypassed for content to be stolen and infringed upon.

6:40Healthcare has been a big developing area for us recently as well. So a lot of apps where there's a mobile app that is a companion to a physical medical device. Think about diabetes and insulin care, things like that. Yeah. So we're going to get into like what this is effectively. And also to kind of clarify, because we're going to be talking a lot about just simply mobile application. Are we also talking about iPads as well, for example? Yeah. Yeah. So when we talk about mobile, we talk about Android and iOS. So that includes different form factors, also the TV elements of those platforms. Yeah.

7:19So that kind of leads into, I guess, literally one of my first questions when I was thinking about this was, well, how did this differ from desktop effectively? We've had desktop binaries since not the dawn of time, but the dawn of consumer computing. and when it comes to mobile across these form factors as we've just talked about like these are just binaries right but there's way more to it than that and i think that's kind of where it would be interesting to start like what really sets apart the mobile landscape from this perspective what are the things that guardscore needs to be looking at yeah so mobile apps they're fundamentally reverse engineering them tampering them is not much different than the practices and patterns that applied on desktop applications.

8:06I think the biggest fundamental difference is the purpose and the value of mobile apps is fundamentally different, right? Like you've never installed a banking app on a desktop computer. Sure, you've accessed it maybe through a web browser, but all of the IP and the logic lives on a server that's well-protected and secured. But a banking app for mobile, a lot of that IP and logic is built into an app that's on the end user's device where they can tamper with the environment, tamper with the code and manipulate its behaviors. And that extends beyond banking, of course, but I think the value and the stakes are just much higher with mobile apps.

8:47The biggest parallel we've seen with desktop apps is maybe our gaming customers. Anti-cheating and cheating protections have been something that they've invested heavily on, on the desktop side and is similar on the mobile side. And maybe some paid enterprise software apps where piracy and things are a concern would be, would have parallels between desktop and mobile. But there are a lot of consumer apps on mobile that never really existed in a desktop world. So it brings into focus these different security considerations and attack paradigms. And like a desktop, the thing with mobile is what makes it different than a web application is the end user has so much control over the hardware, the device, and lots of tools at their disposal to manipulate and modify and tamper with it.

9:36Yeah. And thinking about, as you were touching, how users use their mobile devices. And it's very common these days for BYOD, bring your own device to a company. So a company is having to, there are obviously many ways to protect against this, but ultimately a user is running apps on a device that is also running work apps and email and all that kind of stuff. Yeah. And there's two kind of paradigms to mobile security. There's mobile device security and there's mobile app security. So definitely enterprises care about device security and making sure that any business corporate data that ends up on a phone is well controlled and secured.

10:17And actually that's a somewhat easy problem to solve because your company can force different tools and policies onto your device as a exchange for giving you access to corporate data on that device. But mobile apps for consumers is a different paradigm because a bank that builds a mobile banking application can't force their customers to install MDM tools and set policies on their devices. They kind of have to take the device as it is and make a trust-based evaluation of whether that device is suitable to access their banking services. So I think in the B2C consumer model, there's a lot more trust that has to be placed in the end user and a lot more security checks that need to be put in place to ensure that things are secure.

11:07Yeah. And then if we just look at a slight difference perhaps between the mobile app landscape and sort of desktop apps, binaries, whichever you'd like to call them, the reverse engineering tool maturity in mobile apps seems quite well mature and it feels like there's just more going on in that space with people that like to decompile and understand mobile apps i mean i'm guessing some of that is around the distribution the distribution is very easy to go to an app store or pretty much as we for better for worse most mobile apps you'll get it through an app store because of how they are distributed so you can go and find the app of whichever company incredibly easily which is quite different to desktop where a lot of apps are just kind of randomly hosted github binary easy download or something which you can see the source code anyway so there's clearly a lot of interest around decompiling and as you've called out these apps link to big companies as you said like a bank it produces a website which is a whole bunch of technology but an app is a total package there so yeah is that something you've sort of seen as well and how GuardSquare has evolved, I guess.

12:17Yeah, there's definitely a lot of tools and a whole democratization of reverse engineering knowledge that's gone on in the last 10 years. And every year it just gets more intense. And I think it's not so much that desktop and mobile are different from a technology standpoint. I think there's a simpler explanation, which is people with bad intentions or attackers, however you want to characterize them, they go where the value is, where the money is. And mobile apps just represent such an attractive target that it has spurned a whole, like any good internet effort, a community, right? A community of tools and knowledge and expertise that's been widely distributed.

12:58And up until the last year or two, it required people to write blogs and share knowledge and go to conferences and do demos to get that knowledge distributed. Now with LLMs and whatnot, that knowledge is kind of even more accessible. People could just type in a question and get some pretty detailed guidance on which tools to use and how to approach some of these problems. So that's accelerating it even more, I'd say, in the last year or two. Yeah. And then what is the threat landscape then in terms of what is somebody likely to be able to turn up on a mobile app if they decompile it or so on? What are the kind of things that, as we'll get on to, are trying to be protected against here?

13:42Yeah, yeah, it's a good question. There's quite a wide range of different threats that can exist. The most basic threat can be just intellectual property in the application that's important. So that could be proprietary algorithms or ways of doing something that are unique and you don't want competitors to know or understand about that. If you've got any models that you've trained for different AI use cases, we've seen customers that are concerned about those models being manipulated or extracted and maybe used by competitors or new entrants in their market. So IP protection is one category of use case for protecting a mobile app.

14:24We've also had some high-profile consumer companies that build consumer technology with a heavy mobile component to it, concerned about new features they're building and protecting their app from competitors or tech journalists from reverse engineering to see what their roadmap is. They'll silently build out these critical features for something that's in their roadmap a year out or longer, and they don't want people to know about it. So that's kind of another variation of IP protection. So that's one sort of category. In the financial services industry, the biggest risk there is fundamentally fraud.

15:03And it comes in different forms. One is around account opening fraud. So as the world shifted from requiring everyone to show up at a banking branch with their passport to verify their identity, a lot of that's been digitized now. You can open up a bank account digitally. There's authentication flows to verify your face and to make sure that you're a real live person and to match it to your identity. Turns out money laundering really wants to manipulate those mechanisms to be able to open fraudulent accounts so they can launder money. So we see that kind of use case a lot. And then phishing-based fraud has been really targeting mobile banking and payment apps a lot in recent years.

15:48so this is a case where somebody reverse engineering a banking app will download the official app from the app store they will tamper with it to introduce malware or just code and logic to steal credentials and information from that user and then they'll use that fraudulent app in a phishing campaign they'll trick users into saying hey there's a new update of your bank app available click here to download it users get tricked into downloading it and now they go to log in and they're passing their credentials on to an attacker who's sitting at the other end just waiting to log into their account and perform some fraud so yeah financial services it's really all about variations of fraud gaming we touched on it's about cheating so people looking to gain an advantage in multiplayer games especially or games that have rewards or monetary components to them And then healthcare is an interesting one.

16:46The medical device space, what we see most often is two aspects. One, there's just a concern around privacy and data and making sure that the entire path of how data is collected from the app transmitted to servers is as secure as possible to prevent data leakage and breaches of personal information. information. And then also there's just sort of an academic security component in medical devices as well. If you recall, maybe 10 years ago, there were some high profile talks at events like Black Hat, where they're talking about how you can remotely control a pacemaker or an insulin pump. And these things, practically speaking, probably don't represent a very real threat for the majority of people.

17:30So you'd think they're kind of low risk, but they are headline grabbing and no company really wants their brand to be affiliated with that kind of academic security research so part of protecting your app is also just a defensive measure at mitigating some of the brand risk that can come about yeah and we're going to get into sort of how this all works in a second i think just one more thing which is i guess interesting to touch on is well it's interesting and to some people unfortunately quite boring but it is part of life as a business is compliance and just that compliance is only getting increasingly more stringent how does that factor into if you're a company distributing a mobile app like what kind of compliance are you i guess let's say at bank level like what are you expected to be showing and doing yeah so in some instances there's very targeted and specific regulations or certifications that are required for certain types of applications so most notably you'll find anything that deals with payments There's a whole consortium, the payment card industry, PCI, that has layers of standards and certifications that are required for different payment types and channels.

18:40So one thing you'll notice if you go into a lot of shops, retail environments today, or restaurants, they've all got mobile phones or tablets where you can tap your card against to pay. Well, underpinning those mobile devices is an app and SDKs for processing payments. and so there's a whole compliance theme around how do we protect that payment information on what is essentially a shop owner's personal device in many cases so those are very precise they lay out very specific requirements that need to be met around mobile app and sdk security it's the most specific in what steps you need to take banking apps generally are less specific they definitely have security frameworks, but they don't tend to be very mobile specific.

19:29In some regions of the world where there's a high risk of malware, they've started to introduce specific regional regulations around what steps banks need to take to protect mobile app users from phishing campaigns and app-based malware. But beyond that, a lot of it's just general regulations, things like GDPR, ISO, NIST, HIPAA controls, where they don't really specify the mobile app requirements or controls that are necessary. They just say you need to make sure personal data is secured, sensitive data is secured, and it's up to the mobile app development team and their security team to really figure out what does that mean.

20:11So there's a bit of a gap, I would say, in terms of industry standards around this topic. And one project that's been really trying to push to address some of that is the OWASP working group that's focused on what's called the Mobile App Security Project. So they have a verification standard and a testing guide that details what that group believes are some of the important security considerations for mobile apps. So GuardSquare has been working closely with that group to help build out those requirements and provide testing guidelines and test automation scripts to help fulfill some of those requirements.

20:48Nice. So I think, yeah, let's get into what is actually happening. I mean, is it worth talking about both the open source and the paid total product? How do they intersect? Or where would you like to start? Well, there's not much to say there because I think the open source product was built for a very specific purpose of optimization and shrinking. And only by coincidence did it address, to some degree, these security use cases. So we think mostly about the commercial tools around mobile app security. And first of all, mobile app security is a broad umbrella. But within that, the area where we really started from was mobile app protection.

21:26And so protection for us means protecting the application from reverse engineering and tampering. And there's two primary axes for reverse engineering and application. what we call static techniques and attacks, and then dynamic techniques and attacks. And there's different capabilities and protection features that are necessary for each of those. So maybe if we just start with the static side first. So static analysis of a binary is all about you download the binary, and you can use any number of decompiling tools that turn machine code back into readable, interpretable human readable code that you can understand the logic the behaviors and spot ip or secrets or information that can be useful knowledge to an attacker and the primary mechanism for defending against that is code obfuscation so obfuscating is all about taking that code and manipulating it in different ways to make it so that it's not readable so that when it's decompiled it's very difficult for someone to understand and that's not to say that it's irreversible but the complexity becomes so high with good quality obfuscation that the time it would take someone to really make sense of the code is often no longer kind of worth the the effort and time they would spend yeah i mean to some developers this is sort of similar but different to you know minification effectively where minification being that it's obviously very clear how to effectively it's obfuscation but also compressing but it's also very known and clear how to deobfuscate and inflate it back up in this case the whole idea is that let's say you had decompiled this app as you call it there is no real way to deobfuscate the code at the end of the day you can't see what's running there yeah and the main way we achieve that is through a lot of different layers of obfuscation techniques, right?

23:29So the simplest example is the name obfuscation that I mentioned earlier, which is kind of rooted in the open source tool, just simply renaming class names, method names, and all the different objects you see in the application with short, nondescript names. And when we process an application to do that renaming, we generate a mapping file. And as long as you keep that mapping file internal to your organization, anyone without that mapping file would have a hard time putting the puzzle pieces back together. So name obfuscation is the most foundational and basic obfuscation feature that's needed.

24:05But then there's different layers to add on top of that. You can encrypt classes and then you hide the encryption code in different pieces throughout the application so that you can't read the class implementations. String encryption, similarly for protecting high value or important strings in the application. And then you get into the more advanced and sophisticated techniques like control flow obfuscation. So here you're actually remapping the flow of the application to make it very difficult to understand the logic and how the code's flowing at runtime. And then virtualization, you can virtualize code, which again, makes it very difficult and provides a whole layer of indirection that just makes it very difficult to observe or analyze the application.

24:51So those are are all examples of some of the features that we use as techniques to defend against static attacks and techniques. Yeah. And it's maybe just worth touching on for a second. I guess everything you've just described there, these are all layers as opposed to a developer might have come across one of these and has potentially implemented one of these to some extent. But my understanding is it's DexGuard when we're talking about Android and iXGuard when it comes to ios it's the layering that kind of adds this like defense in depth approach is that right yeah yeah exactly right we always call it mutually reinforcing layers for classes encrypted if the things within it are renamed if the control flow has been changed like all of those things work together to just raise the bar of the complexity of being able to analyze that code and that's the key difference between proguard and our open source approaches a lot of companies initially thought, hey, well, let's use ProGuard.

25:52It has name obfuscation. Great. Now our code's safe. But a lot of times when you're analyzing an application, you don't necessarily need the real names of a class or a method to understand the behavior and what's going on. I mean, if you're familiar enough with code, you can kind of put two and two together. Sometimes there's decompiling tools that will conveniently, based on the logic contained within In a class, it will assign a name of meaningful value and then find all the other things with that same name and rename them for you. So there's a lot of convenience mechanisms if you rely solely on name obfuscation as the primary technique.

26:29So yeah, the layers are super important to work together to really provide strong defense. Yeah. And on that last point, LLMs, I'm sure, are very, very good at that as well. The obfuscation deriving meaning from it, I'm sure. So yeah, layering is very important. And this, I guess, could be the approach of, I'll just say DexGuard for now. I know we're going to talk about the fact there is both DexGuard and IxGuard, but it's a compiler-based approach, which is different to wrapper-based. And I think that's maybe some developers already understand or have encountered wrapper-based approaches. But yeah, could you maybe just speak to like, why did, I guess, you guys go down the compiler-based approach and how does that kind of differ?

27:10Yeah. So we talked about static attacks. The other side of that coin is the dynamic attacks. So things like people rooting devices and using hooking tools like Frida and others to manipulate at runtime what's going on with the application or inspecting things in memory or at certain key breakpoints within an application. so the other key defense strategy is runtime application self-protection or rasp for short which is a key detection feature where you inject these checks that are just making sure the environment and everything around the device is safe and not tampered with so checking the environment integrity checking that there isn't a debugger attached or these different debugging and hooking tools operating on the code.

28:00So yeah, static protections, dynamic protections, those are two key foundational principles for us. And then the way we apply those protections is through this compiler approach that you mentioned. And the key difference there is, you know, there's a few open source tools out there, SDKs you can download to implement some of these detections or some of these obfuscation techniques. But oftentimes these are SDKs or what we call wrappers where they take the application binary and they just encapsulate it with a layer of encryption. And at startup, it then decrypts the application and the application runs as normal.

28:43And they, in that startup or wrapper phase is where all the security logic lives to hide the encryption that's used and whatnot. But the challenge with this wrapper-based approach is that there's just one layer of defense. And if you figure out how that encryption mechanism or decryption mechanism is working, it's very easy to undo that security function. And then what you're left with inside is the complete transparent and original binary that can be tampered with or inspected. So when we got into this market, our experience with ProGuard, it was already doing a lot of code transformation and decompiling and compiling.

29:26So we had this sort of advantage to be able to apply that on the security front. And the benefit is we're decompiling the app, we're obfuscating it throughout, and then we're implementing these code injections that we do for these RASP features, these detections. And we're spraying them throughout the application in diverse ways and in many different locations. And then we recompile the app and sign it, or the user signs it with their original signing keys before publishing. And that leads to a very difficult to reverse and break security model because there isn't just one layer for you to attack and break apart.

30:09If you find one detection and you were to somehow intercept that, well, there's many more laying around. They're kind of like landmines or tripwires in effect. And the reality of being able to catch all of them and spend all that time to remove them since they've been woven throughout the code, the complexity is just so much higher so the time it takes for an attacker to figure all this out and find all these places and then break across all these different obfuscation layers it's just it's an insurmountable challenge and you know if a nation state really wanted to break protection on an application that's secured in this way it's definitely possible with enough time and resources but for the majority of attackers they just don't have the time and resources to be able to put towards breaking that kind of defense strategy.