Guest lecture hack a Mobile 00 15 01 28 45

Name: Guest lecture hack a Mobile 00 15 01 28 45
Uploaded: 2026-02-22T17:10:24.000Z
Duration: 4 h 28 min 59 s
Description: video1

Introduction to Digital Forensics Challenges

Overview of the Lecture

Gunnar Allall introduces himself and sets the stage for a guest lecture on digital forensics, emphasizing his expertise and willingness to clarify any unfamiliar terms.

He notes that this lecture will differ from typical digital forensics teachings, focusing more on general security rather than just vulnerability research.

Agenda and Focus Areas

The session will cover challenges in digital forensics, particularly during the acquisition phase where data is extracted from devices.

Emphasis will be placed on one specific challenge within this phase to illustrate complexities involved in data acquisition.

Deep Dive into Data Acquisition Challenges

Understanding Data Acquisition

The first phase of digital forensics involves seizing data; without successful data acquisition, forensic analysis cannot proceed.

Gunnar encourages participants to ask questions throughout the lecture to ensure clarity and understanding of technical concepts.

Key Concepts in Security Mechanisms

The discussion will include software firmware reversing and Android security, specifically focusing on Samsung devices as case studies.

User input sanitization is highlighted as a critical aspect of security; improper handling can lead to vulnerabilities.

Exploitation Techniques in Digital Forensics

Definition and Importance of Exploitation

Exploitation refers to offensive techniques used to bypass security mechanisms when acquiring data from devices like mobile phones.

In cases where victims are deceased or inaccessible, exploitation becomes essential for retrieving necessary forensic data.

Encryption Challenges in Android Devices

Most modern Android devices encrypt user data by default (mandatory from version 7 onwards), complicating access during forensic investigations.

Keys protecting encrypted data are device-specific, making it difficult to decrypt information even if physical access is gained through methods like chip-off.

Security Features and Their Implications

Device-Specific Key Binding

Keys generated for encryption are bound to individual devices, presenting significant challenges when attempting cross-device decryption.

Understanding Device Security and Forensics

The Challenge of Accessing Encrypted Data

Keys are directly tied to the phone, meaning that only the specific device can decrypt data on its flash storage. This necessitates powering on the device to access hardware keys.

Simply desoldering chips and reading data is insufficient; decryption requires specific keys, highlighting the need to break the device's security.

Keys are protected by both a user-defined passphrase (PIN/password) and hardware mechanisms, making unauthorized access complex.

Both layers of protection (hardware and passphrase) must be bypassed to retrieve keys, indicating a multi-faceted approach is necessary for accessing encrypted data.

The Importance of Digital Forensics

Digital forensics relies heavily on data acquisition; as consumer devices become more secure, obtaining this data becomes increasingly challenging.

There exists a conflict between user desires for higher security and law enforcement's need for access to digital information during investigations.

Security vulnerabilities can be exploited positively in digital forensics, contrary to their typical association with malicious activities.

Case Study: Samsung Aspid Vulnerability

As security measures increase, acquiring data from devices becomes more difficult; thus, understanding vulnerabilities is crucial for forensic purposes.

Most sensitive personal information is now stored on mobile phones rather than traditional computers, elevating their forensic value significantly.

Multi-Layered Security in Modern Devices

Modern devices employ multiple layers of security across hardware, operating systems (iOS/Android), and applications (encrypted apps), complicating forensic efforts.

IoT devices present unique challenges due to generally lower security standards compared to smartphones but often hold less valuable forensic information.

Law Enforcement vs. Technology Companies

The FBI faced challenges accessing an iOS device when Apple refused assistance in a criminal case, sparking debate over privacy versus law enforcement needs.

Reports suggest that the FBI purchased a vulnerability for $900k to access the locked device without informing Apple about it—highlighting tensions between tech companies and law enforcement agencies.

Ethical Considerations in Digital Forensics

Apple's refusal to assist law enforcement sets a precedent where agencies may feel compelled to seek out vulnerabilities independently rather than collaborating with manufacturers.

The speaker advocates exploring offensive techniques within digital forensics research while emphasizing ethical considerations regarding how these methods are applied.

Digital Forensics and Security Vulnerabilities

Entry Points for Device Access

Law enforcement often accesses devices physically rather than through remote attacks, which are more common in hacker fame.

Physical access allows law enforcement to utilize various methods for data extraction, making it less reliant on internet protocols.

Challenges with Digital Forensics Tools

Closed-source digital forensics products raise concerns about the completeness of evidence; transparency is crucial in legal contexts.

Understanding the functionality of forensic tools is essential for law enforcement to confidently present evidence in court.

Evolution of Data Acquisition Techniques

Historical methods involved simpler devices like old Nokia phones, where raw data could be accessed without encryption challenges.

Modern devices require complex techniques due to encryption and security mechanisms that vary by manufacturer and model.

Case Study: Samsung Mobile Phones

The discussion focuses on Samsung's security model, including secure boot processes and mandatory encryption features across popular models.

While Samsung's approach can be generalized to other Android vendors, hardware differences complicate forensic analysis.

Encryption Mechanisms in Android Devices

Mandatory user data encryption was introduced starting with Android 6; later versions enforce this feature universally across devices.

Encryption keys are hardware-tied, meaning they cannot be transferred between devices, complicating data recovery efforts.

Variability Among Samsung Models

Different regions may have different hardware configurations (e.g., Exynos vs. Qualcomm chips), affecting forensic approaches.

The focus will remain on the Exynos variant of Samsung devices as it presents unique challenges distinct from Qualcomm models.

Data at Rest Security Concerns

Data at rest remains secure when a device is powered off; accessing this data requires powering on the device to retrieve necessary keys.

Understanding Hardware Keys and Trust Zones in Android

Importance of Hardware Keys

The slide emphasizes the significance of hardware keys, focusing on how user input (PIN/password/pattern) is transformed through hashing into a key encryption key.

Trust Zone Functionality

A secure operating system, known as the trust zone, operates alongside the Android OS to manage encrypted user data. Each user data partition contains an unencrypted footer that provides information about the encryption key.

Key Storage and Encryption Process

The encryption process involves a double-encrypted data key stored within the device. This example pertains to Android 6, highlighting differences in later versions.

Accessing the encrypted data requires powering on the trust zone; without this step, retrieving keys is impossible.

User Data Mounting Process

When attempting to access user data, a volume daemon automatically tries to mount it by requesting decryption from the trust zone using the user's PIN or pattern.

Hardware Dependency and Security Vulnerabilities

The hardware key is unique to each phone's CPU; only that specific chip can decrypt its corresponding blob. If another CPU attempts this operation, it will fail.

Emphasizes that decryption must occur on the same hardware where encryption took place due to this hardware dependency.

Samsung's Secure Boot Mechanism

Ensuring Code Integrity

Samsung employs a secure boot process ensuring all code executed from power-on until full Android startup is signed and verified for integrity.

Tamper Detection Features

If users attempt to root their devices, Samsung flags them with a Knox flag indicating tampering. This action voids warranties and disables certain features like Samsung Pay.

One-Time Writable Fuses

Samsung uses one-time writable fuses that permanently set flags if tampering occurs; these cannot be reset once triggered.

Boot Process Overview

The secure boot model includes a boot ROM with minimal code verifying signatures of loaded firmware. Unsigned code leads to bricking devices—rendering them non-functional without recovery methods.

Understanding the Boot Process and Security Features of Android Devices

Overview of Hardware Limitations

The initial hardware component is immutable; if a bug occurs, users must receive a new device as it cannot be updated.

Firmware updates are possible for components below the hardware level, which reside on flash storage.

Boot Process Simplified

The boot process involves loading the trust zone and two bootloaders that prepare the hardware before launching the Android kernel.

This process is essential for transitioning from hardware initialization to full Android operation.

Identifying Vulnerabilities in Secure Bootchain

Analyzing user input is crucial to identify potential vulnerabilities within the bootchain.

Three primary goals are established: breaking into the device to access keys, obtaining an e-deck blob post-encryption removal, and brute-forcing passwords.

Focus on Esboot in Exynos Devices

The lecture will focus on BL2, known as Esboot in Exynos devices, which has distinct features compared to Qualcomm counterparts.

Esboot's responsibilities include signature verification and preparing the device for Android startup.

Signature Verification and Download Modes

Esboot checks if the Android kernel is signed by Samsung; failure results in a warning and prevents startup.

Two methods exist for firmware updates: over-the-air updates or entering download mode via a key combination.

Additional Responsibilities of Esboot

In download mode, users can upload firmware directly to their devices; this mode operates from the phone's perspective.

Other security features include managing E-Fuse settings related to warranty status upon tampering with devices.

Debugging Capabilities through UART Shell Access

Esboot communicates with Trust Zone and handles kernel crashes while providing debugging capabilities via UART shell access.

A command prompt exists within the bootloader that allows user input—this presents potential vulnerabilities not initially intended for user interaction.

Discovery of Vulnerabilities by Hex Detective

A blog by Hex Detective revealed terminal shell access within S-Boot, indicating possible vulnerabilities without detailing them fully.

To exploit this vulnerability, a special USB cable with specific resistance on its ID pin is required.

This structured summary provides insights into critical aspects of Android device security and boot processes while linking back to specific timestamps for further exploration.

Magic Cable and Command Prompt Overview

Introduction to the Magic Cable

The speaker introduces a "magic cable" that connects to a command prompt, hinting at its significance for upcoming demonstrations.

A brief break is suggested before demonstrating the cable's functionality, emphasizing the importance of the demonstration.

Demonstration Preparation

The speaker considers audience fatigue on a Friday evening and opts for a shorter break of five minutes instead of fifteen.

The focus shifts to analyzing terminal shells as potential attack vectors, setting up for an in-depth exploration post-break.

Understanding S-Boot and Reverse Engineering

Analyzing S-Boot

S-Boot is described as a binary blob (1.5 MB), consisting of native ARM code without any operating system layer.

The challenge lies in reverse engineering this code due to its direct access to hardware components like RAM and USB.

Tools for Reverse Engineering

IDA Pro is highlighted as an essential tool for static reverse engineering; it allows analysis of dead code without running it.

Dynamic analysis isn't possible with S-Boot since there's no debugger available; however, memory dumps can be useful for exploit development.

Live Demo: Accessing the Shell

Initial Shell Interaction

The speaker demonstrates accessing the UART shell using the magic cable, showcasing debug output from S-Boot during boot-up.

A terminal shell appears before Android boots, allowing input commands which reveal potential vulnerabilities through crashes.

Identifying Vulnerabilities

Inputting incorrect commands leads to crashes, indicating poor handling of user inputs—an opportunity for security research.

Crashing upon invalid input suggests exploitable vulnerabilities within argument handling in S-Boot.

Exploring Security Implications

Understanding Vulnerability Discovery

The discussion emphasizes that discovering vulnerabilities requires manual bug hunting and tracking user-input related functions in S-Boot.

Potential attack vectors include any user-influenced input methods such as typing or physical modifications via USB connections.

Exploit Development Process

Understanding Vulnerability to Exploit Transition

The process of exploit development begins after identifying a vulnerability, which involves executing custom code. This can be challenging but is relatively straightforward in some cases.

Finding the actual bug typically takes between one to five days, followed by an additional ten days for developing the necessary code to execute within a unique environment.

A specific vulnerability arises when memory allocation for arguments exceeds the expected limit, leading to potential crashes if more parameters are provided than allocated buffers.

Mechanics of Memory Control

The crash occurs due to writing beyond allocated memory limits, allowing control over what data is written and where it is stored in memory.

The term "vanilla write what where" describes the ideal scenario in exploit development where there are minimal limitations on writing data and specifying its location in memory.

Limitations include not being able to send zero bytes or backspace characters, as these would terminate strings or delete characters respectively.

Exploiting Memory Buffers

By sending specific sequences (like 'a', 'b', 'c', etc.) into designated buffers, control over subsequent addresses can be achieved through strategic spacing.

This method allows for writing arbitrary strings—including ARM code—to controlled addresses in memory, demonstrating how exploits can manipulate execution flow.

Potential Outcomes of Exploitation

One immediate goal could be patching signature checks within Sboot that verify kernel signatures, potentially allowing unsigned kernels to run on devices.

Exploits executed only in RAM do not persist after rebooting the device; this approach minimizes risks associated with permanent changes and is beneficial for forensic purposes.

Practical Application and Demonstration

Since modifications occur solely in RAM during exploitation, they disappear upon shutdown—this characteristic makes it safer from a forensic standpoint.

To effectively demonstrate exploit execution, automated frameworks are preferred over manual input methods; this enhances efficiency and accuracy during demonstrations.

A live demo will illustrate the practical application of these concepts using a different phone setup for visibility.

Exploit Demonstration and Control Over S-Boot

Initial Setup and Execution

The speaker demonstrates the process of exploiting a device by connecting a phone to a host machine, showcasing real-time interactions on both screens.

Emphasizes that the details are less important than understanding the demonstration's purpose, which is to illustrate control over the device.

Successful Exploitation of S-Boot

The speaker confirms successful communication with S-Boot, indicating that custom code execution has replaced standard operations.

Highlights that full control over the device has been achieved; all security features in S-Boot are compromised, allowing for extensive modifications.

Implications of Gaining Control

Discusses the significance of controlling S-Boot: it allows for replacing critical components like the Android kernel and bypassing trusted boot processes.

Mentions potential actions such as patching an unsigned kernel and enabling ADB (Android Debug Bridge), leading to root access on the device.

Limitations and Next Steps

Notes that while S-Boot is exploited, TrustZone remains unexploited, meaning certain security layers still exist.

Outlines future steps needed to remove encryption layers from TrustZone to retrieve sensitive user data like PIN codes or passwords.

Brute Force Methodology

Explains how password validation works within the system; if a guessed password decrypts correctly, it indicates success.

Describes how brute-forcing can be executed by mimicking Android's existing methods for key validation against encrypted blobs.

Exploring Further Attack Vectors

Expresses interest in researching additional exploits possible through control over S-Boot, including potential interactions with TrustZone.

Suggests various attack scenarios such as bypassing Replay Protected Memory Blocks or manipulating Knox security features in Samsung devices.

Understanding Vulnerabilities and Trust Zones in Digital Forensics

Exploring User Data and Device Vulnerabilities

The discussion begins with the importance of user data, suggesting that there may be alternative methods to exploit vulnerabilities in devices. The speaker emphasizes that this is a preliminary overview, hinting at more complex details to come.

A dilemma arises regarding zero-day vulnerabilities: whether to disclose them to manufacturers like Samsung for fixes or keep them private for potential profit. The speaker notes the ethical considerations involved in handling such vulnerabilities.

Emphasizing the need for training, the speaker discusses how individuals can identify their own vulnerabilities or analyze patches (patch-diffing) to discover what has been fixed, which could indicate exploitable weaknesses in older devices.

Offensive Techniques and Security Research

The scenario of seizing a device by law enforcement is presented, highlighting how old devices can remain vulnerable long after they are taken out of circulation due to lack of firmware updates.

The speaker clarifies that the techniques demonstrated are more aligned with security research than traditional digital forensics. To effectively engage in this work, skills in reverse engineering and understanding cryptography are essential.

Identifying Vulnerabilities

While some vulnerabilities can be discovered through simple trial-and-error methods (e.g., crashing a terminal), many require deeper investigation into firmware and code analysis to find exploitable inputs.

Concerns about the Internet of Things (IoT) are raised, noting that if high-end mobile devices have significant security flaws, IoT devices—often built with less stringent security measures—are likely even more vulnerable.

Trust Zone Concept

A question about Trust Zones leads to an explanation: Android operates as a large system managing various tasks while also addressing security concerns. Trust Zones aim to create a smaller operating environment dedicated solely to secure operations.

The concept behind Trust Zones is maintaining a minimal attack surface by isolating sensitive operations from the broader Android ecosystem. This separation aims to enhance security by reducing complexity and potential bugs.

Hardware Support for Security

It’s explained that hardware plays a crucial role in enforcing separation between different operational environments (Android vs. Trust Zone). This hardware support ensures strict communication protocols between these zones.

Boot ROM checks signatures during startup processes; it will not allow execution unless valid signatures are confirmed. This mechanism helps protect against unauthorized modifications post-initialization.

Addressing Potential Attacks on Trust Zones

Although theoretically possible, attacks on Trust Zones must navigate strict hardware-enforced boundaries designed to minimize risks associated with cross-environment interactions.

Despite efforts to reduce attack surfaces within Trust Zones through careful design and implementation, attackers may still find ways around these defenses; thus ongoing vigilance is necessary in securing these environments.

Understanding TrustZone Security

Communication and Security in TrustZone

The communication between the fingerprint reader and TrussZone must be secure to prevent man-in-the-middle attacks, emphasizing the importance of robust security measures.

The hardware protecting the TrustZone is designed with high-security requirements, aiming to keep the code minimal for enhanced security.

Vendor Perspective on TrustZone Security

Vendors believe that while vulnerabilities may exist, they prioritize securing the TrustZone, allowing for a penetrated Android system as long as the TrustZone remains intact.

The speaker acknowledges skepticism about security but encourages exploration of potential vulnerabilities within the system.

Project Insights and Challenges

The discussion reflects on a personal project aimed at exploring vulnerabilities rather than being part of a Ph.D. thesis, indicating an experimental approach to understanding device security.

Implementing and testing vulnerabilities on one device highlights the extensive effort required to assess all devices used in law enforcement, suggesting significant time investment for comprehensive analysis.