AOSP Apps

Investigations
Part 1: AOSP Messaging Provider
AOSP Application/Services
What is AOSP Application?
• Android Open-Source Project Apps/Services
• Original purpose many years ago
• to provide a usable set of applications for someone building an Android
device from AOSP
• to serve as a demonstration for the nascent Android app developer
community, showcasing how they should build some of these applications
• to provide functionality to other Android applications that would interact with
them through the standard Android APIs
• to serve showcase richer set of features demonstrating the power of Android
 AOSP Apps/Services: com.andriod.*

you have an email app and a

browser app which talk to the
same backend server with
the same set of credentials.

contains data related to phone

operation, specifically SMS and
MMS messages, access to the APN
delivering IP multimedia list, including the MMSC to use,
services (text, video..) and the service state.

Recording device contains data related to phone

activity over a short operation, specifically SMS and
period of time is known MMS messages, access to the APN
as system tracing list, including the MMSC to use,
(research project?) and the service state.
Investigating AOSP Apps/Services
• Investigating messaging service
• com.android.providers.telephony
• Investigating contacts
management service
• com.android.providers.contacts
• Investigating calendar service
• com.android.providers.calendar
What are Messaging
Services?
SMS/MMS
Message service is a core
component of AOSP
• SMS (short message service)
• A text messaging service
component of most telephone,
Internet, and mobile device
systems
• MMS (Multimedia Message
Service)
• Send multimedia content—
pictures, video, and audio—in
addition to text

https://www.zdnet.com/article/facebook-messenger-on-android-gets-a-google-inspired-facelift /
Message service implementation

Can be used by other 3rd applications

Message service can be used by
other apps
Check apps using the message
services
The Role of Messaging
Services in Digital
Forensics
Important to investigate message
services
• Message apps are popular
• People use message apps to share information
• Evidence generated by the service
• SMS/MMS messages, call logs, carrier-related information.
Sample investigation questions
• Who sent the message?
• What is the content of the message?
• Does the message have attachments?
• Does the message contain multimedia information?
• Has the message been read?
• Which message app did the sender use to create the message?
Strategies to find evidence
• Understand how raw data are stored in disks
• often organized and stored in centralized locations such as databases, XML,
and text files.

Approach to find evidence

Message service folder structure

-L: Level
Investigating mmssms.db
Location of mmssms.db

This mmssms.db SQLite database typically contains tables with information such
as message content, sender/receiver phone numbers, timestamps, message status
(e.g., sent, received, draft), and MMS attachments or metadata.
Summary of Most Valuable Tables in
mmssms.db

• sms: SMS message data.

• pdu: MMS message data.
• part: MMS message parts (e.g., text, media).
• threads: Conversation grouping.
• canonical_addresses: Phone number
normalization.
• attachments: MMS attachment metadata.
• pending_msgs: Queued messages.
sms table
• Why It’s Valuable: This table is the core storage for SMS messages. It
contains the actual text messages, including the message body,
sender/receiver phone numbers, timestamps, message type (sent,
received, draft), and status (read, unread).
• Use Case: Essential for recovering or analyzing SMS communication
history, such as in forensic investigations or for apps that need to
display a user’s text messages.
pdu part table
• Why It’s Valuable: The pdu (Protocol Data Unit ) table stores the
metadata and overall structure of MMS messages. Need the part
table to retrieve the MMS messages.
• Use Case: Critical for reconstructing MMS messages or analyzing low-
level message data, especially in forensics or when debugging
messaging issues.
part table
• Why It’s Valuable: This table stores individual parts of MMS
messages, such as text, images, videos, or audio. Each MMS message
is multipart, and this table includes details like the content type (e.g.,
image/jpeg), file path, and the actual data or reference to the
attachment.
• Use Case: Key for accessing MMS content, such as retrieving
multimedia attachments in forensics or displaying MMS messages in
an app.
attachments table
• Why It’s Valuable: This table stores metadata about MMS
attachments, such as file paths, MIME types, and sizes of media files
(e.g., images, videos). It complements the part table by providing
additional details about multimedia content.
• Use Case: Important for retrieving or analyzing MMS attachments,
such as in data recovery or forensic analysis of multimedia messages.
threads table
• Why It’s Valuable: The threads table groups messages into
conversations. It links SMS and MMS messages to a specific thread
(conversation) with a contact or group of contacts. It includes
metadata like the thread ID, recipient IDs, and the timestamp of the
last message in the thread.
• Use Case: Essential for organizing messages into conversations, which
is how most messaging apps display data. It’s also useful for analyzing
communication patterns with specific contacts.
canonical_addresses table
• Why It’s Valuable: This table maps phone numbers to unique IDs,
normalizing them (e.g., removing country codes or formatting
differences). Other tables like sms and threads reference these IDs
instead of raw phone numbers, ensuring consistency.
• Use Case: Crucial for linking messages to contacts accurately,
especially when phone numbers might be stored in different formats.
It’s often used in forensics to identify who a message was sent to or
received from.
pending_msgs table
• Why It’s Valuable: This table stores messages that are queued for
sending but not yet delivered (e.g., due to lack of network
connectivity). It includes details like the message content, recipient,
and status.
• Use Case: Useful for troubleshooting failed message deliveries or
recovering messages that were never sent, especially in forensics or
app development.
Investigate sms table
conversation ID. indicates the specific
corresponds to thread Read flag:
SMS content • 0 : not been read
table (comes from the
same phone #) • 1: has been read
SMS center (SMSC)
phone # of the handles the SMS
entity who sent time the message operations of a
the message was received/sent App that
wireless network
created the sms
 How Messages are sent/received

SMS Service
Center Number
9811236789

SMS Service
Center Number
9811236789 SMS Service Center (SMSC) Number often is associated with your carrier
Which message was received on Jan
29, 2020 around 6:20 pm?
https://www.epochconverter.com/

Who sent the message?

 What table describes conversation
(threads)? number of messages stores only the content of a
conversation ID short message or messages read flag
multimedia message, the rest 0: unread
conversation of the content is indicated by
start date 1: has read
an ellipsis
The rest of rows in threads table
Investigate pdu table
• thread_id: Organizes messages into conversations. For example, all messages with thread_id 17 belong to
the same conversation.
• date: The timestamp when the message was sent or received, stored as a Unix epoch time (in milliseconds).
• msg_box: msg_box 1 are incoming MMS messages, and those with msg_box 2 are outgoing MMS messages.
• read: 0 = Unread.1 = Read.
• ct_t: content type of the message: Specifies the format of the MMS message.
application/vnd.wap.multipart.related indicates a multipart MMS message (e.g., containing text and media).
NULL values might indicate SMS messages or messages without a specified content type.
• ct_l: The content location, often a URL or reference to where the MMS content can be retrieved (e.g., from a
carrier’s server).
• m_type: The MMS message type. 128 = MMS notification (indicating an MMS is available to download).130 =
MMS delivery report.132 = MMS message (the actual message).
pri: The priority of the MMS message, as set by the sender or network. 129 = Low priority.130 = Normal
priority (default).131 = High priority.
st: The status of the MMS message, often used for MMS notifications to indicate the retrieval status.
seen: Indicates whether the message has been seen by the user (e.g., displayed in the messaging app).0 = Not
seen.1 = Seen.
text_only: Indicates whether the MMS message contains only text (no multimedia).0 = Contains multimedia
(e.g., images, videos).1 = Text only.
Investigate part table
Part of an MMS message
Which table contains MMS
information ?
links to the _id column in the pdu table

• Purpose: If an MMS contains a text message, an image, and a video, the part table will have
three rows—one for each component—linked to that MMS message.
• Part table stores the following:
• _id: Distinguish between different attachments of a multimedia message (including
text, picture, audio, video, and other formats)
• ct: indicates what type of attachment
• text: Represents the body of the MMS.
Reconstruct an MMS
message using pdu and
part tables
Approach to reconstruct an MMS
message
• Linkage: The part table is associated with the pdu table through the
mid column, which matches the _id column in the pdu table. Each
MMS message in the pdu table can have multiple parts in the part
table.
• Purpose: The pdu table stores the overall metadata of the MMS
message (e.g., timestamp, message type, status), while the part table
stores the individual components (e.g., text, SMIL) of that MMS
message.
Reconstruction steps
• Look up the MMS message in the pdu table (e.g., _id = 1).
• Find all parts in the part table with mid = 1.
• Use the seq column to order the parts (e.g., SMIL first, then text).
• Use the ct and text (or _data for media) columns to access the
content of each part.
Example: MMS message with _id =
1 in the pdu table
• The MMS message with _id = 1 in the pdu table has two parts (mid =
1 in the part table): a SMIL layout (row 1) and a text message "Here’s
Signal." (row 2). A messaging app would use the SMIL layout to
display the text in the correct format.
Summary
• Understand the application
• Locate the application package
• Look at the application directories
• Go to the "databases" directory
• Open mmssms.db
• Explore these tables: sms, threads, pdu, part
• Look at the data in each column and fetch the information you need
• Link pdu and part for reconstruct MMS messages