Pith. sign in

REVIEW 2 major objections 1 minor 45 references

A Longitudinal Study of Android Apps Signing Key Protection

T0 review · 2 major / 1 minor · reviewed 2026-06-26 · grok-4.3

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Signing keys for Android apps used by more than 10 billion people have been exposed on GitHub.

desk verdict The paper quantifies leaked Android signing keys at scale and links some to real apps reaching billions of users. read the letter →

arxiv 2606.21487 v1 pith:CQFHDHBU submitted 2026-06-19 cs.CR cs.SE

Mark Huasong Meng , Qing Zhang , Weirao Lu , Chunyang Chen This is my paper · ORCID
classification cs.CRcs.SE
keywords AndroidsigningkeyskeystoreleakageGitHubappsecuritysupplychaincertificate
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper mines public GitHub repositories to find exposed Android signing credentials and recovers 5,673 compromised keystores. It matches 26 unique certificates to 278 real-world apps, including 252 preinstalled by seven manufacturers. This demonstrates that key mismanagement creates a systemic risk in the Android ecosystem, with practical implications for app integrity and user security.

What carries the argument

Mining public repositories for exposed Android signing credentials and matching them to app signatures.

What would settle it

A check showing that none of the 26 certificates match signatures of any apps in the wild or that the exposed passwords do not grant access to production signing keys.

Watch

Extended reading notes

Core claim

By searching GitHub for Android signing keystores and matching recovered certificates against over 4,000 apps from stores and OEM images, the study identifies 5,673 compromised keystores and 26 certificates linked to 278 apps affecting over 10 billion users. A proof-of-concept shows these leaks enable app replacement attacks, extending to automotive platforms.

Load-bearing premise

The keystores found on GitHub and the certificate matches accurately represent keys used to sign actual production apps rather than test or duplicate keys.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

2 major / 1 minor

Summary. The paper conducts a longitudinal empirical study of Android app signing key protection by mining public GitHub repositories for exposed signing credentials, recovering 5,673 compromised keystores via exposed passwords, and matching the resulting 26 unique certificates against signatures from a corpus of over 4,000 apps drawn from public stores and OEM images. It reports that 26 certificates correspond to 278 real-world apps (26 third-party store apps and 252 preinstalled apps from seven manufacturers), collectively impacting over 10 billion users, demonstrates a proof-of-concept app replacement attack, and notes spillover risks to automotive platforms.

Significance. If the credential recovery and certificate-to-app matching pipeline is shown to be accurate and free of substantial false positives, the work provides concrete evidence of systemic mismanagement of production signing keys, quantifying the scale of exposure and its potential for supply-chain compromise in the Android ecosystem.

major comments (2)
  1. [Abstract and §3] Abstract and §3 (Data Collection and Matching): The reported counts (5,673 keystores, 26 certificates, 278 apps) are presented without any description of the GitHub search queries employed, the false-positive filtering steps applied to recovered keystores, the precision of certificate matching against the 4,000-app corpus, or any error bars or sensitivity analysis; these omissions make the central empirical claims impossible to evaluate for accuracy or representativeness.
  2. [§4 and §5] §4 (Results) and §5 (Impact Analysis): The claim that the identified keys affect 'over 10 billion users' and include production apps (as opposed to test keys or duplicates) rests on the unverified assumption that the recovered certificates were actually used to sign the matched apps in the wild; no validation against app-store metadata, version history, or developer confirmation is described to support this.
minor comments (1)
  1. [Abstract and §4] The abstract and results sections would benefit from a clear table summarizing the breakdown of the 278 apps by store vs. preinstalled and by manufacturer.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for their thorough review and constructive feedback. We address each major comment below, indicating where we will revise the manuscript to improve clarity and transparency.

read point-by-point responses

  1. Referee: [Abstract and §3] Abstract and §3 (Data Collection and Matching): The reported counts (5,673 keystores, 26 certificates, 278 apps) are presented without any description of the GitHub search queries employed, the false-positive filtering steps applied to recovered keystores, the precision of certificate matching against the 4,000-app corpus, or any error bars or sensitivity analysis; these omissions make the central empirical claims impossible to evaluate for accuracy or representativeness.

    Authors: We agree that §3 requires substantially more detail on the methodology to support evaluation of the reported counts. In the revised manuscript we will expand this section to describe the GitHub search queries and parameters, the multi-stage false-positive filtering process (including format validation, password verification, and exclusion criteria for non-production keys), the certificate matching procedure (SHA-256 fingerprint equality), and any sensitivity analysis performed on search parameters. These additions will include explicit discussion of matching precision. revision: yes

  2. Referee: [§4 and §5] §4 (Results) and §5 (Impact Analysis): The claim that the identified keys affect 'over 10 billion users' and include production apps (as opposed to test keys or duplicates) rests on the unverified assumption that the recovered certificates were actually used to sign the matched apps in the wild; no validation against app-store metadata, version history, or developer confirmation is described to support this.

    Authors: The 278 apps were identified by exact certificate matching against a corpus drawn from public app stores and OEM system images, which are real deployed applications; certificate equality is the standard and definitive indicator that the leaked key was the production signing key. The >10 billion user figure aggregates publicly reported install counts and OEM fleet estimates. We did not perform developer confirmation or version-history cross-checks, as these are not publicly feasible at scale. We will revise §4 and §5 to state the matching basis more explicitly and note this limitation. revision: partial

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: pure empirical measurement study

full rationale

The paper performs data collection and matching: mining GitHub for exposed Android signing credentials, recovering keystores via passwords, and matching certificates against a corpus of 4,000+ apps from stores and OEM images. No derivations, equations, fitted parameters, predictions, or self-citations appear in the provided abstract or description. All claims are direct outputs of the measurement pipeline with no reduction to inputs by construction. This matches the default expectation for non-circular empirical work.

Assumptions & free parameters 0 free parameters · 2 assumptions · 0 invented entities

The central claim rests on the assumption that public GitHub searches capture a representative sample of real signing-key leaks and that certificate matching to app signatures has negligible false positives.

assumptions (2)
  • domain assumption GitHub search for signing credentials is comprehensive and the recovered items are production keys rather than test or example material.
    The study uses this to characterize the threat; stated in the abstract description of mining and recovery steps.
  • domain assumption Signature matching between recovered certificates and apps from stores/OEM images is accurate and complete.
    Required to link the 26 certificates to the 278 apps and the 10-billion-user impact figure.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Longitudinal Study of Android Apps Signing Key Protection." pith.science (2026). https://pith.science/paper/CQFHDHBU

@misc{pith2026260621487,
  author       = {Pith},
  title        = {Pith review of: A Longitudinal Study of Android Apps Signing Key Protection},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CQFHDHBU}},
  note         = {Machine review of arXiv:2606.21487}
}
read the original abstract

Android app signing relies on developer-managed credentials, making secure key protection essential for the integrity of the software supply chain. A recent platform key leakage incident involving two major OEM manufacturers demonstrates that even robustly designed signing mechanisms can be compromised due to developers' oversight. In this work, we conduct a longitudinal ecosystem study to characterize this threat by mining public repositories for Android signing credentials, recovering compromised keys via exposed passwords, and matching them against signatures from over 4,000 apps collected from major stores and OEM system images. Our analysis identifies 5,673 compromised keystores on GitHub and 26 unique certificates linked to 278 real-world apps. These include 26 third-party apps in public app stores and 252 preinstalled apps from seven manufacturers, collectively affecting over 10 billion users. We demonstrate the practical exploitability of these leaks through a proof-of-concept app replacement attack and identify spillover risks in non-smartphone platforms, including a popular automotive head-unit platform installed in over 1,100 vehicle models. Our results reveal that signing-key mismanagement is a systemic risk, underscoring the need for a more rigorous key-management support in Android release engineering and distribution infrastructures.

Figures

Figures reproduced from arXiv: 2606.21487 by the authors.

Figure 1
Figure 1. The role of app signing in the life cycle of an An [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Overview of our methodology, including repository-side compromise identification, ecosystem-side signature matching, [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Word cloud pictures showing the distributions of [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: The process of (a) creating permission conflict and (b) injecting malicious DEX. [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: An illustrated attack to hijack the automotive head [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

45 extracted references · 3 canonical work pages

  1. [1]

    Bissyandé, Jacques Klein, and Yves Le Traon

    Kevin Allix, Tegawendé F. Bissyandé, Jacques Klein, and Yves Le Traon. 2016. AndroZoo: Collecting Millions of Android Apps for the Research Community. In Proceedings of the 13th International Conference on Mining Software Repositories (Austin, Texas)(MSR ’16). ACM, New York, NY, USA, 468–471. doi:10.1145/ 2901739.2903508

    work page arXiv 2016

  2. [2]

    AppBrain. 2024. AppBrain Statistics - Top manufacturers. https://www.appbrain. com/stats/top-manufacturers (accessed 20 March 2026)

    2024

  3. [3]

    Baidu. 2025. Baidu CarLife+. https://carlife.baidu.com/carlife/morecars (in Chinese, accessed 5 March 2026)

    2025

  4. [4]

    David Barrera, H Güneş Kayacik, Paul C Van Oorschot, and Anil Somayaji. 2010. A methodology for empirical analysis of permission-based security models and its application to android. InProceedings of the 17th ACM conference on Computer and communications security. 73–84

    2010

  5. [5]

    Kerry Bisset. 2023. Exploring the Frontier of Android Plugin Architecture: For the Curious and the Innovative. https://medium.com/%40kerry.bisset/exploring-the- frontier-of-android-plugin-architecture-for-the-curious-and-the-innovative- 3cb903a4decd (accessed 11 March 2026)

    2023

  6. [6]

    Manuel Egele, David Brumley, Yanick Fratantonio, and Christopher Kruegel

  7. [7]

    In Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security

    An empirical study of cryptographic misuse in android applications. In Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security. 73–84

    2013

  8. [8]

    Adrienne Porter Felt, Erika Chin, Steve Hanna, Dawn Song, and David Wagner

Show all 45 references
  1. [9]

    InProceedings of the 18th ACM conference on Computer and communications security

    Android permissions demystified. InProceedings of the 18th ACM conference on Computer and communications security. 627–638

  2. [10]

    Runhan Feng, Ziyang Yan, Shiyan Peng, and Yuanyuan Zhang. 2022. Automated detection of password leakage from public github repositories. InProceedings of the 44th International Conference on Software Engineering (ICSE). 175–186

    2022

  3. [11]

    Google. 2023. Privacy changes in Android 10. https://developer.android.com/ about/versions/10/privacy/changes (accessed 9 March 2026)

    2023

  4. [12]

    Google. 2023. Privacy in Android 11. https://developer.android.com/about/ versions/11/privacy (accessed 9 March 2026)

    2023

  5. [13]

    Google. 2023. Sign your app. https://developer.android.com/studio/publish/app- signing (accessed 3 March 2026)

    2023

  6. [14]

    Google. 2024. Application Signing. https://source.android.com/docs/security/ features/apksigning (accessed 3 March 2026)

    2024

  7. [15]

    Google. 2024. System Security Best Practices. https://source.android.com/docs/ security/best-practices/system (accessed 3 March 2026)

    2024

  8. [16]

    Google. 2025. Configure your build. https://developer.android.com/build#top- level (accessed 3 March 2026)

    2025

  9. [17]

    Google. 2025. InMemoryDexClassLoader. https://developer.android.com/ reference/kotlin/dalvik/system/InMemoryDexClassLoader (accessed 11 March 2026)

    2025

  10. [18]

    Google. 2025. <permission>. https://developer.android.com/guide/topics/ manifest/permission-element (accessed 3 March 2026)

    2025

  11. [19]

    Google. 2025. Permissions on Android. https://developer.android.com/guide/ topics/permissions/overview (accessed 3 March 2026)

    2025

  12. [20]

    Google. 2025. Privileged permission allowlist. https://source.android.com/docs/ core/permissions/perms-allowlist (accessed 13 Febuary 2026)

    2025

  13. [21]

    Google. 2025. Sign builds for release. https://source.android.com/docs/core/ota/ sign_builds (accessed 3 March 2026)

    2025

  14. [22]

    Google. 2026. Google Play Protect. https://developers.google.com/android/play- protect (accessed 11 March 2026)

    2026

  15. [23]

    Google Groups. 2025. What’s the difference of /system/app/ and /system/priv- app in Kitkat? https://groups.google.com/g/android-platform/c/Vsa4IsJcOPE (accessed 3 March 2026)

    2025

  16. [24]

    Umar Hussain. 2018. Storing Android Signing Config Credentials: Secure and Platform Independent. https://medium.com/%40umar.hussain/storing-android- signing-config-credentials-secure-and-platform-independent-c593464f927c (ac- cessed 11 March 2026)

    2018

  17. [25]

    IBM. 2024. What is Log4Shell? https://www.ibm.com/think/topics/log4shell (accessed 11 March 2026)

    2024

  18. [26]

    Rahul Kumar. 2023. An Introduction to Smali. https://payatu.com/blog/an- introduction-to-smali/ (accessed 5 March 2026)

    2023

  19. [27]

    Charlie Lambropoulos. 2022. GitHub, GitLab, Bitbucket. Which code repository do you use? https://www.scrumlaunch.com/blog/GitHub-GitLab-Bitbucket (accessed 11 March 2026)

    2022

  20. [28]

    Michael Meli, Matthew R McNiece, and Bradley Reaves. 2019. How bad can it git? characterizing secret leakage in public github repositories.. InProceedings of the Network and Distributed Systems Security (NDSS) Symposium

    2019

  21. [29]

    Lily Hay Newman. 2022. Android Phone Makers’ Encryption Keys Stolen and Used in Malware. https://www.wired.com/story/android-platform-certificates- malware/?utm_source=chatgpt.com (accessed 11 March 2026)

    2022

  22. [30]

    NIST. 2013. CVE-2013-4787. https://nvd.nist.gov/vuln/detail/CVE-2013-4787 (accessed 11 March 2026)

    2013

  23. [31]

    NIST. 2017. CVE-2017-13156. https://nvd.nist.gov/vuln/detail/cve-2017-13156 (accessed 11 March 2026)

    2017

  24. [32]

    NIST. 2021. CVE-2021-44228. https://nvd.nist.gov/vuln/detail/cve-2021-44228 (accessed 11 March 2026)

    2021

  25. [33]

    Raul Roberts. 2024. A (Partial) History of Software Supply Chain At- tacks. https://www.reversinglabs.com/blog/a-partial-history-of-software- supply-chain-attacks?utm_source=chatgpt.com (accessed 11 March 2026)

    2024

  26. [34]

    Sanatsu. 2021. Exploiting Apps vulnerable to Janus (CVE-2017–13156). https://medium.com/mobis3c/exploiting-apps-vulnerable-to-janus-cve-2017- 13156-8d52c983b4e0 (accessed 11 March 2026)

    2021

  27. [35]

    Shangcheng Shi, Xianbo Wang, Kyle Zeng, Ronghai Yang, and Wing Cheong Lau

  28. [36]

    InInternational Conference on Security and Privacy in Communication Systems

    An empirical study on mobile payment credential leaks and their exploits. InInternational Conference on Security and Privacy in Communication Systems. Springer, 79–98

  29. [37]

    Yizhe Shi, Guangliang Yang, Zhemin Yang, Yifan Yang, Min Yang, Kangwei Zhong, and Xiaohan Zhang. 2025. The Skeleton Keys: A Large Scale Analysis of Credential Leakage in Mini-apps. (2025)

    2025

  30. [38]

    Vibha Singhal Sinha, Diptikalyan Saha, Pankaj Dhoolia, Rohan Padhye, and Senthil Mani. 2015. Detecting and mitigating secret-key leaks in source code repositories. In2015 IEEE/ACM 12th Working Conference on Mining Software Repositories. IEEE, 396–400

    2015

  31. [39]

    Sreelakshmi S Dilip. 2025. Android Automotive: Understanding app permissions and privileged applications. https://medium.com/{@}sreelakshmis.dilip/android- automotive-understanding-app-permissions-and-privileged-applications- c00b83df11d6 (accessed 3 March 2026)

    2025

  32. [40]

    StackOverflow. 2010. Is it possible to inject code in an android applica- tion? https://stackoverflow.com/questions/4260231/is-it-possible-to-inject- code-in-an-android-application (accessed 11 March 2026)

    2010

  33. [41]

    priviledged

    StackOverflow. 2024. Android O (api 26): root-app not recognized as "priviledged". https://stackoverflow.com/a/52162905 (accessed 20 March 2026)

    2024

  34. [42]

    Connor Tumbleson. 2025. Apktool: A tool for reverse engineering Android apk files. https://apktool.org/ (accessed 11 March 2026)

    2025

  35. [43]

    Haoyu Wang, Hongxuan Liu, Xusheng Xiao, Guozhu Meng, and Yao Guo. 2019. Characterizing android app signing issues. In2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 280–292

    2019

  36. [44]

    Lili Wei, Heqing Huang, Shing-Chi Cheung, and Kevin Li. 2025. How far are app secrets from being stolen? a case study on android.Empirical Software Engineering30, 3 (2025), 90

    2025

  37. [45]

    Yajin Zhou and Xuxian Jiang. 2012. Dissecting android malware: Characterization and evolution. In2012 IEEE symposium on security and privacy. IEEE, 95–109. 11

    2012

Pith tools

Reviewed June 26, 2026 · model on record in the stance chip above.