Mobile Anti-Forensics: Hidden Evidence and Forensic Recovery

When Deleted Does Not Mean Gone

Smartphones contain far more investigative information than users can see through their screens. Application databases, temporary files, system logs and cached records may preserve traces of activity long after the visible content has disappeared.

This creates an important challenge in digital investigations. Information can be deleted, concealed, encrypted or deliberately manipulated, while the forensic examination itself may introduce additional changes.

These challenges fall under mobile anti-forensics: techniques intended to obstruct investigations by hiding, removing, altering or misrepresenting digital evidence. Understanding these techniques requires more than attempting file recovery. Investigators must establish how data was stored, identify possible manipulation and assess the reliability of the acquisition process.

Understanding Mobile Anti-Forensics

Mobile anti-forensics includes several techniques that produce different investigative challenges.

• Data hiding: Information may be stored in application-private directories, embedded in media files, concealed within databases or protected inside encrypted containers.
• Deletion and wiping: Ordinary deletion generally makes storage space available for reuse. Secure wiping attempts to make previous information unrecoverable, although its effectiveness depends on the storage medium and implementation.
• Encryption: Android uses File-Based Encryption (FBE) to protect data. Access may depend on device authentication, encryption keys and the acquisition method.
• Trail manipulation: Application records, timestamps or other artifacts may be altered to create a misleading account of activity.

These techniques should not be treated as equivalent. A missing file does not establish secure wiping, and an inconsistent record does not automatically demonstrate deliberate manipulation.

Where Residual Evidence May Survive

Residual evidence refers to information that remains after an operation appears to have removed or changed the original data.

Android applications commonly use SQLite databases to store messages, contacts, account information, activity records and settings. These databases may have associated files:

• Main database (.db): Contains the primary database pages.
• Write-Ahead Log (-wal): May contain recent transactions not yet checkpointed into the main database.
• Shared-memory file (-shm): Supports coordination between database connections using WAL mode.
• Rollback journal: May preserve database information during certain transaction operations.

Examining only the main database can therefore produce an incomplete picture. A relevant transaction may still be represented in a WAL file, depending on checkpointing, reuse and subsequent database activity.

Other potential evidence sources include application logs, cached media, thumbnails, notification-related artifacts, browser data and filesystem metadata.

The Scientific Working Group on Digital Evidence (SWGDE) identifies SQLite databases as important mobile forensic evidence sources and recommends considering associated journal and WAL files during examination. It also notes that automated tools may have parsing limitations, making manual analysis necessary in some circumstances.

Why Deletion Is Not the Same as Secure Wiping

Smartphones use flash-based storage, which behaves differently from conventional magnetic hard drives.

Two mechanisms are particularly relevant:

• Wear levelling: Distributes writes across memory cells to reduce uneven physical wear.
• Garbage collection: Reclaims storage blocks by consolidating valid data and preparing blocks for reuse.

The operating system may also issue discard or TRIM-related commands to indicate that certain storage blocks are no longer required.

These mechanisms make deleted-data recovery unpredictable. A deleted logical file does not necessarily remain at a stable physical location, and subsequent storage activity may make recovery impossible.

A 2026 study by Oh and colleagues evaluated six Android file-wiping applications. One application advertised wiping functionality but performed ordinary file deletion instead. The researchers also identified traces associated with wiping-tool execution and artifacts of wiped files.

The finding demonstrates why investigators should examine what an application actually does rather than relying on its advertised functionality. A missing file alone does not prove secure wiping, while failure to recover a file does not prove that it never existed.

Detecting Fabricated or Manipulated Records

Recovering a record does not automatically establish its authenticity.

Consider a message entry found in an application database. Its presence alone cannot establish who created it, whether it was modified or whether its timestamp accurately represents the original event.

Investigators should seek corroboration from relevant sources, including:

• Related database transactions and WAL pages.
• Application logs and notification-related artifacts, where available.
• Associated media files and metadata.
• Account synchronisation records.
• Device clock and time-zone settings.
• Network or service-provider records, where lawfully available.

Timestamps require particular care. Applications may store time as Unix epoch values, local time strings or database-generated values. Differences can arise from time-zone conversion, incorrect device clocks, delayed synchronisation or distinctions between event time and record-creation time.

Database structure can provide additional context. Investigators may examine whether records follow the expected schema, whether identifiers and relationships are consistent, and whether surrounding transactions support the record's interpretation.

An unusual entry is an investigative lead, not automatic proof of fabrication. Software errors and legitimate application behaviour can also produce unexpected records.

Recovering Deleted Database Fragments

In some circumstances, deleted or fragmented database pages may survive outside the active database structure.

A September 2026 research paper presented · WALRUS, a framework for reconstructing deleted and encrypted SQLite Write-Ahead Log pages from unallocated storage space.

The approach combines structural validation, fragment identification and selective decryption to reconstruct recoverable database pages. However, it depends on independently obtained decryption material, knowledge of the relevant page size and encryption scheme, and the availability of recoverable fragments.

Partial overwriting and severe fragmentation can limit reconstruction. Recovering a page also does not necessarily establish the complete transaction or the context in which a record was created.

WALRUS does not break encryption. It demonstrates how residual database structures may remain useful for forensic reconstruction when the required cryptographic material is already available.

Can Forensic Acquisition Change Evidence?

Modern Android security has made data acquisition more complicated. Full File System (FFS) extraction may require a device to be booted and its encrypted user-data partition to be accessed.

Once a device is operating, background applications and system services may update logs, temporary files, databases and other records. Network activity can introduce further changes.

A 2026 study by Yoo, Park and Jeong examined hash inconsistencies across repeated Android FFS acquisitions. The researchers found that system-generated files and logs were more prone to change, while much user-generated content remained stable. Their evaluation also identified differences in consistency between repeated acquisitions using the same tools and comparisons across different tools.

This has an important implication: a hash mismatch does not automatically prove tampering. It may reflect normal operating-system activity or changes introduced during acquisition.

The role of cryptographic hashing

Algorithms such as SHA-256 generate a digest from a set of data. Investigators use hashes to verify that acquired evidence has not changed during subsequent handling and to compare forensic copies.

However, a hash establishes whether the compared data is identical. It cannot independently prove that the original information was authentic before acquisition.

A defensible process should document the device state, acquisition method, tool and version, relevant interactions, timestamps, errors and hash values. Expected acquisition-related changes should also be identified and explained.

Tools Used in Mobile Anti-Forensics Investigations

Investigators combine acquisition platforms, artifact parsers and manual examination because no single tool identifies every anti-forensic technique.

Automated tools can accelerate analysis, but their output requires validation. A tool may not support a newer application database, may misinterpret a changed schema or may omit artifacts outside its capabilities.

For important findings, investigators should examine underlying files and database structures where possible. Tool versions, parsing assumptions and limitations should be recorded.

A Defensible Examination Workflow

A structured process helps separate direct observations from interpretations.

1. Preserve: Document the device's physical condition, displayed state, connectivity and relevant observations. Follow applicable legal authority and evidence-handling procedures.
2. Plan: Select an acquisition method based on the device model, Android version, encryption state and investigative objectives. Logical, filesystem and physical-level acquisitions do not provide equivalent access.
3. Acquire and document: Preserve original outputs, calculate hashes where applicable, record tool versions and document interactions that could change device state.
4. Examine: Identify relevant databases, WAL and journal files, logs, caches, media and filesystem metadata.
5. Correlate: Compare records across independent sources. Investigate timestamp differences and structural inconsistencies.
6. Validate and report: Verify important findings through manual examination or another suitable method. State assumptions, limitations and alternative explanations.

For example, an absent record in a main database is an observation. A related WAL fragment may suggest an earlier transaction, but it does not independently establish the complete content or context of the missing record.

Beyond File Recovery

Mobile anti-forensics presents investigators with challenges involving hidden application data, ineffective wiping claims, encrypted database fragments, manipulated records and acquisition processes that can change a device's state.

Reliable examination depends on understanding how applications and operating systems store information, identifying related residual artifacts, validating acquisition results and correlating independent evidence sources.

Recovering a file is only one part of the investigation. Establishing its origin, integrity and evidential meaning is what makes the finding defensible.