A hand holding a phone.

Fellowship: APKQF – Simplifying Android Forensics

This blog post was written as part of the Digital Forensics Fellowship by one of the 2022-2023 Fellows. 

About me: My name is Paul Aguilar, I was born in Mexico, I’m a Computer Engineer by profession, and passionate about technology and free culture by choice. I am currently Coordinator of Digital Security at an organisation called SocialTIC, a Mexican NGO that works on the strategic and secure use of technology. At SocialTIC I work with journalists, activists and rights defenders in Mexico and Latin America, facilitating training and support on digital security, as well as assisting with rapid responses to incidents and the development of policies and protocols. I also maintain (along with my team) digital security content and resources on the Protege.LA site and at SocialTIC.

Regional context

In 2016 and 2022, SocialTIC, together with other local and international organizations and media, made public the #GobiernoEspía and #EjercitoEspía campaigns respectively, where we documented attacks on journalists, activists and defenders using the Pegasus spyware.

With the publication of #GobiernoEspía, Mexico became the first country in Latin America to document the use of this type of technology, while #EjercitoEspía documented the use of Pegasus by two different governments in the same country. This was despite statements on spyware by the current government.

There is evidence that in 2021 Pegasus was used in El Salvador against various journalists and local media, as well as evidence that between 2020 and 2021 Pegasus was used in the Dominican Republic against the journalist Nuria Piera. This illustrates the increasing use of spyware in the region, not to mention other types of surveillance and spying technologies.

At SocialTIC I have been able to observe first-hand the evolution of spyware in the Mexican and Latin American context. Given this context and in view of the need for more professionals in the field of digital forensics in defending human rights, I decided to apply for Amnesty International’s Digital Forensics Fellowship.

Current state of digital forensics defending human rights

Early Pegasus attacks required victims to click on a malicious link (1-click attacks) to begin the chain of exploitation and infection. These links allowed the first cases to be detected and documented in Mexico.

Currently, attacks are carried out by exploiting zero-day vulnerabilities which do not require any interaction by users (zero-click attacks) and can be completely unseen.

This evolution has meant that the detection of attacks is more complex and requires deeper analysis in the field of forensics for the defence of human rights, which led to the development of various tools such as the Mobile Verification Toolkit (MVT) by the Amnesty Tech team as well as a methodology for their use.

When it comes to companies, the situation varies. In Apple’s case, the company has taken the initiative (as a result of work carried out together with civil society) by sending notifications about “State-sponsored attacks”, which has made it possible to identify potential cases of attacks or spyware infections of Apple devices and accounts. This in turn is linked to the homogeneity of Apple’s ecosystem of products and services, which allows greater control and standardization of the information collected and analysed in a forensic process.

In the case of Android, there is not the same level of homogeneity or standardization in the internal structure of systems or devices. For example, there are a variety of versions of the operating system that differ from each other, as well as a wide range of manufacturers that add an extra layer of customization on Androids, or that incorporate additional tools to those that are inherent to the system. All this means that the forensic analysis of Android devices is more complex.

While Google has also taken the initiative to send notifications about “Government-backed attack alerts”, these are linked directly to Google services and not necessarily to mobile devices, let alone those maintained by third parties such as Samsung, Motorola, Huawei, Xiaomi, etc.

Another important consideration related to the above is the rate of use of Android models versus the rate of use of IPhone models. . In the Mexican context, recent information indicates that this rate stands at 77% for Android and 23% for IPhone, while in the South American region it is 85% for Androids and 14% for iPhones, both percentages were as of August 2023.

It is clear that Android is the mobile operating system most used in the region and that since there is not the same ease or standardization for forensic analysis as in the case of the iPhone, we may be lacking a broader view of the use of spyware against Android users.

To address this problem in Android, there are two tools that can be used for the forensic process, the aforementioned MVT and androidqf, both developed by the Amnesty Tech team.

In general terms, androidqf allows standardized extraction of information from Android devices, such as system logs, information related to installed applications or system configurations. In the case of MVT, the tool allows you to directly analyse a device, or the information extracted through androidqf.

While these tools allow information and Android devices to be standardized, extracted and analysed, they require a basic technical knowledge of computers and mobile phones and, in the case of MVT, of terminals and command lines. In addition, this approch requires that there is computer equipment available to the person who is going to perform the extraction or analysis. And in some cases where support is provided remotely, a stable and robust internet connection is also required for the communication and transfer of the extracted information for analysis.

In some cases this can be complicated, for example, when the person requiring support is physically located elsewhere and requires remote support. In such situations, the person may not have the computer equipment needed to perform the extraction using androidqf, or a stable connection to send the information over the internet, or they may not have the skills needed to operate computer equipment to perform the entire process even with remote or video call support when their support is required.


Considering everything mentioned so far, the idea emerged to try developing a tool that does the same thing as androidqf or MVT for information extraction but without the dependence on computer equipment and that enables easier information sharing.

This test was called apkqf or “APK Quick Forensics”, in honour of androidqf.

The aim was to develop an application for Android devices that can extract the same information as androidqf and in the same format so that it can be analysed using MVT as if it were an extraction performed with androidqf. This would avoid the need to use a computer as everything would be done from the person’s mobile device.

Another proposal is that the extracted information be packaged in a compressed file and that this can be shared through instant messaging applications such as WhatsApp or through cloud applications such as Google Drive, in such a way that sharing the information is relatively simple.


The functions of the androidqf version on which the test was based are:

  • Obtaining a backup of SMS and MMS message
  • Obtaining device properties
  • Obtaining device configurations (system, global, secure)
  • Obtaining running processes
  • Obtaining running services
  • Obtaining logcat information
  • Obtaining device logs
  • Obtaining dumpsys information
  • Downloading a copy of the installed apps
  • Securely storing information extraction

All these functions are implemented using adb in the Go programming language.

In the case of apkqf, the objective was to use the largest number of functions through the APIs provided by Android and add the additional functions of compression and sharing through a third party, all while respecting the format of the information extracted by androidqf.

For the development, it was decided to use the Kotlin programming language given that its syntax is simpler than Java’s and that it has retro-compatibility with the Android virtual machine.

It was also decided that the minimum version of Android to be supported would be Android 4.1 Jelly Bean (API 16), which is the oldest currently available for development and would mean a greater range of devices could use apkqf.


During the development of the application, details emerged that did not allow the initial objective to be met. Thus, not all the functions were successfully carried out and those that were did not always manage to extract the same information as androidqf.

The functions that were not carried out by the Android APIs had to be performed by executing commands by applying a shell through a child process in the application, thus simulating the behaviour of an adb command.

The functions that were able to be carried out through the Android APIs were:

  • Obtaining a backup of SMS and MMS messages. All the desired information was extracted.
  • Obtaining device configurations (system, global, secure). All the desired information was extracted, albeit with slight changes in the order of the data.
  • Obtaining running processes. The information obtained only corresponded to the application itself and not to elements of the system or other applications; in addition less information was obtained than that obtained by androidqf and the same format could not be maintained.

The functions that were carried out through the adb command simulation were:

  • Obtaining device properties. The information obtained was incomplete as some properties were absent or their values could not be obtained.
  • Obtaining running processes. The information obtained only corresponded to the application itself and not to elements of the system or other applications; in addition less information was obtained than that obtained by androidqf and the same format could not be maintained.
  • Obtaining running services. The information obtained was incomplete as some services were missing or their data could not be obtained.
  • Obtaining logcat information. The information obtained only corresponded to the application itself and not to elements of the system or other applications.
  • Obtaining dumpsys information.The information obtained only corresponded to the application itself and not to elements of the system or other applications.

Functions that could not be carried out:

  • Obtaining device logs – because it was not possible to access the necessary folders or files due to lack of permissions.
  • Downloading a copy of the installed apps. It was decided not to implement this since in theory (thanks to Android documentation) information can be obtained from the applications but not copies of the files and, given that the rest of the information was not complete, it was decided not to proceed with this function.
  • Securely store extracted information. There was no intention to carry this out in the same way as androidqf.

In light of the results obtained, it was decided not to fully implement the functions of file compression and sharing through third-party applications since the results of information extraction were not wholly positive. Although these functions can be implemented, it was decided not to do so since the extraction was not as successful as we had hoped.


The results obtained were due to the following factors:

  1. The Android security model for running apps. All applications are run in their own container so they can only access their resources (or shared resources through the same development signature) and not the resources of the system or other applications.
  • The evolution of permissions in the various versions of Android. Some of the permissions that are useful for extracting information from the system or other applications are obsolete from Android 6 onwards. Likewise, these permissions if they are available in later versions, are considered dangerous and can only be granted to system applications, applications registered by the manufacturer or device management applications.
  • The Android security model for access to permissions. Since Android 6, the management of permissions has changed, so it is necessary to carry out different checks and requests for permissions while apps are running which, combined with the previous point, does not ensure that all permissions are available or accessible.

The latter was expected, however, now we can better measure the level of access to device information from a native application on Android.

A possible solution to all of the above would be to root the device and give superuser permissions to the application, which is not recommended and is bad security practice.

Since version 11 of the Android it has been possible to run adb over WiFi, so a possible option is to try a connection through sockets locally that allow a connection to adb over WiFi to be simulated. This could work for recent devices and while it excludes a lot of devices, it can be considered a breakthrough in the field.

Another alternative would be to try to develop the application as a device management application with other types of permissions and access.

Final conclusions

For now, we have confirmed that the best way to extract the information is through androidqf and adb.

Some recommendations for androidqf that would be useful (as a result of the reflections of this test):

  • Implement an option to package data in a compressed file
  • Implement an option to share information through a third-party service and generate a link to the shared file
  • Generate more accessible documentation on downloading and using the tool, perhaps through video tutorials or guided videos for non-technical users

The alternatives and options presented in the previous section are intended for implementation and testing at a future date, seeking to obtain a more accessible way to extract data, mainly for people who do not have computer equipment or an adequate internet connection.

Despite the results of this test, I believe that it was successful as they allow us to have a clear idea of what is possible and potential alternatives.

Finally, I believe we need to continue developing tools and alternatives in the field of digital forensics in the defence of human rights in view of the lack of control over the use of spyware and the contexts of inequality and vulnerability of some groups or regions and their characteristics and needs (such as the massive use of Android devices, the lack of computer equipment and the complexities of internet connection).

Contact: [email protected] or Twitter at @_penserbjorne