Forensic Operations for Recognizing SQLite Content (FORC): History
Please note this is an old version of this entry, which may differ significantly from the current revision.

Mobile forensics is crucial in reconstructing various everyday activities accomplished through mobile applications during an investigation. Manual analysis can be tedious, time-consuming, and error-prone. Forensic Operations for Recognizing SQLite Content (FORC) is an automated tool specifically designed for Android to extract Simple Query Language Table Database Lightweight (SQLite) evidence.

  • automated forensics tool
  • SQLite
  • evidence extraction
  • Android

1. FORC Overview

The FORC (Forensic Operations for Recognizing SQLite Content) tool has been meticulously developed to facilitate mobile forensic investigations, with a specific focus on SQLite data. The reasons behind customizing FORC to support extracting SQLite include:
  • Ubiquity of SQLite: SQLite databases are ubiquitous in mobile devices, especially on Android and iOS platforms. Many critical pieces of information, such as call logs, text messages, and application data, are stored in SQLite databases. Given the prevalence of SQLite, SQL-based forensic tools like FORC are indispensable for comprehensive data extraction.
  • Data Structure and Relationships: SQL databases, including SQLite, are known for their structured data format and support for complex relationships between data elements. Mobile devices often store data in structured tables with well-defined schemas, making SQL databases suitable for forensic investigations in which preserving data integrity and relationships is paramount.
  • Standardization and Consistency: The use of SQL databases adheres to well-established data-management and querying standards. This standardization ensures consistency and reliability in data extraction, which is critical when dealing with digital evidence that may be subject to legal scrutiny.
  • Data Recovery and Analysis: SQL-based tools offer advanced capabilities for data recovery and analysis. They can handle complex SQL queries, data joins, and filtering, enabling forensic experts to extract and interpret a wide range of digital artifacts effectively.
  • Legacy Data: Many older mobile devices and applications rely heavily on SQL databases. Legacy data stored in these databases can provide crucial insights in forensic investigations. SQL-based tools are essential for extracting and analyzing data from older devices.
To ensure the legality and admissibility of the extraction process in the court, the methodology recognized by National Institute of Standards and Technology (NIST), and known to forensic investigators, is followed. NIST is a U.S. government agency responsible for developing and promoting measurement standards, including standards related to digital forensics. The NIST methodology serves as a comprehensive framework for forensic practitioners to follow when conducting mobile device examinations. It helps maintain the integrity and reliability of the data, given the credibility, reliability and admissibility of digital evidence collected from mobile devices required in a legal context, such as in court proceedings. Procedures of the NIST methodology in mobile forensics include:
  • Evidence Handling: Proper procedures for collecting, preserving, and documenting digital evidence from mobile devices to maintain its integrity and chain of custody.
  • Data Acquisition: Guidelines for acquiring data from mobile devices, whether through logical, physical, or file-system-extraction methods, while minimizing potential data alteration.
  • Data Analysis: Techniques for analyzing the acquired data, which may involve decoding and interpreting various file formats, databases, and system artifacts on mobile devices.
  • Reporting: Recommendations for documenting findings, preparing reports, and presenting evidence in a clear and understandable manner for legal purposes.
  • Validation: Ensuring that forensic tools and techniques used in the examination of mobile devices are scientifically validated and meet established standards.
  • Legal Compliance: Adherence to legal and ethical standards, as well as compliance with relevant laws and regulations governing digital evidence collection and presentation.
The FORC tool, developed to validate the NIST methodology, is programmed using a combination of key technologies. FORC utilizes PYQT5, a free software used for designing the graphical user interface (GUI). The core programming is performed in Python 3.9.4, providing the tool’s functionality. Additionally, the Sleuth Kit, a library and set of digital forensic tools, is employed for handling forensic images, with integration facilitated through the pytsk3 library. The Sleuth Kit, created by Brian Carrier, is a versatile collection of open-source command-line tools frequently employed in digital forensics investigations. These tools offer a comprehensive set of functionalities, encompassing file recovery, metadata extraction, and keyword searching, and support various file systems such as NTFS, FAT, and Ext.
FORC’s primary objective is to automatically identify and recognize pertinent SQLite files essential for forensic examination. It employs a twofold approach to achieve this. First, it considers the file extensions of the target files to ensure that all potential evidence is systematically included. Additionally, FORC leverages a distinctive “magic” header string consisting of a 16-byte hexadecimal sequence, “53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00”, in ASCII format. This header string is intrinsic to valid SQLite database files and serves as a reliable marker for the accurate identification and extraction of pertinent SQLite evidence. Furthermore, FORC’s capabilities extend to encompass both physical image and ADB-backup acquisitions, broadening its range of applicability in data-acquisition scenarios. The sequential steps involved in FORC’s automated data acquisition, analysis, and reporting are depicted in Figure 1, illustrating the tool’s comprehensive workflow.
Figure 1. Flowchart of the FORC tool.
As illustrated in the flowchart, via FORC, investigators have the flexibility to initiate a new project or to load an existing one with a user-friendly wizard comprising two steps: inputting case information (i.e., including the case number, investigator’s name, date of the case, and case description) and connecting the device to the workstation via USB cable (automatically detecting smartphone specifications and installed packages). The primary window of the FORC tool is visually represented in Figure 2, while Figure 3 showcases the New Case window, which appears when initiating a new case.
Figure 2. Main window of the FORC tool.
Figure 3. FORC tool: New Case window.
To initiate a new acquisition, a USB cable is required to establish a connection between the mobile device and the workstation. Upon successful connection, FORC automatically retrieves essential smartphone specifications and the list of installed packages, as depicted in Appendix A Figure A1. Following a successful connection with the workstation, investigators are guided to select their preferred acquisition method, choosing between ADB backup or Raw image, as demonstrated in Appendix A Figure A2.
Upon method selection, FORC initiates the BusyBox software on port 8888 to enable the physical acquisition process, as highlighted in Appendix A Figure A3. Upon completion of this task, details such as image size, acquisition time, and data transfer speed are displayed, and a screen with the partition table, image hash value, and acquisition date appears. The resulting forensic image is saved with a .dd extension. Upon the successful acquisition of the image, a subsequent screen (Appendix A Figure A4) presents the partition table of the image, the hash value calculated using MD5, and the image acquisition date. FORC offers the flexibility to load ADB backups with .ab or .tar extensions by specifying the image path. It also enables the loading of physical images with the .dd extension for subsequent analysis. In this case, users must provide the image location. Additionally, the FORC tool incorporates a report function empowering investigators to generate case reports based on the assigned case number.

2. Acquisition Requirements

Acquisition is the crucial first step in the process of extracting data from smartphones. The extracted data is then processed forensically to obtain digital evidence. The FORC tool provides investigators with two options for acquisition: ADB backup and physical acquisition. Before starting the acquisition, investigators must consider the following points:
  • Ensuring the smartphone is turned on.
  • Ensuring the smartphone is unlocked.
  • Enabling USB debugging.
  • Connecting the smartphone to the computer or workstation using the original USB cable.
  • Selecting the appropriate option on the smartphone screen to establish a communication between the mobile phone and the workstation.
  • For ADB backup, rooting is not required, but for physical acquisition, rooting is essential, and it cannot be performed without rooting. The appropriate tool, such as BusyBox, must be used for rooting the device, depending on the mobile device and the installed Android version.3.2.1. Handling Forensics Image.
  • ADB backup:
After executing the ADB backup command, a file with an .ab extension will be generated. To ensure compatibility with the FORC tool, a vital procedure entails converting the .ab file into a .tar file, as illustrated in Figure 4.
Figure 4. Converting .ab file to .tar file.
  • Physical acquisition:
For physical acquisition, as previously noted, rooting is imperative, resulting in a .dd file extension. To process forensic images with the .dd extension, the FORC tool seamlessly integrates the Sleuth Kit library through the pytsk3 module. The extracted data can be handled like any other folder on the computer, akin to data extracted in the case of ADB backup.

3. FORC Data Processing: Recognizing SQLite Files

Within mobile devices, databases function as containers housing data from various mobile applications, each maintained within its SQLite database. The FORC tool streamlines the automatic extraction of SQLite evidence, employing both file extensions and file headers for identification and extraction, as elucidated in Appendix A Figure A5. SQLite files exhibit various extensions (e.g., .db, .db3, .sqlite, and .sqlit3) or may even be devoid of an extension altogether. However, each valid SQLite database file unmistakably includes a “magic” header string, fundamental for the identification and recognition of SQLite files.
With FORC, SQLite files are seamlessly extracted, granting investigators direct access to explore and examine them, without necessitating additional software. Moreover, FORC empowers investigators to select sets of evidence directly from these databases, associating them with specific case numbers for subsequent report generation. The generated report encompasses four primary sections:
  • Case Information: This section includes critical case details, such as the case date, case description, investigator’s name, case number, and image hash value.
  • Workstation Information: Automatically generated by the FORC tool, this section provides insights into the workstation used for forensic analysis, including the operating system, node name, and username.
  • Mobile Device Details: This section presents information related to the mobile device in question, including the serial number, device name, and manufacturer.
  • Evidence Details: Investigators can comprehensively document the selected set of pieces of evidence, including evidence specifics, the table and column where the evidence resides, and the path to the SQLite database file.

This entry is adapted from the peer-reviewed paper 10.3390/app131910736

This entry is offline, you can click here to edit this entry!
Video Production Service