DEV Community: Mustafa Salih Berk

Is the Android Lock Screen an Illusion? A Critical Logical Bypass Discovered in the Gemini App

Mustafa Salih Berk — Wed, 01 Jul 2026 10:17:03 +0000

NOTE: As of the publication of this article, the vulnerability has been fully patched, and all coordination regarding disclosure was managed directly with the Google VRP team.

Introduction: “Security Architecture vs. The Real World”

How can Android’s foundational security layer, the Keyguard, falter when confronted with the complexity of a modern AI interface? The answer is simple: as systems grow more complex, the impact of overlooked edge cases amplifies.

In this write-up, I will dissect how a simple multi-touch interaction triggered a critical logical security flaw. I’ll provide the technical details of how this vulnerability bypassed the lock screen — the very boundary designed to be the most secure — and exposed sensitive user data.

How I Discovered It

Fig 1: Demonstration of the Multi-touch Bypass

I didn’t uncover this vulnerability using automated scanning utilities or complex fuzzing frameworks; rather, it surfaced organically during my daily user experience. I noticed that multi-finger interactions within the user interface triggered benign functions that should have been restricted under specific device states. While an average user might dismiss this behavior as a transient UI glitch, to a security researcher, it signaled a potential flaw.

Further analysis revealed that invoking specific operational modes, such as Lyria or Deep Research, forced the application into a full-screen state. Initially, interaction was restricted, and the system prompted for credentials. However, applying the multi-touch technique I discovered earlier circumvented these constraints, granting unauthorized access to application settings and chat histories. By expanding the attack surface during my research, I confirmed that critical assets like NotebookLM notebooks and Gmail drafts were equally vulnerable, subsequently documenting and escalating these findings to Google.

Technical Analysis

Diagram: End-to-end exploit sequence from lock screen overlay invocation to full app context escape via UI race condition.

Gemini’s modular features bypassed the system Keyguard due to an architectural misconfiguration. The application improperly exposed UI elements that should remain strictly inaccessible while the device is locked. Although the system repeatedly invoked the Keyguard to request authentication during these operations, I successfully bypassed the lock state by leveraging a form of Context Hijacking.

The root cause lies in inadequate validation of concurrent UI interactions. By maintaining an active press on a permitted interaction area (such as a text input field) while simultaneously tapping a restricted target element, the application failed to isolate the input contexts. This race-like UI interaction completely neutralized the application’s internal security control mechanisms, turning a seemingly minor interface bug into a robust logical bypass.

Impact & Exploitation Surface

During the initial phase of my research, the exploit vectors were limited to reading, deleting, or renaming historical chats, accessing Gemini’s core settings, and viewing profile data. However, digging deeper into the application’s ecosystem revealed a significantly more severe impact:

Arbitrary Creation of Gmail and Google Docs Drafts: Allowing unauthenticated data injection into core Google services.
Unauthorized Access to NotebookLM: Exposing proprietary or highly sensitive personal and enterprise data stored within notebooks.
Gem Execution: Triggering custom AI agents without owner authentication.
Destructive Actions: Permanently deleting critical NotebookLM assets.

The practical implications of this vulnerability present severe risks, including data exfiltration, advanced social engineering scenarios via unauthorized draft creation, and the compromise of enterprise-grade environments.

Coordination and Disclosure Timeline

Throughout the lifecycle of this vulnerability, I maintained an active and transparent line of communication with Google’s security team. Shortly after submission, my report was designated as a “Duplicate,” tied to an older legacy issue inherent to Android’s core component architecture. Despite my requests for verification regarding the unique interaction vector, the root cause was maintained as identical.

Nevertheless, I continued my research. Following a subsequent major Gemini update, I verified that the exploit remained active. Upon presenting this evidence, an immediate mitigation was deployed, removing the specific mode buttons from the locked interface. Roughly a month later, a comprehensive patch was pushed, completely resolving the underlying logic flaw. My subsequent regression testing confirmed that unauthorized multi-touch access had been completely mitigated, successfully concluding the lifecycle of the report.

Key Takeaways and Conclusion

This journey marked my very first experience within the bug bounty ecosystem. Uncovering this logical vulnerability taught me that security research extends far beyond hunting for code flaws; it is about navigating the disclosure process and understanding how even a “duplicate” report can be leveraged to harden a system’s overall security posture. It perfectly illustrated how seemingly decoupled, non-critical components can be chained together to form a high-severity exploit.

Analyzing Android’s security architecture and engaging with engineering teams on regression analysis during my first research attempt fundamentally shifted my perspective on information security. While this specific report did not yield a financial bounty, the true payout was invaluable: a deep dive into the inner workings of complex enterprise software and the discipline required to execute a responsible disclosure process.

This experience is merely the opening chapter of my career in security research. It stands as a reminder that no architecture is infallible, but through the vigilance of independent researchers, they can be made resilient. Security is never a static defense; it is a continuous cycle of curiosity, analysis, and refinement.

NOTE: All PoC media provided in this article have been redacted to ensure user privacy and are presented solely for educational and security analysis purposes.

📌 References & Community

If you want to check out my other security research, tools, or open-source projects, feel free to explore the links below:

GitHub: github.com/msalihberk
Previous Research: ShadowLab: A Modular C2 Framework Architecture Built with Python for Modern Cybersecurity Research
Follow for More: Feel free to follow my Medium profile to get notified about my future security research, development projects, and technical write-ups.

ShadowLab: A Modular C2 Framework Architecture Built with Python for Modern Cybersecurity Research

Mustafa Salih Berk — Fri, 29 May 2026 20:34:38 +0000

Introduction: The Engineering Paradigm of “Building” in Cybersecurity Research

The discipline of cybersecurity diverges radically from traditional software engineering workflows. Merely operating a system or analyzing its vulnerabilities is often insufficient to fully comprehend its underlying operational mechanics. True expertise stems from grasping the core architecture at the heart of offensive and defensive strategies — by building that system entirely from scratch.

Driven by this engineering paradigm, I developed the ShadowLab framework to decode the detection mechanisms of modern EDR (Endpoint Detection and Response) and antivirus systems, delve into the intricacies of network protocols, and bridge the gap between theory and practice in secure communication channels. ShadowLab is far more than a conventional Remote Access Trojan (RAT); it is an advanced research platform that integrates asynchronous network traffic, end-to-end encryption, and modular payload architectures.

Throughout this technical paper, I will detail the architectural design choices, the engineering bottlenecks encountered while establishing a Python-based Command & Control (C2) infrastructure, and how I centered the principles of “ethical engineering” at the core of cybersecurity research. ShadowLab is a product of the conviction that offensive simulations yield meaningful insights only when executed through a transparent, modular, and ethically grounded framework.

⚠️ DISCLAIMER: This project is designed exclusively for educational and research purposes. Unauthorized operations on remote systems are strictly prohibited, and all legal liability resides entirely with the user.

Architectural Foundations

Modular Design & Clean Architecture

When designing the ShadowLab framework, I implemented a modular architecture anchored in Clean Architecture principles. This structural approach drastically enhances system maintainability while optimizing debugging, minimizing technical debt, and streamlining the integration of new functional modules. Decoupling the codebase into subclasses facilitates the dynamic injection of new capabilities into the runtime environment.

Directory Structure:

ShadowLab/
├── Shadow.py                 # Main C2 Server Application
├── requirements.txt          # Python Package Dependencies
├── LICENSE                   # Project License File
├── SECURITY.md               # Security Policy
├── FAQS.md                   # Frequently Asked Questions
├── CONTRIBUTING.md           # Contribution Guidelines
├── README.md                 # Project Documentation
├── assets/                   # Media & Resources
├── confs/                    # Configuration Files
│   └── conf.json             # Encryption Keys & Server Settings
├── mainclass/                # Core Server Modules
│   ├── builder.py            # Agent/Payload Builder
│   ├── comm.py               # Network Communication Handler
│   ├── encrypter.py          # Encryption & Decryption Utilities
│   ├── pyi_progress.py       # PyInstaller Integration & Progress Display
│   ├── options.py            # Command-Line Options & Menus
│   ├── shell.py              # Remote Command Handlers
│   └── system.py             # System Utilities & Display
├── payloads/                 # Agent/Implant Code
│   ├── payload.py            # Unstaged Payload (Full-Featured)
│   └── payload_staged.py     # Staged Payload (Lightweight)
├── postexploits/             # Post-Exploitation Modules (Future)
│   └── keystroke.py          # (In Development — Pending Security Review)
├── photos/                   # Screenshot & Image Storage Directory
├── records/                  # Audio Recording Storage Directory
└── build/                    # PyInstaller Build Output Directory

System Architecture Overview

The ShadowLab framework is built upon a modular, decoupled architecture designed for high maintainability and extensibility. The core interaction flow is centered around a robust client-server communication model, where the C2 server acts as the central intelligence hub for payload management and post-exploitation tasks.

C2 Framework (The Controller): The central hub responsible for command dispatching, cryptographic key management, and session monitoring. It utilizes mainclass/ modules to manage the lifecycle of each agent.
Agent (The Implant): Designed for lightweight execution on target systems, supporting both Staged and Unstaged execution modes.

Network Communication & Cryptographic Protocols

The network layer represents the most critical component of a Command & Control (C2) architecture. To guarantee data integrity and confidentiality, ShadowLab enforces end-to-end encryption on all packets transmitted over the wire using the Fernet (AES-128) module from the Python cryptography library.

Furthermore, to mitigate TCP streaming anomalies such as packet fragmentation and buffering issues, a strict length-prefixed communication protocol was integrated into the core network handler. Empowered by dynamic key management, the cryptographic layer can be rotated periodically via the terminal interface. The server enforces a rigid authentication layer, refusing to initiate the command loop until incoming connections clear the handshake validation.

Technical Note on Network Security: The communication channel established in this flow operates under a hardened security layer. All data transmitted through this tunnel — including command instructions and agent responses — is fully encrypted. This ensures that even if network traffic is intercepted, the underlying communication remains confidential and structurally protected against tampering.

Payload Architecture & Exploitation Methodology

Payload Deployment Modes

The current release supports two distinct deployment methodologies, allowing researchers to evaluate defensive posturing against varying injection vectors:

Staged Payload: Deployed as a lightweight bootstrap/downloader instead of executing the full implant immediately. This minimizes the initial disk footprint and significantly lowers the probability of tripping static and heuristic AV/EDR detection mechanisms.
Unstaged Payload: A monolithic, self-contained binary that encompasses all functional modules upon initial execution. Because it bypasses the need for secondary network fetches, it minimizes network anomalies, reducing the likelihood of triggering Network Intrusion Detection Systems (IDS/IPS).

Security & Ethical Engineering

Ethical Boundaries

This framework was developed entirely to apply my cybersecurity knowledge, analyze the underlying operational logic of modern threat actors, and provide a transparent sandbox environment for defensive engineers. The project is open-source and distributed under the MIT License. Utilizing this framework for unauthorized, malicious, or illegal activities falls strictly under the legal liability of the end-user.

Responsible Disclosure Policy

Adhering to strict cybersecurity ethics is a foundational pillar of the ShadowLab project. To ensure a standardized pipeline for reporting potential design flaws or edge-case vulnerabilities within the framework itself, I have established a structured Coordinate Vulnerability Disclosure process via the SECURITY.md. policy.

Engineering Insights & Technical Retrospective

The primary engineering bottleneck encountered during development revolved around handling asynchronous network I/O, maintaining state consistency across raw sockets, and establishing reliable concurrent debugging pipelines. Decoupling the framework into classes not only alleviated code complexity but also optimized scalability and maintainability across the entire architecture.

This project provided invaluable pratical expertise, extending beyond the mechanics of offensive vectors (such as persistence mechanisms and evasion tactics) into the fundamental principles of “defensible software design.” Documenting and analyzing malicious behavioral patterns has equipped me with a profound theoretical and practical understanding of adversary simulation. Leveraging this architectural experience, I plan to pivot towards developing an entirely defensive, behavioral-analysis-focused solution in the near future.

Future Vision & Roadmap

ShadowLab is engineered as an evolving research ecosystem. The short-term development roadmap encompasses:

Integration of advanced post-exploitation modules.
Native, low-footprint payload alternatives compiled in C/C++ and Go for cross-platform evasion research.
A real-time, event-driven graphical telemetry monitor to map active implant operations.
Behavioral Analysis Sandbox: Incorporating an integrated heuristic antivirus module directly into the framework to transform ShadowLab into a comprehensive, closed-loop simulation laboratory.

To foster collaborative growth, I encourage the open-source community to contribute to the project by adhering to the architectural guidelines outlined in CONTRIBUTING.md.

Conclusion

Ultimately, executing a pre-compiled exploit simply concludes a script. However, engineering a framework from the ground up — architecting its cryptographic routines, managing low-level socket streams, and structuring its fault-tolerant boundaries — allows a researcher to understand the invisible fortifications of the digital landscape. True cybersecurity is not the art of destroying systems, but the science of deconstructing them to comprehend their design.

Official Repository & Documentation: The complete source code, security matrices, and technical deployment guides for this framework are transparently hosted on GitHub. To track active developments, audit the codebase, or contribute to the ecosystem, visit the official repository: ShadowLab GitHub Repository

⚡ ShadowLab is an ongoing research project. If you want to support my work and help me develop new post-exploitation modules, please consider leaving a ⭐ on GitHub!

ShadowLab: Building a Python C2 Prototype for Security Labs (V1.3)

Mustafa Salih Berk — Fri, 29 May 2026 18:28:16 +0000

I built ShadowLab: A modular, Python-based C2 framework designed for security research and offensive simulation.

Traditional cybersecurity study often stops at analyzing existing tools; I believe true expertise comes from building the architecture from scratch to understand the underlying mechanics of EDR evasion and network protocols. This is a technical retrospective on the engineering choices behind ShadowLab.

🏗️ Architectural Foundations: The "Clean" Approach

ShadowLab follows Clean Architecture principles, decoupling the server's core logic to ensure maintainability and scalability. Instead of a monolithic script, the framework is structured into specialized modules:

Controller (C2 Server): The central hub responsible for command dispatching, cryptographic key management, and session monitoring.
Agent (Implant): A lightweight binary designed for minimal footprint, supporting both Staged (bootstrap downloader) and Unstaged (monolithic) execution modes. ### 🏛️ Project Structure

ShadowLab/
├── Shadow.py                 # Main C2 Server Application
├── requirements.txt          # Python Package Dependencies
├── LICENSE                   # Project License File
├── SECURITY.md               # Security Policy
├── FAQS.md                   # Frequently Asked Questions
├── CONTRIBUTING.md           # Contribution Guidelines
├── README.md                 # Project Documentation
├── assets/                   # Media & Resources
├── confs/                    # Configuration Files
│   └── conf.json             # Encryption Keys & Server Settings
├── mainclass/                # Core Server Modules
│   ├── builder.py            # Agent/Payload Builder
│   ├── comm.py               # Network Communication Handler
│   ├── encrypter.py          # Encryption & Decryption Utilities
│   ├── pyi_progress.py       # PyInstaller Integration & Progress Display
│   ├── options.py            # Command-Line Options & Menus
│   ├── shell.py              # Remote Command Handlers
│   └── system.py             # System Utilities & Display
├── payloads/                 # Agent/Implant Code
│   ├── payload.py            # Unstaged Payload (Full-Featured)
│   └── payload_staged.py     # Staged Payload (Lightweight)
├── postexploits/             # Post-Exploitation Modules (Future)
│   └── keystroke.py          # (In Development — Pending Security Review)
├── photos/                   # Screenshot & Image Storage Directory
├── records/                  # Audio Recording Storage Directory
└── build/                    # PyInstaller Build Output Directory

🛡️ Hardened Communication & Network Layer

The network layer is the most critical component. To ensure confidentiality and stability, I implemented:

End-to-End Encryption: All packets are secured using Fernet (AES-128) with dynamic key management.
Length-Prefixed Protocols: To mitigate TCP streaming anomalies like packet fragmentation, I integrated a 4-byte length-prefixed protocol.
Non-Blocking I/O: Using Python's native networking structures, the communication handler manages concurrent socket operations effectively.

📊 Deployment Modes Comparison

Mode	Use Case	Detection Risk
Staged	Bootstrap/Downloader	Low (Smaller footprint)
Unstaged	Self-contained binary	Moderate (Monolithic)

🔗 Code & Full Deep Dive

GitHub Repository: ShadowLab Source Code
Full Technical Paper: Read the deep dive on Medium

Check out the repository, and I would highly appreciate any backend architecture reviews or code quality feedback from the infosec community here!