All right. Thanks, everyone. My name is Ryan Johnson, and today I'm going to be giving a talk called
Still Vulnerable Out of the Box, Revisiting the Security of Prepaid Android Carrier Devices,
and I collaborated with Angelo Stavro and Mohamed El-Sabag for this research.
So today, just the agenda, we're going to start off talking about Android, then look at some of the preloaded software,
then we'll move on to applications and their application components.
After that, we'll move to application IPC, then we'll get to the core of the talk,
which is vulnerabilities in prepaid Android carrier devices.
After that, we'll move to some CTE-specific vulnerabilities, and then we'll zoom out a little bit,
look at some of the vulnerability root causes, move on to how to secure the software,
and wrap it up with some conclusions.
And this talk is somewhat like a continuation of the talk we gave at DEF CON 26 in 2018,
essentially on the same topic, looking at vulnerabilities in Android prepaid carrier devices,
so five years later, just showing that the issue still persists.
So we all work for Quokka, which is previously known as CryptoWire.
We were jump-started in 2011 on a DARPA project.
We've also worked with DHS, S&T, NIST, and at Quokka, we do software assurance, developer integration,
personal device management, firmware testing, threat fixing,
and security analytics.
So prepaid smartphones, these are going to be smartphones that you generally purchase in full price
at the time of purchase, and you generally get a prepaid service contract.
This is going to be a fixed-term service contract, usually one, maybe to three months.
Some of these smartphones are typically on the low end, so they could be anywhere from $50
up to maybe $300 or $400.
The major American market is the US market.
Most of the American carriers have a presence in the prepaid smartphone market.
You can see there's a picture there from Walmart showing T-Mobile, AT&T, as well as Verizon.
So in the prepaid market, Verizon has a large presence, since they own Total by Verizon,
which used to be called Total Wireless.
They also own Track Phone, as well as Straight Talk.
So Android is developed and maintained by Google, so they make the source code available
through the Android open-source project, also known as AOSP.
So Android is an open ecosystem where vendors can take a version of Android, fork it, and then modify it
to provide extra hardware and software features, which gives them kind of a differentiation in the market
and a competitive advantage.
And this is good, since it gives you something beyond plain vanilla Android, but it also requires some scrutiny
from a security perspective.
Some of the major Android vendors have their own security bulletins, so if there's a vulnerability
in their own code, which is not present in AOSP, then they will list it on their security bulletin.
And Android, it's the most popular mobile OS in the world, at 70.8%, and in America, with 42%.
So when you have an Android device, various entities are going to provide some software, so there's AOSP,
which is at the core of it, from Google.
There's going to be the chipset manufacturer and the hardware manufacturer.
They're going to add some hardware components as well as some software components.
If it's a carrier device, they usually put on some software as well.
There's the vendor, which does the customization, and then there's also vendor partners,
which is anyone from Netflix to Facebook to some app you've never heard of that doesn't have a launcher or an app icon.
So pre-installed software, this is necessary to make your device more functional than just a brick.
So some of the software is necessary, some of it is value-added, where the vendor thinks that you will find this useful.
So pre-installed software is more trusted and has more privileges than third-party applications,
because it's specifically curated by the device or the vendor or OEM.
So pre-installed applications get special access to permissions.
They can run a certain special UI.
They can run new IDs and run system services.
And on Android, processes are bound by an SELinux domain, as well as the rules that apply to that domain.
And a lot of this pre-installed software may contain insecure interfaces,
which third-party apps that you download can interact with.
In an Android, the main IPC mechanism is called an intent.
And you can think of this as a message with a destination,
as well as some embedded data.
So Android applications, when you install them, they have their own user ID,
as well as group ID, which are assigned at installation time.
And this helps to provide a sandbox for the application's files and resources.
In Android, applications are identified using a package name.
This is generally reverse domain notation.
And in Android, applications get access to data.
And capabilities using permissions.
So an application will declare what permissions it needs.
And there's different levels of permissions.
Normal permissions are granted to an application upon installation.
And then dangerous permissions are, at least for third-party applications,
to get them, they have to prompt the user with either an accept or reject dialogue.
And a user can also download an app and assign it to a specific role.
So maybe you download an app, you want it to be the default VPN or you want it to be
the default messenger or a notification listener.
This is, again, done through the GUI.
And Android apps are not monolithic.
You can decompose them into individual units called application components.
In an Android, they provide an activity, which is essentially a user interface that the
user can interact with, service for long-running tasks, broadcast receiver, registers for events,
somewhat like an event listener.
And a content provider provides access to structured data.
So application components, they can be started independently.
They can run concurrently.
And they perform dedicated tasks.
And all apps in Android have a manifest file, and this is somewhat like a specification,
which has their package name, version information, permissions they request, listing of application
components, and any hardware or software requirements.
And for external apps, they can run concurrently.
So for an external app, to interact with an application component in another file,
this is dictated by three attributes, which are listed in the manifest for the declaration
of an app component.
Android exported needs to be true.
Android enables, like, can't be false.
And an application component can set a permission, which is like an access permission.
So for an external app to interact with it, to send it a message, it needs to possess
that permission.
So here are some ways.
Some IPC mechanisms either done directly or indirectly.
Many of these are provided by binder in Android.
Some of the ones we'll talk about today are intents, bound services, and network sockets.
So the threat model is a local application that has either zero or one normal level permission.
And a normal level permission is granted to the application upon installation.
The application, based on that zero or one permission, appears limited and constrained.
We're not requiring any user interaction beyond installing and running a third-party application
once.
And then once this application is run, it turns to its environment and interacts with
insecure interfaces of co-located software on the device, generally through intents,
bound services, and sockets.
So, on to the carrier devices.
We looked at 21 Android carrier devices.
They are grouped by carrier, showing the vendor as well as the model.
So you can see TrackPhone is pretty well represented, because they're a pretty big player in
the prepaid market.
And here is a summary of the vulnerabilities in these devices.
So 86% of them leak non-resettable device identifiers to system properties.
81% of them.
percent of them leak the GPS coordinates to a loop back port like a debug port on TCP port
7000. Nine percent of the devices expose arbitrary file read and write as a system UID.
There's also 24 percent of them are impacted by a factory reset and this is when
essentially you wipe the user's apps, the app data as well as the settings. So if you have
any data that isn't backed up or synced externally, your data is gone forever so the user
can experience data loss. There's also arbitrary AT command execution which an AT command is a
command that's sent to the base band processor which is executed by the modem. 24 percent of
the devices were impacted and most severe is arbitrary command execution as a system UID and
nine percent of the devices were impacted. So I mentioned earlier that this talk
is a continuation of the talk we did at DEF CON 26. So here's a listing of the devices as well as
the carrier and the model and then the vulnerabilities that were present in each. So
non-resetable device identifiers, these are data items like the IMA, the Wi-Fi MAC address,
Bluetooth MAC address, serial number, the ICC ID and back in Android 9 there was a lot of data
information that was created that said if the user granted the device, the read phone state
permission, which an application could request, and if the user granted it to the application,
then the application could get these non-resetable device identifiers. And then in Android 10
Google made some changes so the permission was read privilege phone state instead of read phone
state which made it so that third party applications could no longer access these device identifiers.
Although, preinstalled apps can get the read privilege phone state permission. Access can also be
access the device identifiers and then leak them to a location which is accessible to a zero
permission third party application. And a common leakage location we noticed was system
properties. So system properties, this is a system wide repository of key value pairs. You
can see the get prop being executed with a snippet of the output and the get prop command can
be executed by any application. It doesn't require any permissions. SELinux can actually
restrict access to certain system property keys. That's not the ones we're going to talk
about. They're accessible by a third party app with zero permissions. So the system
properties contain version information of the build, version information about the chipset,
status of in it services and much more. And third party applications cannot write to system
properties which is enforced by SELinux. So the third party applications cannot write to
system properties which is enforced by SELinux. So here are the system property key names as
well as the non-resetable device ID that it leaks as well as the devices that are impacted.
As you can see here, the IMAZE is fairly common as well as the Bluetooth or the Wi-Fi Mac
address and the serial number. So based on the previous table, there's just a small code
snippet executing the get prop command. And then there's the serial number. So based on the
data, the data is being sent to the system. And then grepping on all of those patterns. And
then it reads from the command output and just writes it to the system log. And as you can see
here, this is being run on the track phone TCL A3X, which here, zero permission app can get
the device IMA, the ICC ID as well as the Bluetooth Mac address. Next, there is on certain
Android devices, they contain a system binary from MediaTek called MMS. So you can see the
MNLD. And the vulnerability here is whenever the GPS module is active, MNLD will open a debug
port on the loopback interface, TCP port 7000, that doesn't perform any authentication or
authorization to any clients that connect. It just starts emitting the GPS coordinates. And
the attack requirements here is just a local application that has been granted the Internet
permission. You can see the impacted devices as well as the path that's being sent to the device.
This system binary executes with the GPS user ID. And you can see the CVE there. And this
appeared in MediaTek's May 2023 security bulletin. And they've provided the affected chipsets.
We've noticed there's different behavior among versions, major Android versions for MNLD. So on
Android 11, 12 and 13, MNLD will bind to the loopback interface. This is a very common
feature. It will bind to the loopback interface on port 7000, which in Hex is 1B58. And then on
Android 9 and below, it will bind to any IP address. And we observe this going down to Android
4.4.2 device, which is Android KitKat, which is quite old. And at the bottom is just a source
code snippet to connect to port 7000 on the loopback interface, read from the socket, and then
write the output to the system log. So here is some output from connecting to the debug port. It
emits NMEA sentences. And we've redacted the latitude and longitude from the GPS coordinates
here. And we've listed the NMEA sentences that contain the user's GPS or the device's GPS
coordinates. So there's two different attack models you could do. You could have a passive approach,
where you could have a passive approach, where you could have a passive approach, where you could have a
malicious application to an application that has the Internet permission, just periodically pulls
port 7000 in the background to see when it's open. And whenever it's open, it can then just get
the device's GPS coordinates, record this longitudinally. There's also an active approach,
where a malicious application can start Google Maps or a similar type of application. And if
you've used Google Maps and given it access to your location, then it's going to send you an
as soon as you start the application's launcher activity, it will immediately activate the GPS
module, which will then open TCP port 7000, which application can then connect to in the
background and get the device's GPS coordinates. We also searched the GNGGA NMEA sentence on
Shodan, and there's 930 Internet-facing devices that are emitting that NMEA string. And 913 of
them are from port 7000. Next we're going to talk about the MMI group app. This is a pre-
installed app that exposes various capabilities, which I will talk about on the next slide. The
attack requirements are just a local app with no permissions necessary. You can see the
impacted devices that we've installed, that we've set up on top of the NMEA and that we've
listed. The package name is com.factory.mmigroup. On all the devices we looked at, it always had a
version name of 2.1 and a version code of 3. It executes as a system UID and the reserved CVE ID
is shown on the slide. So these are the capabilities that it exposes broken down by device.
So there's a factory reset, which I mentioned earlier, is a data wipe. It also leaks the
device IMEI, the device serial number, and exposes arbitrary AT command execution and you can
enable wireless adapters. So the workflow for this is the local malicious app sends an intent to
the MMI group receiver in the MMI group app. The MMI group app starts. It then dynamically
registers for various actions. It then sends an intent to the MMI group receiver in the MMI group
app. The malicious app then sends a broadcast intent using those action strings that it
registered for and puts the embedded data that the MMI group is expecting. The MMI group then
either queries some data or performs an action and it writes the result to persist.sys ATA ADB
result system property. And the malicious app then reads either the action string or the
data or the result of executing the action from that same system property. And at the bottom is
just a small source code snippet to send a broadcast intent which initiates a factory reset. So
the more interesting vulnerability here is arbitrary AT command injection. So this application
executes the a set AT command for AT plus power where the MMI group receiver in the MMI group is
the actual parameter is controlled by an intent extra that an external app can send and the AT
power AT command is not actually supported on the devices we examined and it's also not in the 3GPP
standard. So to inject our own command, we look at AT plus power equals that string is nine
characters. So we inject the backspace escape sequence nine times or its Unicode equivalent
and then put our own AT command and send that broadcast intent and then check the result from
the persist system property. So there's a source code snippet there where we inject nine
backspace characters and then execute the AT plus CNUM which returns the device's phone number
which is then read from system properties. So here's a demo on a T-Mobile rebel 6 pro 5G.
Here's the attack app showing that it has no permissions and it's going to execute AT commands in
the background. So just getting the device's phone number, getting the IMA, getting the base station
ID which is a proxy for its location, getting the ICC ID, getting the IMSI, getting the serial
number, calling 911, showing that 911 has been called and then programmatically hanging up.
Next we have another application that also exposes arbitrary AT command execution to
collocated apps. The attack requirements is just a local app. It doesn't require any permissions.
The package name is com.trackphone.tfstatus. As you can see by the path, the file name is
hiddenmenu.apk. This executes with the radio UID which is the UID that the telephony framework runs
on. So this is a very similar type of vulnerability where it's executing a different set AT command
where we can control the parameter which is from an intent extra. So this, the only difference is
it's 11 characters long and so we just inject 11 backspace characters. And there's also another
approach where you can stack additional AT commands by turning that AT command into a
AT command by injecting a question mark and then adding additional AT commands which are
separated by a carriage return. So at the bottom you can see there that it's just injecting 11
backspace characters, resetting the settings for the modem, and then calling 911 again.
So we have another hidden menu app. And as you can see, these applications are not that hidden.
The vulnerability here is that it exposes,
is a programmatic factory reset to co-located apps. Again, it's a data wipe where a user could
potentially encounter catastrophic data loss. The attack requirements is a local application
that hasn't been granted any permissions. The impacted device is a Boost Mobile
TCL 20XE. The package name you can see is com.tctgcshiddenmenuproxy.
The version name, version code, and that it runs as a system UID. And at the bottom is essentially
just a broadcast intent where you send a message or an intent to factory reset receiver and once it
starts it just programmatically initiates a factory reset.
In Android, application components can set an access permission that external applications
must possess to interact with them. So here there's a vulnerability where it says I'm protected by the
permission. But if that permission isn't declared either by that app, by any other pre-installed
apps, or the Android framework, then a third-party app can then declare that permission, set the
access requirements for it, and then interact with any application components which are supposed
to be protected by it. So we observe this in the TCL screen recorder app, and the vulnerability
here is that it exposes arbitrary file read and write as a three-dimensional file. You could
system user app to local applications. The attack requirements are just an application that
declares the missing permission and then requests it. The impacted device is a track phone and
AT&T TCL 30Z. The package name is com.TCL screen recorder. And we've provided the version
names, version codes, and it runs as a system UID. So the workflow is this malicious app
declares and requests the missing permission, which is com.TCT.Smart.SwitchPhone.Permission.
SwitchData. And it manifests and then also requests it. It then binds to the service that
requires this access permission that it just declared. It binds, after it binds to the service,
it gets an iBinder, which it then embeds into a messenger. And then it goes back to the
messenger. It then gets a message from this messenger, creates its own messenger, and then
sets it to the reply to instance field in the message with a what value of 1. And then sends it
to the TCT screen recorder app. And this is for bidirectional communication. And then on that
messenger it invokes function number 4, which is essentially just a what value of 4. It provides the
file it wants to access, which in this case, example, just SD card, DEFCON 31.TXT on
external storage as well as the mode, which would either be read or write. Then the TCT
screen recorder app responds to the messenger that was provided in step three that the
malicious app receives. In the bundle, there's an extra named file descriptor which
contains a parcel file descriptor, which it can then put into a file input stream for
reading or a file output stream for writing and perform whatever operation it wanted to on
the file that it indicated. So there's something called factory apps. These kind of provide a
centralized location for testing of hardware and software functionality. These can come by
many different names, engineering apps or hidden menu apps, factory apps, and so on.
These generally cannot be disabled or installed by the user. You would need root access or
potentially an exploit to remove or disable them. They run with a system UID, which makes them
quite privileged. Generally, there's no launcher activity, so the user is unlikely to actually
use them. So we talked about the MMI group already. Now we'll cover the FQC app as well as
the Transion factory app.
So the Evenwell FQC app, this exposes local arbitrary command execution to co-located
applications. The attack requirements is just a local app with no permissions necessary. And the
impacted devices are the Verizon sharp rovo 5 and the track phone blue view 2. The package name
is com.evenwell.fqc. You can see the vulnerable version names, version codes, the path it runs is a
system UID and the reserved CVE ID. So this one kind of has an interesting workflow. The malicious
app starts the show barometer activity. The FQC app then starts this activity. And when this
activity comes into the foreground as part of its on resume activity life cycle, it sets a system
property called persist.sys, prevent power key to a value of on. And if this activity moves into the
background as part of its on pause activity life cycle callback, it sets the system property to off.
And to actually execute commands in the context of this app, the persist.sys, prevent power key system
property needs to have a value of on. And FQC app cannot have a foreground activity which it
checks before executing a command. So the way we achieve this is we crash the app while that
activity is in the foreground. So we send a broadcast intent to FQC broadcast receiver with a null
string, which at run time the application does not check to see whether this action string is
null. It operates on it and encounters a null pointer exception. And this sets the requirements
where we have the system property to the desired value and there are no activity components of the
FQC app in the foreground which the FQC service checks before it will execute a command. So then we
send it an intent with the command we want to execute. And then we send it an intent with the command we
want to execute in the turn off heater string extra. And executing commands in the context of a
system UID app is very powerful. This is a very limited set of capabilities. You can grant
arbitrary permissions to apps. You can install apps and then grant them the permissions. You can
perform a factory reset. You can record the device's screen from the background. You can drive
the GUI by injecting arbitrary input events and then also perform a factory reset. And then you can
run operations with app ops. So here we have a demo. We have bad app, which is going to install an
app programmatically using this vulnerability called all perms and then granted all permissions
available to a third party application. And this is on the track phone blue view, too. Just going
to the app info, showing that this application does not have any permissions. We're going to run
it, start that activity, crash it, and then interact with the app. And then we're going to run it,
do the FQC service in the background to install an app and then grant it all the permissions
available to a third party app. So there it is, all perms, going to its permissions. This shows
kind of the course view of the permissions it has. And then moving to the more granular, you can
see that this has quite a few permissions, which could be abused to surveil the user. And then
we're going to run it, check it, and then we're going to run it again and then we're going to run it
Thank you. Thank you. So the best we can tell, this even while Digitech, company that created
the app, they have, they're a Taiwanese company, they have an app on Google Play, a test app, and
this use to be on Nokia devices, which were on Android N and Android O, or whatever, and that's
Nougat and Oreo 7 and 8 and then they removed it in Android 9 or Android Pie due to a battery
issue. And then looking at honehi.com, there's a PDF there that shows the ownership of this
Evenwell Digitech Inc. company which is owned by Foxconn. So here's another application that
exposes the same vulnerability, exposes local arbitrary command execution as a system user to
co-located apps. Again, you just need a local app that hasn't been granted or doesn't
request any permissions. The vulnerable device is the Itel Vision 3 Turbo. It's an unlocked
device. The package name is com.transion.autotest.factory. You see the file path, it's
factory.apk. The version name, version code, and runs as a system UID. In this workflow the
malicious app needs a file system location that's both readable and writable. And then you can do it by
malicious app and the factory app. So it takes its base scope storage directory, makes it
globally readable, writable and executable. It then creates a shell script in this
directory with whatever commands it wants to execute, makes it globally readable and
executable. And then it creates another file. It needs a specific file name that's expected by
the factory app, run script file.txt. And in this app it essentially runs our shell script in
a shell that was from step 2. Makes this file globally readable and executable. It then
interacts with a broadcast receiver component named command receiver. And it sends the file
path to the run script file. And then factory app in the command receiver, it reads the
the contents of that file which executes a script and then it writes it to shared
preferences. The command receiver then starts monkey background service which
then reads from shared preferences and executes the script with system
privileges. Next we're going to talk about some ZTE specific vulnerabilities.
There's three of them that we discovered. The most severe is the first one which
is an arbitrary file right as the Android system which is system server. If
you're familiar with Android this is the Android framework, this is what most
applications request functionality and data from and this the way this is
accomplished is by a zip file that employs relative paths using path
traversal attacks. There's also another vulnerability where you can start
arbitrary activity components.
in the context of a system UI app
where all the intent fields are externally controlled
except for the action string.
And then lastly, there's a vulnerability
where you can delete arbitrary files
or delete directories recursively
in the context of the settings app
which runs with the system UID
and all three of these vulnerabilities
do not require any permissions
except the last one checks to see
that you have one of four different package names
where none of these package names are actually installed.
So you can boot up Android Studio
and create an application with whatever package name
you want to fulfill this
and it doesn't check the actual app signatures.
It's just checking the package name
which obviously is not secure.
So this is from ZTE's security bulletin
showing the impacted devices
up to what version is impacted
and as well as the security
and the software version that it was fixed in.
So this is the workflow.
We have a local malicious application.
It creates an AndroidX file provider
and it just needs a URI authority
that starts with com.zte.beautify
because system server checks with strings starts with
instead of strings equals
which is obviously more discriminating.
So we just create an example URI authority of com.zte.beautify
underscore potatoes.
And the malicious app then in its assets directory
like within the application,
it then unpacks a zip file to its internal storage
into a directory that is shareable by its file provider.
It then grants system server
which has a package name of Android,
read access to this zip file that it just unpacked.
Using the standard API from the context class
called grant URI permission.
It then broadcasts an intent
with an action string of com.zte.beautify theme change
with the URI to this zip file
which is employing path traversal attacks
using an extra named theme underscore URI and theme ID.
Can be any arbitrary string.
System server then unpacks this zip file
which we granted it read access to.
It doesn't enforce any constraints on any of the file types
or file names.
It also doesn't protect against
any of the path traversal attacks.
It doesn't canonicalize the path
and enforce any constraints there.
So it essentially just in its context
executing the system UID as like the Android framework itself
overwrites files.
And in certain cases,
depending on what is overwritten,
a third party application can cause a system crash
just by an uncaught exception in the system server process
to trigger initialization routines.
Say if you did overwrite another application
or overwrite the screen lock database
with a screen lock database copy
that does not require any pin or a pattern.
So here are just some of the use cases.
You can uninstall apps.
You can overwrite applications.
You can overwrite app libraries.
You can overwrite the screen lock
which will work once after you perform a system reboot.
And at the bottom, you can see the crafted zip file.
It's called not evil dot zip.
And as you can see, it's using relative paths
which move up the file system and then overwrite
the lock settings database as well as its journal file.
So here we have a video from the ZTE Axon 40
showing that we have a screen lock.
And this is done with another phone
just because we have to do a system crash
and to show it in one take.
So we just showed that we have some pictures there.
This is the attack application showing
that it has no permissions.
So now we start an arbitrary component, perform a phone call.
We don't have service on this device.
We delete the user's photos.
And then we're going to start WhatsApp
showing it's the official legitimate version of WhatsApp.
Then we go back to the POC app.
We overwrite the screen lock database as well as
WhatsApp with a repackaged version, cause a system crash.
Now it's going to boot up showing that the device no
longer has a screen lock.
So there was no screen lock there.
We open up the photos.
User's photos are gone.
And now we run WhatsApp, which is our own version,
which is just kind of a silly version.
But if we wanted to be malicious,
we could have a repackaged version of WhatsApp
that appears to be WhatsApp that gets the user's data
surreptitiously and sends it off.
And so just to summarize, looking
at some of these vulnerabilities, some
of the root causes, there's definitely some failure
to perform access control at application component
boundaries, at interfaces, on network sockets.
Also, when you are unzipping a zip file,
you certainly want to canonicalize the path
and enforce some constraints.
in Android 14 applications that target Android 14, there are some platform defenses which are
going to prevent escaping using relative paths. And if you try and protect your application
component with a permission, and this permission isn't declared anywhere, it obviously doesn't
provide any protection. And in many cases we saw a lack of a whitelist which could at least
kind of constrain what a user could do and limit the impact instead of having it be completely
unbounded. And also relying on just the package name of an application doesn't provide you with
any real security as I mentioned earlier. You know, you can use Android studio and create any
arbitrary activity or arbitrary app with whatever package name you wanted. And just some
suggestions.
So vendors could use some showing, looking at these vulnerabilities, some sort of proactive
scanning of devices actually before they reach the user. Also maybe some sort of certification
showing that the device has undergone some sort of security analysis. Enterprises need to
constantly monitor and regularly scan assets in order to enforce security policies. The user, if
you see some of these preinstalled applications, you may want to disable them. And if there is a
preinstalled application that's vulnerable to arbitrary command injection, if you execute that
command, you can have the application disable itself. So to kind of close that vulnerability.
And the way we find these vulnerabilities is a firmware pipeline where you can run a firmware image,
or a set of applications, run it through some static analysis engines, looking for violations,
using vulnerability patterns, applying some filters to it, and then creating POC. And after
introducing all these vulnerabilities, Quokka has an application called QScout which you can
download for free and run it on your device to see if your device is impacted by any of these vulnerabilities. And the QR code is
the code that takes you to the Google Play link to download the application. And just to wrap it up,
so third-party applications, even though they may appear limited, they can interact with their
environment looking for insecure interfaces of privileged preinstalled software. And any time you
have some software and it goes out there, I mean, you should assume that people are going to spend copious
amounts of time reverse engineering your software, looking for software flaws. And as shown by this
presentation, privileged preloaded software could use some increased security vetting. And you should
read our paper. It goes into much more detail, has POC code. It's about 70 pages. And you can contact us at
OEM at Quokka.io. Try the QScout app to see if your device is vulnerable. And if you would like to
continue the conversation, we'll be at Yardhouse at Link at 1.30 today. And I'd like to, that's all for the
presentation. I'd like to thank you for attending.
And it looks like we have two minutes maybe. I don't know if that's enough for questions. But if there
are.
Any other questions? Of those, the blade X1 from visible, it didn't have any of those
vulnerabilities. It was actually part of the data set but didn't contain any vulnerabilities.
If you were limiting it to that set of devices, yes.
All right. Well, if there's no more questions, thank you very much for attending the talk.