Quick Share is a wireless file transfer feature from Samsung and Google that allows users to quickly share files between devices via Wi-Fi and Bluetooth. First introduced as a Samsung-exclusive feature with the Galaxy S20, it was integrated with Google’s Nearby Share in January 2024 and has since become the standard sharing solution across the Android ecosystem, supporting not only Samsung devices but also other Android devices, Windows PCs, and Chromebooks.

Quick Share is also compatible with Apple’s AirDrop. Starting with the Pixel 10 series in November 2025, Google began rolling out two-way AirDrop compatibility to Android devices, and Samsung followed in March 2026 by officially adding AirDrop support to the Galaxy S26 series running One UI 8.5, beginning in South Korea.

As Quick Share expands its support across a wider range of devices and operating systems, its importance from a digital forensic perspective is increasing. Quick Share records are more than just a history of file transfers—they can act as key artifacts revealing a user’s send/receive activity and the connections between devices. Information on shared files, connected devices, and the use of the ‘Private Sharing’ feature can be particularly valuable for identifying data leaks, the movement of evidence, or the transfer of materials between accomplices.

This article explains how to share data with iOS and Android devices using the Quick Share feature, and the information that can be collected from an Android device after sending or receiving content via Quick Share. The findings are based on data extracted from an Android 16 device via MD-NEXT v2.2.14 and analyzed via MD-RED v4.0.12.

Table of Contents

• How to Use Quick Share
  • Sharing with Nearby Devices
  • Private Share
• Available Information from Mobile Devices
• Summary
• Appendix
  • Quick Share Receiving Settings
  • Supported File Types by Sharing Method
  • File Transfer Limits by Sharing Method

How to Use Quick Share

To share content using Quick Share, both the sending and receiving devices must have Wi-Fi and Bluetooth enabled, and devices must be located within nearby range. To share content with Galaxy devices, you must be signed into a Samsung account. To share content with non-Galaxy devices, a Google account sign-in is required.

Sharing with Nearby Devices

Sending Content

1. Select the content to share, then tap the Share button.
2. Tap the Quick Share button.
3. Select the user or device to share the content with. The available sharing targets may vary depending on the receiving device’s Nearby Sharing settings.

Receiving Content

When a Quick Share request is received, a sharing notification appears on the receiving device. The recipient can preview the type of content being shared and choose whether to ‘Accept’ or ‘Decline’ the request.

Private Share

Private Share is a secure sharing mode available between Galaxy devices. It allows the sender to set an expiration time for shared files. By default, the expiration period is set to 2 days, and it can be extended up to 6 days, 23 hours, and 59 minutes. Recipients cannot take screenshots, save, or reshare the shared content, and the files are automatically deleted after expiration.

Sending Content

1. Select the content to share, then tap [Turn on Private Sharing].
2. Set the expiration date, then select the user to share the content with. The available sharing targets may vary depending on the receiving device’s Nearby Sharing settings.

Receiving Content

When a Private Share request is received, a notification appears on the receiving device. The recipient can preview the type of content being shared and choose whether to ‘Accept’ or ‘Decline’ the request.

Available Information from Mobile Devices

The linkShare.db file stores records of files sent and received through Quick Share, the target devices involved in sharing, and the sharing timestamps. The privacy_library_database.db file stores records of content sent and received through the ‘Private Share’ feature.

The table below summarizes the information above.

Summary

1. Quick Share is a wireless file transfer feature jointly provided by Samsung and Google. It enables users to share data not only between Android devices, but also with devices running other operating systems, including Windows, iOS, and macOS. Support for iOS and macOS transfers is currently limited to certain devices and OS versions, but is gradually expanding.
2. Quick Share supports both Nearby Device Sharing and Private Share. Records of these sharing activities are stored in linkShare.db and the Private Share-specific privacy_library_database.db. Analyzing these records can reveal details about sent and received content, target devices, and sharing timestamps.

Appendix

Quick Share Receiving Settings

The available sharing targets may vary depending on the receiving device’s Quick Share settings.

• No one: No one can share content with the device.
• Contacts: Only users saved in Contacts through a Samsung account can share content with the device.
• Everyone: Anyone nearby can share content with the device.

For more information, please refer to https://www.samsung.com/us/support/answer/ANS10007268/.

Supported File Types by Sharing Method

Quick Share supports different file types depending on the sharing method.

• Sharing with nearby devices: No restrictions on shareable file types
• Sharing using QR code or contacts: Some file types are not supported, such as exe, com, bat, cmd, vbs, reg, msi, etc.
• Sharing using Private Share: The following file types are supported.
  • Image: jpeg, jpg, png, gif, bmp, webp, heic, dng
  • Video: webm, mp4, 3gp, 3g2, mkv
  • Audio: mp3, wav, ogg, m4a
  • Document: txt, pdf

File Transfer Limits by Sharing Method

Quick Share has different file count and size limits depending on the sharing method.

• Nearby device sharing: No restrictions on file count or total transfer size.
• QR code and contact sharing: Up to 1,000 files per transfer, with size limits of 10 GB per file and 10 GB per day.
• Private Sharing: Up to 20 files and 200 MB per transfer.

An OpenAI and NBER study found that nearly 80% of ChatGPT usage is centered on practical guidance, information seeking, and writing, with information seeking functioning much like web search. As search behavior shifts from keyword-based search to conversational AI, ChatGPT is becoming increasingly relevant in digital investigations. Because these interactions develop through natural-language dialogue, conversation histories can reveal not just what was searched, but how the user’s intent evolved, making them a valuable source of investigative insight.

This article focuses on ChatGPT as a leading generative AI application and addresses practical questions in a Q&A format. This article is based on findings extracted with MD-NEXT v2.2.13 from devices running Android 14, using Full Filesystem with MD-PLUG and Android Live extraction methods and analyzed via MD-RED v4.0.10.

Table of Contents

• App Data Storage Structure and Extraction
  • 1. Can I extract data through mobile forensics even though it is stored on the server?
  • 2. Do the available analysis results vary depending on the extraction method?
  • 3. How is the data stored?
  • 4. Can user-generated images or attached files be identified?
• Artifact Analysis by User Behavior
  • 5. Can I find conversation records created without logging in?
  • 6. Are all conversations synchronized after login?
  • 7. What range of data is stored when entering each chatroom?
  • 8. If a chatroom is deleted, can I still recover the data?
  • 9. If the user logs out from the device, does the data disappear?
  • 10. Can I find conversations from ‘Temporary Chat’?

App Data Storage Structure and Extraction

This section examines how ChatGPT app data is stored on Android device and available information for extraction.  

1. Can I extract data through mobile forensics even though it is stored on the server?

Yes. ChatGPT conversation records can be analysis through mobile forensic examination. When chat history is synchronized, the corresponding data is stored on the device, making the synchronized data recoverable through mobile forensic analysis.  

2. Do the available analysis results vary depending on the extraction method?

Yes. The available artifacts vary by the extraction method. The available results can be summarized as follows:

3. How is the data stored?

The data is stored in DB format under /data/com.openai.chatgpt/databases.

4. Can user-generated images or attached files be identified?

User-generated images are retained as cache files, which are stored at /data/com.openai.chatgpt/cache/coil3_disk_cache.

The filenames of attached files, including .pdf, .xml, and .doc, can be identified; however, the actual files cannot be analyzed.

Artifact Analysis by User Behavior

This section examines the data that can be identified based on ChatGPT usage scenarios.

5. Can I find conversation records created without logging in?

Yes. Conversation records will be stored on the device even without logging in. Because conversation records are stored in an SQLite database, chats conducted while not logged in are available for analysis.

6. Are all conversations synchronized after login?

No. Logging in automatically synchronizes only the 20 most recent conversations, and the contents are not synchronized unless each one is opened individually. To synchronize older chats, you must scroll through the chat list to trigger additional synchronization.

7. What range of data is stored when entering each chatroom?

When you enter a chatroom, the full text content is synchronized at once, and the entire conversation is recorded in the database. No additional scrolling is required after entering the chatroom to synchronize the data.

For image files, if the image has not been loaded on the device, the original file is not stored and therefore cannot be analyzed. If the image has been loaded properly, a cache file (coil3_disk_cache) is created, allowing the image to be analyzed.  

8. If a chatroom is deleted, can I still recover the data?

Yes, but only under limited conditions. When a chatroom is deleted, the related database records are marked as deleted. If those deleted records have not yet been cleaned up, the data may still be identified. However, once the deleted records have been cleaned up, data cannot be recovered.

9. If the user logs out from the device, does the data disappear?

Yes. When the user logs out, all conversation data (.db) stored on the device is deleted.

10. Can I find conversations from ‘Temporary Chat’?

No. Temporary chat conversations cannot be examined because they are not stored locally on the device and are not synchronized.

From iOS 8 and later versions, Apple has provided a built-in Health app that automatically tracks and stores a wide range of physical activities, including step count, distance traveled, heart rate, flights climbed, and workout records. Health app data is aggregated across all devices linked to the same Apple Account, including iPhone and Apple Watch. The physical activity and health data recorded in the Health app can serve as evidence to verify subject statements and reconstruct behavioral timelines during an investigation.

This article aims to introduce Apple’s Health app and the available information in the app. The findings are based on data extracted from iOS 26 device and watchOS 26 via MD-NEXT v2.2.13 and analyzed via MD-RED v4.0.10.

Table of Contents

• iOS Health App Overview
  • Types of Recorded Health Data
  • Data Recording Method
  • Health Data Sharing
• Available Information
  • Device Information & Data Entry Method
  • User Profile & Health Records
  • Shared Health Data from Other Users
• Summary

1.iOS Health App Overview

1.1. Types of Recorded Health Data

Data from all devices connected to the same Apple Account is aggregated in the Health app. When an Apple Watch is paired with an iPhone, step count and distance data are automatically recorded in the iOS Health app, without additional configuration. Tap the    icon in the bottom right corner of the app to see the categories of data that can be recorded in the Health app. For more details, refer to https://support.apple.com/guide/iphone/view-your-health-data-iphe3d379c32/26/ios/26

The table below summarizes the key data that may be recorded in iPhone and Apple Watch, and how they serve during investigation.

Data Recording Method

Health app data can be collected automatically through the sensors built into iPhone and Apple Watch, or input manually by the user. To manually input the data, follow the steps below.

1. Open the Health app and tap Steps.

2. Then tap the icon to manually input the data.
3. When finished, tap    icon to save.

Health Data Sharing

The health data sharing feature has been available since iOS 15 and watchOS 8. Sharing is limited to users who have added each other as contacts, and shared data is continuously synchronized.

Follow the steps below to share the health data. For more details, refer to the Apple support page https://support.apple.com/guide/iphone/view-your-health-data-iphe3d379c32/26/ios/26

1.In the Health app, go to the ‘Sharing’ tab.

2.Tap [Share with Someone].

3.Search for and select a person from the contacts list.

4.Select the health data categories to share, then tap [Share].

2.Available Information

2.1. Device Information & Data Entry Method

The healthdb.sqlite contains the device information, initial Health app setup timestamp, and manual and automatic data entry flag. Any manually input records may suggest potential data manipulation.

2.2 User Profile & Health Records

The healthdb_secure.sqlite file contains the user’s personal information, the start and end timestamps of health data recording, health data entries, and location records.

2.3 Shared Health Data from Other Users

Health data shared by another user is stored in /private/var/mobile/Library/Health/Profiles/{SharedAccoundInternalID}/.

The healthdb.sqlite and healthdb_secure.sqlite files at this path follow the same structure as the primary Health database. Records of health data sharing requests are stored in /private/var/mobile/Library/Health/Client/HealthApp.sqlite.

3.Summary

Text entered on a mobile device can be stored and managed by keyboard apps to improve features such as auto-completion and data learning. Therefore, not only messenger apps that contain large volumes of messages, but also keyboard apps that store keyboard text artifacts are forensically significant sources of evidence during investigations.

Text input methods on mobile devices vary by language. Some languages, such as English, allow direct text entry without conversion, while others require a conversion process before finalizing the input. Japanese is a prime example of the latter. Japanese users typically input text in romaji (Latin alphabet) or hiragana, then convert it to hiragana, katakana, or kanji and confirm their final input. For languages with conversion processes like Japanese, keyboard apps can retain various text input records, including initial input, suggested conversions, and final confirmed text.

This article aims to explore the available information from keyboard apps from Android and iOS, focusing primarily on Japanese input records. The findings are based on data extracted from Android 12.0 and iOS 16.7 devices via MD-NEXT v2.2.12 and analyzed via MD-RED v4.0.8.

Table of Contents

• Keyboard Input Process
• Available Information by Keyboard App
  • Android
    • Gboard
    • Wnn Keyboard Lab
    • Samsung Keyboard
    • Simeji Keyboard
  • iOS
    • Default Keyboard
    • Biome
  • Available Information by Keyboard App
• Summary

1.Keyboard Input Process

Japanese uses three writing systems, hiragana, katakana, and kanji. It is characterized by multiple kanji characters that share the same pronunciation but convey different meanings, as well as individual kanji that can be read in multiple ways. Because of these complexities, Japanese input requires users to first enter text in romaji or hiragana, then select from suggested words (to hiragana, katakana, or kanji) presented by the keyboard app to determine the final text.

2.Available Information by Keyboard App

2.1 Android

Gboard

Gboard is a keyboard app developed by Google that supports multiple languages and integrates features such as Google Translate and Google Search.

The input text records and the timestamp of entry are stored in the history.db file located under the /.mozc directory. Within this file, both the input text and the corresponding input timestamp are stored in an encrypted Protocol Buffer format.

Wnn Keyboard Lab

Wnn Keyboard Lab is a keyboard app installed on many Android devices manufactured by Japanese vendors. It stores input records using the OpenWnn structure, an open-source input framework developed by Japanese manufacturer Omron.

Text input records are stored in njuserl.a and njuserw.a files under the /files/discet/master directory.

Samsung Keyboard

Samsung Keyboard is the default keyboard app preinstalled on Samsung mobile devices. Similar to Wnn Keyboard Lab, Samsung Keyboard uses the OpenWnn structure, resulting in a similar data storage format. Japanese text input records are stored in njuserl.a and njuserl_uniq.a files under the /app_omrondb/dicset/master directory.

Simeji Keyboard

Simeji Keyboard is a third-party keyboard app that supports a wide range of emojis and theme customization features. Text input records are stored in the following locations.

• /database

• /file/dat

Text input content and the timestamp of the last input can be identified in the SimejiProvider.db file located under the /database directory.

In addition, plaintext records of input text and the package name of the application in which the text was entered are stored in the fcloud.dat file under the /files/dat directory. The dad_info.dat file, stored in the same path, records the time at which a text input field was displayed. These records may be created even when no text is entered, as long as a keyboard appears on the screen.

The following table summarizes the information above.

2.1 iOS

Default Keyboard

For the default keyboard built into the iPhone, keyboard input records are stored in plaintext in the following files under the /private/var/Mobile/Library/Keyboard directory.

• LexicalLearning_ja_JP.db

• DynamicPhraseLexicon_ja_JP.db

Biome

The Biome directory is known to store system logs such as user activity data, device usage information, application execution records, and Siri-related events. Text input records on iOS devices are also stored under the /private/var/mobile/Library/Biome.

Under the /restricted/Keyboard.TokenFrequency/local directory, numerically named file contains records saved by session. These data are serialized and stored in SEGB format.

Under the /public/TextInputSession/local directory, numerically named file stores keyboard usage logs, and the application package name. These data are serialized in SEGB format.

2.3 Available Information by Keyboard App

3.Summary

The ‘Recent Apps’ feature allows users to conveniently browse and relaunch recently used apps, and it has been available since Android 5.0 and later versions. Starting with Android 8.0, a new internal infrastructure called ‘task snapshots’ was introduced to store app screen captures and metadata displayed in the ‘Recent Apps’.

This article aims to introduce the ‘’Recent Apps’’ feature available on Android devices, and explain the concept of task snapshots, which save its traces. The findings are based on data extracted from the device with Android 11 using MD-NEXT v2.2.8, and analyzed with MD-RED v4.0.5

Table of Contents

• Recent Apps
  • Task Snapshot
• Available Information
  • Last Screen of the Recent App
  • Timestamp of Background Transition
  • Others
  • Summary of Available Information
• Summary

1.Recent Apps

Tap at the bottom-left of the home screen to access the ‘Recent Apps’. Swipe left or right to browse through the apps running in the background. You can reopen a specific app or swipe it upward to remove it from the ‘Recent Apps’. Up to 50 apps can be open in the background, and when the limit is exceeded, the oldest apps will be removed from the ‘Recent Apps’.

Learn more

1.1 Take Snapshot

A task snapshot is an internal Android infrastructure used to store the screen displayed in the ‘Recent Apps’ feature. It refers to the app screen when it is switched to the background. The app screen is saved in both high-resolution and low-resolution.

Learn more

2.Available Information

Under /system_ce/{User ID}/snapshots/, Android stores a set of three files for each screen displayed in the ‘Recent Apps’ list. If a user swipes an app away from the ‘Recent Apps’, the corresponding files are also deleted.

• {Task ID}. jpg

• {Task ID}_reduced.jpg

• {Task ID}.proto

The name of each file is assigned a unique numerical Task ID, and this ID increases sequentially according to the order in which apps transition to the background. Even if an app already shown in ‘Recent Apps’ is launched again and then switched back to the background, its previously assigned Task ID does not change.

2.1 Last Screen of the Recent App

You can identify the last screen displayed in a recent app from the two snapshot image files: {Task ID}.jpg and {Task ID}_reduced.jpg. The {Task ID}_reduced.jpg file is a lower-resolution version and has a smaller file size compared to {Task ID}.jpg

2.2 Timestamp of Background Transition

You can identify the timestamp of an app’s transition to the background in the {Task ID}.proto file, which stores the snapshot’s metadata. The modified, accessed, and changed timestamps (MAC Times) of the {Task ID}.proto file also reflect the moment when the app was switched to the background.

The modified and changed timestamp of {Task ID}.jpg and {Task ID}_reduced.jpg represent the timestamp when the app transitioned to the background. These timestamps are updated each time the app is switched to the background. The accessed timestamp of these files indicates the first time the app was transitioned to the background.

2.3 Others

The /system_ce/{User ID}/snapshots/ directory may also contain screens, such as alarm screens, Galaxy default app searches, network list screens, and others.

Meanwhile, the {Task ID}.xml files stored under /system_ce/{User ID}/recent_tasks/ provide a record of app usage history that complements the snapshot artifacts.

2.4 Summary of Available Information

3.Summary

1. Android devices provide a ‘Recent Apps’ feature that allows users to view recently used apps and relaunch them easily.

2. Task snapshots serve as Android’s internal infrastructure for storing the screens and metadata of recently used apps.

3. For each screen shown in the ‘Recent Apps’, a set of three files, {task ID}.jpg, {task ID}_reduced.jpg, and {task ID}.proto, is stored under /system_ce/{User ID}/snapshots/.

4. The {task ID}.jpg and {task ID}_reduced.jpg files contain the last displayed screen of the app. The modified and changed timestamps indicate the moment the app transitioned to the background, while the accessed time reflects the first time the app transitioned to the background.

5. The {Task ID}.proto file records metadata, including the timestamp of the background transition. Its modified, accessed, and changed timestamps also correspond to the time the app was transitioned to the background.

6. In addition to recent app screens, this directory may also contain images such as alarm screens or other system-generated snapshots. App usage history can be found in the {Task ID}.xml file stored under /system_ce/{User ID}/recent_tasks/.

There is suspicion that the subject participated in criminal activity through a hotspot connection. Is it possible to verify the device’s hotspot connection activity through mobile forensic analysis?

Hotspot connections represent more than simple network activity. They can serve as evidence that two devices were in close physical proximity.

iOS hotspot feature requires manual authentication for the initial connection, but automatically reconnects when the same device comes within range thereafter. This means the presence of automatic connection records indicates that the user previously entered the password manually, and suggests the possibility that both devices were used together in the same location at the time of an incident.

This article aims to explain how to connect to a personal hotspot on iOS devices and provide key information available to identify the connection history. The findings are based on the data extracted from iOS 16.7 device using MD-NEXT v2.2.8 and analyzed via MD-RED v4.0.4.

Table of Contents

• How to Set Up a Personal Hotspot
  • Hotspot Providing Device
  • Hotspot Receiving Device
• Hotspot Connection History on Receiving Device (A)
  • Case 1: Device A connects to Device B’s hotspot (1st session)
  • Case 2: Device A disconnects from the hotspot (1st session)
  • Case 3: Device A reconnects to Device B’s hotspot (2nd session)
  • Case 4: Device A disconnects from the hotspot (2nd session)
  • Case 5: Device A connects and disconnects from the hotspot (multiple times)
• Summary of Available Information
• Appendix: Information Available on Providing Device (B)
• Summary

1.How to Set Up a Personal Hotspot

When a Wi-Fi network is unavailable, you can share your iPhone’s cellular data connection by enabling a Personal Hotspot. To enable a hotspot, configure devices as follows.

Learn more

1.1 Hotspot Providing Device

Go to ‘Settings’ > ‘Personal Hotspot’ or ‘Settings’ > ‘Cellular’ > ‘Personal Hotspot’ and enable ‘Allow Others to Join’ option. To use this hotspot, other users must enter the password set in the providing device.

1.2 Hotspot Receiving Device

Go to ‘Settings’ > ‘Wi-Fi’ and select a personal hotspot of Device B. A personal hotspot is displayed with the icon next to it. If a personal hotspot is successfully connected, the icon is displayed on the top-right corner of the device screen.

2.Hotspot Connection History on Receiving Device (A)

The hotspot connection history on the receiving device is stored in the following source files:

• /private/var/preferences/com.apple.wifi.known-networks.plist

• /private/var/preferences/SystemConfiguration/com.apple.wifi-private-mac-networks.plist

• /var/mobile/Library/Preferences/com.apple.networkserviceproxy.plist

The following information is available in the fils : 

• Start timestamp of initial connection

• Start timestamp of automatic an manual hotspot connection

• Start timestamp of the nth connection

• Start/end timestamp of the last connection

The following sections describe typical scenarios in which this information can be identified and analyzed. Device A refers to the device that received the hotspot connection, and Device B refers to the device that provided it.

2.1 Case 1 : Device A Connects to Device B’s hotspot (1st session)

This scenario is when Device A connects to Device B’s personal hotspot. If it is the initial connection, the password set on the providing Device B is required to enable the connection.

The following information is available :

• The AddedAt key in the com.apple.wifi.known-networks.plist file and the AddedAt key in the com.apple.wifi-private-mac-networks.plist file record the timestamp when the hotspot was initially connected.

• The NSPServiceStatusMAnagerInfo key in the com.apple.networkserviceproxy.plist file contains blob-processed Plist data with detailed hotspot connection information. In each NS.time key, under PrivacyProxyNetworkStatusTimeNetworkStartTime andPrivacyProxyNetworkStatusTimeNetworkEndTime keys, you cna find the timestamp the hotspot was connected and disconnected. The timestamp is recorded in CFAbsoluteTime format.

The following table summarizes the information above.

2.2 Case 2 : Device A Connects from the hotspot (1st session)

In this case, Device A loses its connection to Device B’s hotpot. Hotspot connections can be lost when :

• The user manually disconnects from the hotspot.

• The device switches to a different Wi-Fi network.

• The device moves too far from the hotspot providing device.

• The hotspot provider changes the hotspot password.

When a connection is terminated, the end timestamp can be found in the com.apple.networkserviceproxy.plist file.

2.3 Case 3 : Device A Connects to Device B’s hotspot (2nd session)

In this case, Device A temporarily loses connection and then reconnects to Device B’s hotspot. There are two possible reconnection scenarios.

• Automatic connection: The device automatically reconnects when it comes within range of the hotspot. For this condition, the providing device must not have changed the password, and the ‘Allow Others to Join’ option must be enabled.

• Manual connection: The user actively selects and reconnects to the hotspot. Since the password was saved during the first connection, re-authentication is not required.

The JoinedBySystemAt key within the com.apple.wifi.known-networks.plist file records the start timestamp of the automatic connection. Upon manual reconnection, the JoinedByUserAt key is updated with the corresponding start timestmap of connection.

The lastJoined key in the com.apple.wifi-private-mac-networks.plist file records the start timestamp of the last connection, updating with each session (2nd, 3rd, nth session).

The table below summarizes the information above.

2.4 Case 4 : Device A disconnects from the hotspot (2nd session)

In this case, the device disconnects from the hotspot after having successfully reconnected. To determine when the hotspot connection was terminated, refer to UpdatedAt key in com.apple.wifi.known-networks.plist file and lastUpdated key in com.apple.sifi-private-mac-networks.plist file.

2.5 Case 5 : Device A disconnects from the hotspot (multiple times)

In this case, the device repeatedly connects to and disconnects from the hotspot. In each session, the same information described in Case 3: Device A reconnects to Device B’s hotspot (2nd session) can be found.

When hotspot connections and disconnections occur two or more times, the start and end timestamps for all sessions except the last one are recorded in the NS.timekey under the
PrivacyProxyNetworkStatusTimeNetworkStartTime and PrivacyProxyNetworkStatusTimeNetworkEndTime keys in the com.apple.networkserviceproxy.plist file.

For example, if four sessions occurred, the start and end timestmaps for sessions 1 through 3 can be identified in the source file. While the las (4th) session’s connection start and end timestmaps cannot be verified, you can refer to the recording of previous connection and disconnection timestamps to trace hotspot connection history.

The table below summarized the information above.

3. Summary of Available Information

4.Appendix: Information Available on Providing Device (B)

The device that provided the hotspot also stores records of hotspot connection activity.If deleted records are present in the ZTIMESTMAP key of the ZPROCESS table in the /private/var/wireless/Library/Databases/DataUsage.sqlite file, it suggest that the hotspot provider enabled the ‘Allow Others to Join’ option.

5.Summary

• • Hotspot connection records suggest the physical proximity of the providing and receiving devices.

• • Connecting to a hotspot requires entering the hotspot password on the initial connection. If a device automatically connects to a specific hotspot, it suggests a prior connection between the two devices.

• • On the receiving device, hotspot connection records are found in the following source files

  •   ◦ com.apple.wifi.known-networks.plist

  •   ◦ com.apple.wifi-private-mac-networks.plist

  •   ◦ com.apple.networkserviceproxy.plist

• • On the providing device, if deleted records of the ZTIMESTMAP key in the ZPROCESS table of the DataUsage.sqlite file exist, it indicates that a hotspot connection occurred.