Welcome back, aspiring investigators!

Today we’re going to cover the basics of iOS forensics and find out what makes these devices vulnerable. We will see what a phone actually holds in different states. Modern iPhones encrypt almost everything file by file, and the keys live inside a separate chip called the Secure Enclave, not the disk itself. So the question is  which keys are unlocked right now and how long you’ve got before that changes.

What’s On the Phone

Apple does not encrypt “the disk” as one volume key. Each file is assigned a class when it is created. The class decides when that file can be decrypted.

Class A files only decrypt while the phone is unlocked and lock again fast once the screen goes dark. Mail bodies live here. 

Class B can be written while locked but only read if it was already open. 

Class C is the one you care about most. It unlocks the first time the passcode is entered after a reboot and stays unlocked even after the screen locks again. App data, chats and photo libraries sit here. 

Class D never needs a passcode at all, wrapped with a device only key.

BFU and AFU

Before First Unlock (BFU) means the phone rebooted and nobody’s entered the passcode since. The Secure Enclave hasn’t released the keys yet, Face ID and Touch ID are dead and almost nothing decrypts. What you get from a BFU phone is triage at best. Device info, iOS version, maybe a thin slice of metadata.

After First Unlock (AFU) means the passcode has been entered at least once since the last reboot. Class C data is live and stays live even after the screen locks again. This is the state you want. Analysts usually say AFU gets you around 95% of what a full dump would give you, next to almost nothing under BFU.

The 72 Hour Clock

Since iOS 18.1, a phone that sits idle too long reboots itself. No setting turns this off. The window is around 72 hours. A Faraday bag isn’t a place to park evidence for a week anymore. Labs have already had properly isolated AFU phones reboot themselves back into BFU just from sitting in storage. 

How You Actually Pull Data

The simplest is a standard logical backup through iTunes or Finder. An unencrypted backup is a partial picture at best, since Keychain and Health data only come along encrypted. One step up is advanced logic, which adds access to the camera roll, books and other shared media a plain backup skips. 

Full file system extraction is usually done through a signed agent while the phone’s still AFU. This gets you app sandboxes, full SQLite databases with their WAL and SHM files and the behavioral stores a backup never touches. Agent support for new chips lags behind hardware releases and current A19 and M5 chips with Memory Integrity Enforcement are already a wall some agent chains can’t get past.

Older phones, iPhone X and earlier, can sometimes be opened with bootrom exploits like checkm8, which run below the OS entirely and can work even in BFU. That doesn’t apply to anything shipping today.

iCloud is its own separate source. It can hold things the phone doesn’t and end-to-end encrypted categories still need real credentials or lawful process.

Pairing, USB Locks & Lockdown Mode

A pairing record gets created the moment someone taps Trust This Computer. That record lives on the host machine, and it can let a lab computer talk to a locked AFU phone without another unlock. So every computer the owner used matters just as much as the phone itself.

USB Restricted Mode is separate and much simpler, it’s just a timeout. After roughly an hour locked, the port stops carrying data even though it keeps charging. An old pairing record won’t work once that timer’s up, so every locked phone has a short window.

Lockdown Mode is a different thing entirely. It’s a user enabled hardening feature aimed at spyware, and while it’s active, wired accessories need an unlocked phone. That’s the mechanism that reportedly stopped FBI investigators from extracting a seized reporter’s iPhone in early 2026, even though the phone was powered on and charging right in front of them. Turning Lockdown Mode on or off also reboots the phone, so flipping it yourself kills AFU instantly.

Jailbroken Phones

Some devices may be jailbroken. These are softer targets, but they can’t be trustworthy. Jailbreaking modifies the filesystem and tweaks change or hook app behavior. That can overwrite artifacts, add artifacts that aren’t from normal use and give opposing counsel a way to challenge integrity.

Cellebrite

Cellebrite’s old UFED, Premium and Physical Analyzer lineup is mostly folded into one suite now called Inseyets, though Premium and PA7 are both still running too. Their own docs use AFU and BFU just like everyone else, because the same rules apply. AFU with a supported device opens up fully. BFU on current phones mostly doesn’t, no matter which Cellebrite tool you’re running. Support trails Apple by weeks or months after every iOS release, and brute force support stays limited to specific older models on specific iOS ranges, not a blanket “any locked iPhone” claim.

For old hardware, iPhone 5s through X, they lean on the same checkm8 style bootrom exploit covered earlier.

Worth remembering too, in 2021 Signal’s founder found real bugs in the tool itself

What You Actually Dig Through

Chat apps like iMessage, WhatsApp, Signal and Telegram each keep their own SQLite database, and deleted rows often still sit in the freelist or the WAL file until the database gets cleaned up. Always grab the WAL and SHM files alongside the main database, not just the .db file by itself.

The real skill jump in this field is using behavioral stores. KnowledgeC and its newer replacement, Biome, track which app was in focus, unlock events, notifications, even web activity. That’s how you reconstruct what was actually on screen at a given moment. PowerLog backs that up by confirming the phone was genuinely powered on and connected at a given time.

Photos.sqlite covers hidden and recently deleted images along with iCloud sync state. As you can see, deletion on iOS basically means the key gets destroyed and the database gets cleaned up later, there’s no recycle bin sitting in unallocated space waiting for you to carve out. If someone claims they recovered deleted iMessages from raw flash on a modern iPhone, that claim needs real scrutiny.

Summary

Keep your iPhone protected by updating the firmware and upgrading the device itself regularly. Old devices are prone to certain attacks, and as years go by more vulnerabilities get discovered. Analysts are already using these vulnerabilities to bypass protection and extract data from older iPhones. Keeping backups off iCloud adds an extra layer of protection. Don’t connect your iOS device to your computer and don’t accept anything that pops up on the screen afterward. iOS 18 adds some protection by bringing the phone from AFU back to BFU after 72 hours. These recommendations can help if your life is threatened by people who don’t respect the law. If you’re a forensic investigator, use this knowledge to bring justice to the case. Stay safe out there!

The post Digital Forensics: iOS Forensics – Basics  first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

The modern digital ecosystem has undergone a silent but total transformation. Every day, we interact with ARM-based processors billions of times. These chips drive almost all iOS and Android devices and are key to the significant performance improvements seen in Apple’s M-series Macs. Some lightweight notebooks, such as Chromebooks, use ARM processors. IoT devices are largely powered by ARM. Besides that, recently ARM expanded into silicon production with the Arm AGI CPU, its first production-ready silicon designed for agentic AI workloads in data centers. With this level of ubiquity in our digital world, it’s important to be familiar with ARM.

Therefore, this article serves as a foundation for learning about ARM. It delves into the architecture of ARM CPUs, covering design principles and energy efficiency. Let’s get rolling!

What is ARM?

ARM is a family of CPU designs based on a simple, efficient instruction set (RISC). It started as ‘Acorn RISC Machine’, then ‘Advanced RISC Machines’, and now it’s just called ARM.

Unlike traditional chipmakers, Arm Holdings does not manufacture physical processors. Instead, the company designs the foundational CPU architecture and licenses its intellectual property and processor cores to other hardware manufacturers (such as Apple and Nvidia).

What is an ARM-Based CPU?

ARM CPUs use a simple, efficient RISC instruction set. RISC stands for Reduced Instruction Set Computer. It represents a hardware design philosophy focused on streamlining how a processor interprets and executes software instructions.

This design philosophy stands in direct contrast to CISC (Complex Instruction Set Computer), which is the architecture utilized by traditional Intel and AMD x86 processors.

The RISC concept originated in the early 1980s, heavily influenced by research at the University of California, Berkeley. Researchers evaluating resource usage discovered that most software programs only utilized a small fraction of a processor’s complex, built-in instruction set. They realized that if they removed the highly complex, rarely used, and difficult-to-implement instructions, the remaining simpler instructions could execute much faster, while requiring significantly less physical space and power on the silicon chip. This discovery led directly to the development of early RISC designs, including the foundational Acorn RISC Machine (ARM) project in 1983.

Core Principles of RISC Design

RISC architectures use a fixed instruction width for high-speed execution. Unlike CISC architectures that have instructions of varying lengths, a modern 64-bit RISC architecture like ARM64 uses a uniform instruction size, typically 32 bits. This consistency makes it easier for the processor to identify where one instruction ends and the next starts, which helps in quickly fetching, decoding, and executing instructions.

A key feature of RISC design is its Load-Store architecture. In traditional CISC, a single instruction might perform operations directly on data in memory. In RISC, memory access and calculations are separate. In a RISC CPU, Arithmetic Logic Unit (ALU) operations only happen between registers, which are small, fast storage spaces on the processor. To work with data from memory, the processor has to first load it from RAM into a register, perform the calculation in the register, and then store the result back to memory.

To meet the needs of this Load-Store model, RISC processors have a large, uniform register file. Since data cannot be processed directly in memory, the CPU needs many registers to keep temporary data readily available. A 64-bit RISC processor usually has 31 general-purpose 64-bit registers that act as a quick local workspace.

The clear and register-focused design leads to mostly single-cycle execution and effective hardware pipelining. Because RISC instructions are straightforward and mainly work with registers, most can finish in one clock cycle. This single-cycle capability enables the processor to use an instruction pipeline. In this system, while one instruction is executed, another is decoded, and a third is fetched from memory simultaneously. This overlap helps the processor complete a new instruction nearly every clock tick, maximizing efficiency.

Feature / Approach	CISC (e.g., x86)	RISC (e.g., ARM)
Instruction complexity	Single instructions perform multiple tasks (data manipulation, memory access, arithmetic)	Breaks tasks into multiple simpler instructions
Execution example	One instruction: load → compute → store	Three separate instructions: load → compute → store
Decoding logic	Intricate and complex	Simpler, more uniform
Clock cycles per instruction	Often multiple cycles	Usually one cycle per simple instruction
Hardware requirements	Substantial hardware for decoding and execution management	Less hardware for decoding, more uniform control logic
Power & design impact	Higher power consumption and design complexity	Lower power consumption, simpler design
Optimization	Harder to optimize individual operations	Easier to optimize each step independently
Parallel execution	More difficult	Easier to achieve

Energy Efficiency

Firstly, at the core of the RISC philosophy is the use of a smaller vocabulary of simpler, fixed-length instructions. Because the CPU does not have to parse highly complex, variable-length instructions, the physical hardware required to decode and execute instructions is dramatically simplified. This simplicity results in a vastly reduced transistor count. For example, early ARM cores required only 30,000 to 35,000 transistors. Fewer transistors mean that fewer components are active during each instruction cycle, which directly lowers dynamic power consumption and dynamic leakage.

Secondly, RISC processors are designed to scale their power draw dynamically based on the active workload. Through techniques like Dynamic Voltage and Frequency Scaling (DVFS), the processor automatically lowers its operating voltage and clock speed during periods of low computational demand, conserving energy when peak performance is unnecessary. For example, microcontroller-class processors like the ARM Cortex-M series are engineered to draw almost zero power when in deep sleep states, yet they can wake up and execute tasks rapidly on demand.

Thirdly, on a system-on-chip level, modern RISC implementations leverage heterogeneous processing, such as Arm big.LITTLE and DynamIQ technologies. Instead of running all tasks on identical, power-hungry cores, the processor combines:

LITTLE cores: Tiny, ultra-efficient cores optimized to handle routine, low-intensity background tasks (like texting, email, or playing music) using minimal power.

big cores: High-performance cores designed to tackle heavy, sustained workloads (like mobile gaming or intense web browsing).

This dynamic, on-demand task allocation ensures that the high-power “big” cores are only activated when strictly necessary, maximizing overall battery life.

Apple M-series Chips

The Apple M-series chips are a group of processors made by Apple Inc. They are designed for efficient performance and are based on ARM architecture. Each chip includes a CPU, GPU, a Neural Engine for machine learning, and a unified memory system that helps improve overall efficiency.

Apple announced its move to its own M-series chips at the Worldwide Developers Conference (WWDC) on June 22, 2020. This change was from Intel’s x86 processors to ARM-based designs for better power efficiency and performance.

For example, the M1 chip offers up to 3.5 times faster CPU performance while consuming less power than Intel chips for certain tasks. This allows for high performance without generating too much heat.

The M-series chips also improve battery life. Devices often run up to 1.5 times longer than Intel-based Macs. This is due to their optimized power management. In real-world use, like watching videos or doing light work, the MacBook Air can last 15 to 18 hours, compared to the 11 to 12 hours typical of similar Intel models.

By 2026, devices like the Mac Studio and Mac Mini are using M-series CPUs to run advanced AI models directly on users’ desks. Many people are shifting away from paying for AI services and choosing local systems instead.

Summary

In this article, we discussed ARM, a CPU architecture based on RISC principles, which emphasizes simplicity and efficiency. We explained how ARM differs from x86/CISC (Intel/AMD), noting that its smaller instruction set uses fewer transistors and less power. Additionally, we looked at how ARM has impacted Apple’s M-series chips, showing gains in performance, heat management, and battery life, along with the shift toward handling AI tasks on ARM hardware.

The post ARM CPU Architecture: The Power of Simplicity and Efficiency first appeared on Hackers Arise.

Welcome back, digital investigators!

Many of our messengers sit somewhere between privacy and routine. People treat chats like a private conversation and because it feels comfortable, they often share things they wouldn’t say on social media. The data stored in those apps is valuable for forensics. It may have chats, media and group membership with timestamps. Using this data we can reconstruct events. 

We’re going to take a close look at WhatsApp forensics today and show you the artifacts you can find on Android and iOS. It’ll be a deep dive on how WhatsApp keeps its data and what those files contain. All of it in plain language.

At Hackers-Arise we assist people with forensic investigations to uncover cybercrime and help with incident response. WhatsApp is part of that.

WhatsApp Artifacts on Android Devices

On Android, WhatsApp stores its private app data inside the device’s user data area. You will find the app’s files under /data/data/com.whatsapp/ or equivalently /data/user/0/com.whatsapp/ on many devices. These directories are not accessible without root, so to read them directly you need a physical dump of the file system or root. If you do not have root or a physical image, your options are restricted to logical backups.

There are two important files here: wa.db and msgstore.db. Both are SQLite databases and together they form the core of WhatsApp evidence.

wa.db is the contacts database. It has the WhatsApp user’s contacts with phone numbers, display names, status, timestamps for when contacts were created or changed. You can open the file with a SQLite browser to see its tables. The interesting tables here are those that store contact records (wa_contacts or similar), sqlite_sequence that has auto-increment counts and android_metadata with app language.

Wa.db is basically the address book for WhatsApp. It has names, numbers and a little context for each contact.

msgstore.db is the message store. This database has sent and received messages, timestamps, message status, senders and receivers and references to media files. In many WhatsApp versions you will find tables that include a general information table (sqlite_sequence), a full text index table for message content (message_fts_content or similar), the main messages table which usually contains the message body and metadata, messages_thumbnails which has images and their timestamps, and a chat_list table that stores chat entries. 

Be aware that WhatsApp changes its structure and field names may change between versions. Newer schema versions may include extra fields such as media_enc_hash, edit_version, or payment_transaction_id. So you need to inspect the schema first.

On many Android devices WhatsApp also keeps encrypted backups in a public storage location that you can find under /data/media/0/WhatsApp/Databases/ (the virtual SD card)

or /mnt/sdcard/WhatsApp/Databases/ for physical SD cards. Those backup files look like msgstore.db.cryptXX, where XX shows the cryptographic scheme version. 

The msgstore.db.cryptXX files are an encrypted copy of msgstore.db intended for device backups. To decrypt them you need a cryptographic key that WhatsApp stores privately on the device. The key can usually be found here: /data/data/com.whatsapp/files/. Without that key those encrypted backups are not readable.

Other important Android files and directories to examine include the preferences and registration XMLs in /data/data/com.whatsapp/shared_prefs/. The file com.whatsapp_preferences.xml often contains profile details and configuration. A fragment of such a file may show the phone number associated with the account, the app version, a profile message such as “Hey there! I am using WhatsApp” and the account display name. The registration.RegisterPhone.xml file typically has registration metadata like the phone number and regional format. 

The axolotl.db file in /data/data/com.whatsapp/databases/ holds cryptographic keys (used in the Signal/Double Ratchet protocol implementation) and account identification data. chatsettings.db has app settings. Logs are kept under /data/data/com.whatsapp/files/Logs/ and may include whatsapp.log as well as compressed rotated backups looking like whatsapp-YYYY-MM-DD.1.log.gz. They show app activity and errors.

Media is often stored in the media tree on internal or external storage:

/data/media/0/WhatsApp/Media/WhatsApp Images/ for images,

/data/media/0/WhatsApp/Media/WhatsApp Voice Notes/ for voice messages (usually Opus format), WhatsApp Audio, WhatsApp Video, and WhatsApp Profile Photos.

Within the app’s private area you may also find cached profile pictures under /data/data/com.whatsapp/cache/Profile Pictures/ and avatar thumbnails under /data/data/com.whatsapp/files/Avatars/. Some avatar thumbnails use a .j extension, but those are just JPEG files.

If the device uses an SD card, a WhatsApp directory at the card’s root may store copies of shared files (/mnt/sdcard/WhatsApp/.Share/), a trash folder for deleted content (/mnt/sdcard/WhatsApp/.trash/), and the Databases subdirectory with encrypted backups and media subfolders mirroring those on internal storage. Deleted files in .trash folders can be used to recover media.

Keep in mind, some vendors may add features that change where app data is stored. For example, certain Xiaomi phones implement a “Second Space” feature that creates a second user workspace. WhatsApp in the second workspace stores its data under a different user ID path. That means it may be under /data/user/10/com.whatsapp/databases/wa.db rather than the usual /data/user/0/com.whatsapp/databases/wa.db

WhatsApp Artifacts on iOS Devices

On iOS, WhatsApp centralizes its data into a few places and all that data is commonly accessible via device backups. The main application database is often ChatStorage.sqlite located under /private/var/mobile/Applications/group.net.whatsapp.WhatsApp.shared/ but some forensic tools may display this as AppDomainGroup-group.net.whatsapp.WhatsApp.shared

Within ChatStorage.sqlite the interesting tables are ZWAMESSAGE and ZWAMEDIAITEM. The first one stores message records and the other one has metadata for attachments and media items. ZWAPROFILEPUSHNAME and ZWAPROFILEPICTUREITEM map WhatsApp identifiers to display names and avatars. The table Z_PRIMARYKEY may have general database metadata such as record counts.

iOS also places supporting files in the group container. BackedUpKeyValue.sqlite can contain cryptographic keys and data for identifying account ownership. ContactsV2.sqlite stores contact details which include names, phone numbers, profile statuses and WhatsApp IDs. The consumer_version file holds the app version and current_wallpaper.jpg (or wallpaper in older versions) has the background image used in WhatsApp chats. The blockedcontacts.dat file lists blocked numbers, and pw.dat can hold an encrypted password. net.whatsapp.WhatsApp.plist or group.net.whatsapp.WhatsApp.shared.plist store profile settings.

Thumbnails, avatars and media are stored under /private/var/mobile/Applications/group.net.whatsapp.WhatsApp.shared/Media/Profile/ and /private/var/mobile/Applications/group.net.whatsapp.WhatsApp.shared/Message/Media/. WhatsApp logs (calls.log and calls.backup.log) can be found in the Documents or Library/Logs folders and will have information on call activity.

iOS devices are often backed up through iTunes or Finder, so you can extract WhatsApp artifacts from a device backup without a full file system image. If the backup is unencrypted it may include the ChatStorage.sqlite file and associated media. If the backup is encrypted you will need the backup password or legal access methods to decrypt it. Many investigators create a forensic backup and then examine the WhatsApp databases with a SQLite viewer and other forensic tools (Belkasoft) that understands this WhatsApp schema differences across versions.

Summary

Plainly speaking, WhatsApp forensics can help us understand who a suspect interacted with by viewing chat histories with timestamps, media files, message status (sent, delivered, read), groups, profile names and avatars and more. We understand this data can be accessed without authorization, violating people’s privacy, so part of our goal here was to show just how much data is actually stored on your phone. If you’re part of a sensitive group, look for other secure alternatives to WhatsApp and make sure your chats get deleted regularly to prevent unauthorized access to them. Disable cloud backups and try not to store those backups locally either. Even encrypted ones be cracked open by brute forcing the password.

If you’re interested in mobile forensics, you can join our training. We will walk you through the essentials of Android and iOS, explaining how evidence is stored on these devices. You will learn how investigators extract and analyze data, work with labs that involve finding hidden apps, working with encrypted chats and more.

The post Mobile Forensics: Extracting Data from WhatsApp first appeared on Hackers Arise.