Gregor Van (3:32)

Yeah, nice. So then I guess Guard Square as a company, what's the origin story there?

Ryan Lloyd (3:38)

Yeah, it's an interesting one. So the original founder of the company started an open source project called proguard. And that open source project was initially focused on optimizing and shrinking Java applications, just making them smaller, more efficient, things like that. And, 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. And 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 Dex Guard, which applied this and many other concepts to obfuscate and secure mobile application code. And 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.

Gregor Van (5:30)

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 any names of obvious customers? I guess just sort of what's the kind of scale here of how this is being used?

Ryan Lloyd (5:48)

Yeah, so we have around 1,000 paying customers and they're protecting apps across a range of industries. So around 40% of our customers are in the finance vertical.

Gregor Van (6:00)

Right.

Ryan Lloyd (6:00)

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 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. Healthcare 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.

Gregor Van (6:54)

Yeah. So we're going to get into 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.

Ryan Lloyd (7:09)

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.

Gregor Van (7:18)

Yeah. So 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, 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. What really sets apart the mobile landscape from this perspective? What are the things that guardskir needs to be looking at?

Ryan Lloyd (7:55)

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. I 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. The 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.

Gregor Van (9:36)

Yeah. 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.

Ryan Lloyd (10:02)

And there's two kind of paradigms to mobile security. There's mobile device security and there's mobile app security. 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. And 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.

Gregor Van (11:07)

Yeah. And then if we just looking 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 binaries, you downloader 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 Guard Square has evolved? I guess, yeah.

Ryan Lloyd (12:18)

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 hole like any good Internet effort. A community. Right. A community of tools and knowledge and expertise that's been widely distributed and up until the last year or two 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.

Gregor Van (13:26)

Yeah. And then what is, I guess, 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 onto, are trying to be protected against here?

Ryan Lloyd (13:42)

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. We've also had some high profile consumer companies that build consumer technology with a heavy mobile component to it. Concerned about like 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. And 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 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. So 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. The 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. 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. So 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.

Gregor Van (17:48)

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 complian and just that compliance is only getting increasingly more stringent. How does that factor into if you're a company distributing a mobile app, what kind of compliance are you? I guess let's say at bank level, what are you expected to be showing and doing?

Ryan Lloyd (18:17)

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. So 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. In 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. So 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 Guard Square 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.

Gregor Van (20:48)

Nice. 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? Like, how do they intersect or where would you like to start?

Ryan Lloyd (21:01)

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. And 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 effort and time that they would spend.

Gregor Van (22:51)

Yeah, I mean, to some developers this is sort of similar but different to, you know, like minification effectively, where minification being that it's obviously very clear how to effectively it's obfuscation, but also compressing. But it's obviously 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 de obfuscate the code. At the end of the day, you can't see what's running there.

Ryan Lloyd (23:23)

Yeah. And the main way we achieve that is through a lot of different layers of obfuscation techniques. Right. So 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. But 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 FL 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. So those are all examples of some of the features that we use as techniques to defend against static attacks and techniques.

Gregor Van (25:00)

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 Dex guard when we're talking About Android and ixguard when it comes to iOS, it's the layering that kind of adds this defense in depth approach is that right?

Ryan Lloyd (25:28)

Yeah, yeah, exactly right. We always call it mutually reinforcing layers. If a class is 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 has name obfuscation, great, now our code 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 you, 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 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. So yeah, the layers are super important to work together to really provide strong defense.

Gregor Van (26:34)

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. This I guess could be the approach of. I'll just say Dex Guard for now. We're going to talk about the fact there is both Dex Guard 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. Why did I guess you guys go down the compiler based approach and how does that kind of differ?

Ryan Lloyd (27:10)

Yeah, so we talked about static attacks. The other side of that coin is the dynamic attacks. So things like people routing 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 just 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 so, yeah, static protections, dynamic protections, those are two key foundational principles for us. And then the way we apply those protections is through this, this compiler approach that you mentioned. And the key difference there is, you know that a lot of, 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 and they, in that startup or wrapper phase is where all the security logic lives to hide the encryption that's used and, and whatnot. But the challenge with this wrapper based approach is that there's just one layer of, of defense. And if you figure out how that encryption mechanism or decryption mechanisms 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. So we had this sort of advantage to be able to apply that on the security front. And the, 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. If 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.

Gregor Van (31:00)

Yeah, and a kind of, I guess, extra level here is SDK hardening effectively. So SDK developer shipping code runs inside other people's apps. How does or doesn't this work with a solution like DexCard? Because you're having to then also consider, I guess, any security that's then working just on the pure app level as well.

Ryan Lloyd (31:25)

Yeah. So we've been securing Both apps and SDKs for many years now. So some of our financial services customers are building payment SDKs that are baked into a lot of other different applications. So all the techniques we've talked about here, code obfuscation and RASP techniques, they can equally be applied to a library or an SDK that you're developing. You know, again, we're just compiling and decompiling. Now. There's certain features that look different in an SDK than in an app. You know, things like tampering and resigning. You know, when you publish an app, it has a signature and that signature can be checked and validated to make sure it hasn't been tampered with. An SDK is going to be included in an app, so there'll be different parameters in context, so there's different features for security between SDKs and apps. But fundamentally, the model of applying these different layers of techniques and defenses can be applied to both. And the biggest thing we do occasionally see is that if we've protected an SDK, sometimes that detection mechanism that's baked into that SDK can trigger if the app that consumes it was protected using other tools that are using techniques that conflict with that SDK protection. So that's something that occasionally we'll come across where there's configuration changes that need to be made to ensure compatibility in those cases.

Gregor Van (32:52)

So, kind of moving, I guess, on from the implementation of this, if we actually look at sort of security testing, I assume that Guard Square also does security testing as a part of whether it's through the tools themselves or potentially as a service. But. But you must have seen a lot in this phase. So, yeah, I mean, what are we talking about when an unsecured app, what's some of the kind of most, I guess, common or most crazy things you've seen come out before that hardening process has taken place?

Ryan Lloyd (33:26)

Yeah. So we used to focus exclusively on mobile app protection and applying protection to apps, but around four years ago, we invested in building out some product capabilities around mobile app security testing. And the reason for that is our goal is to help developers secure apps. And you can have an app that's well protected but still have inherent vulnerabilities within it. You know, one doesn't kind of necessarily address the other. So we wanted to provide security testing as a capability. And the main reason, because there's been a lot of security testing tools on the market for years. I mentioned companies I was with in the past, you know, so you've got like Veracode and Checkmarks and all these companies that do security analysis of code. But a lot of them kind of operate at the language level and weren't really specialized in the kinds of vulnerabilities and risks that exist in mobile apps. So we saw a bit of a gap there, just security checks that really weren't relevant or in existence for mobile app developers. So that was kind of the decision for us to build this tool, this capability. So when we launched it, we tried to get as many apps scanned as we could to really pressure test the findings and optimize that over time. And in that process, yeah, we found some interesting things. I'd say there's three kinds of vulnerabilities that we most commonly see. The first one is just hard coded keys. So it turns out that despite all the technology that's available to try and prevent this, people still make mistakes and hard code security keys inside their application code and don't do much to protect or mitigate that.

Gregor Van (35:11)

Old habits die hard, clearly.

Ryan Lloyd (35:13)

Yeah, yeah, exactly. So we did an analysis of a little over 5,000 banking apps for Android and we found 164 hard coded keys that were contained across those applications. And these are keys for things like AWS infrastructure, different security endpoints that they have in their application, tokens that are used as part of their authentication flows, things that just with an attacker coming across them, they can take advantage of infrastructure or authentication bugs to exploit an application. So hard coded keys is still a big, big one that we see. Insecure communication is another. So here I think everybody knows that they should be using tls and securing the communications between their mobile app and their, their backend APIs. But it turns out that there's a lot of mistakes that can be made in the implementation of tls and to do it correctly, verifying the certificates. And so there's just a lot of unique vulnerabilities, a whole class of them that can exist in an application and if you get something wrong, then the app is subject to man in the middle attacks where somebody on the same network can intercept and interfere with the data that's being shared. And then the third case that I think is really interesting that we've seen, we used to just do static analysis of application code to find these kinds of vulnerability vulnerabilities. And then we realized actually it'd be interesting if we interactively evaluate the application during runtime to find other classes of vulnerabilities or concerns an app developer might have. And one of the interesting use cases we had for this was identifying third party libraries and which endpoints they're communicating with. Because app developers, you know, you build up this mobile app, you rely on very heavily on third party libraries and frameworks to do all sorts of things. If you want to implement advertising in your app, you rely on these ad libraries, you want to capture some user behavior analytics, you rely on these libraries crash reporting other libraries. So there's a huge supply chain of third party dependencies and it turns out not all of them are doing the right things. So our interactive analysis feature allows you to identify all the endpoints your app's communicating with, so you can review them and determine, you know, are these expected, are these trusted, or is there something going on here, leaking data from my application that I wasn't expecting or I don't want to exist. So some good privacy checks there that app developers can implement.

Gregor Van (38:01)

Yeah, from where I sit, I'm not working on mobile apps specifically, but I'm definitely seeing from a security perspective, I guess what's termed is like egress restrictions being really looked at a lot more closely now. So if developers are able to use a tool, not always is it kosher that they're able to call, exfiltrate the data off to an endpoint that they would like. So that's definitely seeing if you want to call it a trend. A trend being that we've seen kind of the bad cases now of, of where data can leave a platform kind of unchecked and where it heads off to. So that makes a lot of sense and just kind of, I guess going back to also in a sort of current and past life having to submit apps through these are web apps, for example, but web apps through security screening checks. And the thing that always frustrated me was, okay, you get a bunch of usually hopefully minor or medium requests on what's going on, but if these services provide remediation steps, they're incredibly basic, that doesn't really apply to the code that you've written and you have to go and do a Whole bunch of figuring out what do they actually mean when they want us to tighten this bit up. Whereas if you have this integrated solution, which sounds like you guys do, then you're able to look at the findings. But at the end of the day, the product is right there to then tighten up all these pieces.

Ryan Lloyd (39:23)

Yeah, yeah, that's right. So for us, we always offered these discrete tools for protection and for testing and threat monitoring and such, but in the last year we brought them all together into this platform and the main reason there was just to make all these tools really accessible. So if you're going to recompile your app at build time to apply these security protections, well, you might as well submit it for an analysis and get a scan back at the same time to identify any regressions or vulnerabilities that have been introduced. And, and our focus on findings with our security testing has always been to be very precise and to err on the side of actionable versus noisy. You know, a lot of the code based static analysis tools, yeah, as you said, they'll uncover thousands of findings, but many of them are meaningless. And when you go and triage them, it. Well, in this context that's okay. So we try and eliminate that by being very reserved, I guess, in what we flag as a vulnerability and making sure that each of them are accompanied with directing you where in the code this vulnerability exists and recommendations on what steps you need to take to resolve it.

Gregor Van (40:32)

Yeah. Nice. And I believe there is another, I guess, piece to the suite, ThreatCast. So that's like real time threat monitoring. Like how does that, that fit into all this?

Ryan Lloyd (40:44)

Yeah, so I mentioned, you know, we've been in this mobile app protection business for, for some time now, and one of the questions our customers kind of always wrestled with was, okay, my app's protected, but like, do I really need the protection? Has anything nefarious actually been going on that really matters? And it's kind of like equivalent to, you know, you think you secure a building or a house, you know, you lock the doors and you know, you don't know if anybody was trying to pick the lock or if anybody's been prowling around. So threat monitoring for us was kind of like the equivalent of installing doorbell cameras or outdoor cameras to supplement the locks. It gives you visibility into attempts to target or manipulate your application and just a lot more rich analytics on the threat model. So rather than just protect it, ship it and hope it's secure, you kind of have some, some verification of how well secured is it and collecting Data that can be really helpful to correlate with other data points in case of some form of security event. So for us, threatcast was a way to introduce that, that visibility for once you've released your app. So you get that feedback loop on what threats occur, who's using the app, where in the world, on which devices, which code functions have they been attempting to hook? And it can help you kind of get a really clear picture of maybe victims of phishing and fraud that are trying to use your app, as well as kind of following the chain back to where the reverse engineering started in that phishing campaign and who created a tampered version of your app to begin with. So it's a lot of threat intelligence information that can be really useful for companies.

Gregor Van (42:35)

I'm just curious, is this from an implementation? This is, I don't know if you've heard of Canary. Canary is this service. Yeah. That drops these little files like into your Google Drive or something and you call them.

Ryan Lloyd (42:48)

Yeah, I think Scanary, I think it's called.

Gregor Van (42:49)

There we go. Yeah. Is it kind of the same idea that developer trips over something like, oh, I'm trying to hook this function and in doing so they basically trip something? Is that kind of how it operates?

Ryan Lloyd (43:00)

Yeah, very similar. So those dynamic detections that I talked about that we spray and inject. Yeah, they're all these little tripwires that are constantly checking the state of the environment, the state of the memory, you know, whether debuggers are attached and if code's been manipulated at all and just detecting the different reverse engineering tools that exist. And it's those tripwires that are sending signals along with other sort of basic data that's collected to put into this threat intelligence database.

Gregor Van (43:29)

Nice. Yeah, I think it's always love that technique. It feels so simple, but it's so effective. And if we just also look at attestations. So I mean, we've covered this in the past on SE daily. Again, more from attestation of packages that end up in open source, like that end up in larger applications. Do you know who actually has provided this code? Is this the actual, actual open source package from the actual maintainers, which is becoming so important these days? And again, I believe there's some aspect of that in the guard square approach.

Ryan Lloyd (44:07)

Yeah. So last year we implemented an app attestation capability. And the primary purpose of this is so that you can verify on Your back end APIs that the person or device calling into that API is a valid and trustworthy device. So what we heard about is just examples where people have an API endpoint for, let's say, authentication, and they would get these credential stuffing attacks that are targeting their authentication endpoints. And those credential stuffing attacks are just scripts and things that are just calling into their API. So attestation gives us a way to, in the mobile app, request a encrypted token from Guard Square that's signed using a private public key pair that our customer provides. So we'll take their public key that they've shared with us to sign this token, send it back to the mobile app based on the threat data we've collected, that asserts whether that device is trusted and meets certain policies and such. And then that token from their mobile app can be attached to any API request that they make. And then they'll use our server side SDK along with their private key of this key pair to decrypt that token and inspect whether it was a passing or failing result. And so if a bot or script tries to contact that API endpoint, it won't have a token, so it'll just fail and they can reject all that bot activity. If it's an attacker trying to replay a token, you know, there's a validity period and such. And if it's somebody using a device that's been tampered with or an app that's been tampered with, the token that we've provided will be a failing result. So it just kind of closes the loop and allows you to not just secure, secure your mobile app, but also secure your API endpoints and make sure only your mobile traffic that's vetted and trusted can communicate with those APIs.

Gregor Van (46:09)

Yeah, very nice. I guess looking at sort of guardsgrow total. I mean, these days, at least just from where I sit, like looking at a bunch of security companies, the research piece is one of almost the most important in terms of visibility and that trust piece of believing that there are people that really understand what's going on out there. And obviously it's great if you're able to come up with research that nobody else has on a certain vulnerability or so on and so forth. But yeah, how does Guard Square approach that piece? And is that a dedicated team or do you share it around or how does that work?

Ryan Lloyd (46:48)

Yeah, so we have a security research team and they kind of serve a few different roles for us. One is anytime we're developing new security, security features or mechanisms in our products, they're the first people to try and break it and put it through its paces to make sure that it really meets our bar for a security feature. So there's sort of an internal kind of pen testing angle to building the software that we built. And we just hire these experts in our security research team that know how to attack things, break things and find weaknesses. So that's one purpose of that team, but the other is to sit on telegram channels and, you know, go over the Internet finding new GitHub repositories that are popping up that have all the latest developments in reverse engineering tools and technology. Because these things don't stand still.

Narrator (47:38)

They're.

Ryan Lloyd (47:38)

They're moving fast. And the value of our security protections relies on kind of staying ahead of or in near proximity to the development of all those tools and techniques for attacking mobile apps.

Gregor Van (47:53)

Yeah, we had someone on from Wiz, which is cloud security. And yeah, I was asking them, where do you go these days to find any of this stuff? And sort of used to be you could kind of actually be Twitter, for example. We'd actually have quite a lot. And it's just being pushed further and further away from the fringes and you've got to go find your discord channels and your telegrams and all that kind of stuff.

Ryan Lloyd (48:15)

Stuff, yeah, yeah, yeah, exactly right. And then occasionally when we do this kind of research, we'll come across something novel or interesting that we do want to share. So, you know, we'll write blogs and technical articles that describe how these things work and steps you can take to mitigate it. One of the things we have is our security research center on our website, where sometimes we'll just describe, yeah, different code snippets and examples of how you can mitigate some of these risks. So even if you're not someone who's looking to leverage our technology or our tools, we provide some knowledge and resources out there for folks that are trying to do it themselves.

Gregor Van (48:49)

Yeah. And looking ahead, we touched on it, I think, towards the beginning, actually. Just like how LLMs are probably upending this space a bit. But what are you guys looking at when you sort of think, well, over the next one, two, three years, where is this going? I mean, I'm curious because from a pure app perspective, yet most of the apps I use daily are quite functional apps. Finance is a huge one. Now I have a whole folder of finance. I've probably eight different finance apps of some description, linked institutions, not just charting something for whatever reason. I seem to have lots of. Maybe because I've lived in different countries, you end up having to collect bank accounts or something to that effect. I feel like what I do on my smartphone, my iPads these days, it's very functional and it's very important. Less of, I guess for me, a bit less of the gaming and this kind of thing. But where are you guys kind of looking when you look across the next few years?

Ryan Lloyd (49:46)

Well, I think the whole reason I came to Guard Square and joined the company was that I saw a pretty long Runway of growth ahead for the company for two reasons. One, mobile apps are just becoming so pervasive and important and I think that trends, you know, every year there's just more important things I do on my phone than I did the previous year. So that's one sort of dynamic. And then the second is security aspect. I think our biggest observation around mobile app security is that it hasn't really reached its pivotal moment, its CNN moment. You know, there hasn't been a lot of coverage on mobile app security. High profile, you know, issues. You know, you'll see things in the public like, oh, there's a data breach or there's a security event, but rarely does it get down to the detail of, oh, well, the mobile app was, you know, a real risk or concern in this. So I think we're still in the early days of that sort of forming and right now it's the attackers and these communities that are building up the knowledge and, and such. So for us, the future is just about creating awareness and just trying to stay ahead of how these attck techniques develop so that, you know, we try and reduce as much risk as possible in lockstep with the sophistication of mobile apps. And yeah, LLMs definitely are a vector that we've got to be aware of because I think it does, it democratizes a lot of the attacker knowledge. I don't, I don't think the LLMs are going to invent any new novel way to perform reverse engineering or an attack, but it makes it more accessible to more people. So, you know, you end up with more attackers than you did before and more people trying to maliciously target apps for all sorts of reasons. I want to do account takeovers so I can steal the loyalty or reward points from Name any app that has loyalty or reward points these days. So a lot of different motivations and that's kind of how we see the next few years is just trying to keep pace with that. We call it the cat and mouse game. Constantly trying to unearth these things.

Gregor Van (51:58)

I guess one industry, if you like, that we haven't maybe touched on but could be interesting, is like Mobility and at the end of the day vehicles have apps loaded into them by the dozen now. So yeah, I imagine that's an area that maybe is on the radar or you're already supplying to mobility. Yeah, yeah.

Ryan Lloyd (52:17)

I mean, when we say we support Android, Android kind of can be used in a lot of different operating modes, not just a phone per se. So yeah, we definitely have some examples in the automotive and logistics space that are like that.

Gregor Van (52:31)

Yeah. So I guess a developer today listening something that now understands why they need to secure their apps. Better late than never, as they say. But where to go to kind of get up and running, I guess. Yeah. Where's the best place?

Ryan Lloyd (52:44)

Yeah, so there's a few different things that I could suggest. I mentioned earlier the OWASP working group around mobile app security, that's a good place to start because they have a whole verification standard, talks about the different levels of security depending on the sophistication of your app and the use case. And then they've got categories of concern, things like privacy, communications, storage, etc. So it's a good way to get a broad understanding of the security disciplines and considerations for mobile apps. We put out a new blog post every single week on our website, Guard Square website, some of them very technical, talking about different attack techniques and, and things we've uncovered in our security research and sometimes just, you know, high level information around compliance and things that appeal more to the security teams. And then we have our security research center. So if there's a specific threat that you're concerned about, it's a good place to check to see if we've got any documentation on it and specifically around the topics of malware, for example, or creating a device binding between your mobile app and your server. Backend some good articles on topics like that. So yeah, those are the resources I'd start with and get smart about it. And then if you're serious about looking for security protection, feel free to reach out to us.

Gregor Van (54:09)

Yeah, well, thanks so much for coming on. I mean, I think even though I work, or especially used to work very much in security and I sit across a bunch of things now, but I've definitely learned something today. I haven't really fully appreciated all the kind of ins and outs of how our apps I'm using, how they can all be infiltrated, so to speak. So yeah, really interesting and I'm sure all of the audience have learned something new today as well. So thanks for coming on and I'm sure we'll catch up again in the future. All right.

Ryan Lloyd (54:37)

Pleasure. Thanks for having me.