Run an investigation, start to finish

Before you begin

Atlas is intended for authorized forensic examination of devices, backups, and acquired evidence. Obtain the appropriate legal authority, consent, or organizational authorization before acquiring or examining data. Preserve original evidence and work from forensic copies whenever the case procedure requires it.

What’s New in This Revision

This revision brings the guide in line with the current Atlas build (application version 0.1.0). The table lists what is new or changed and where it is described. A case processed by an earlier build must be re-processed to populate the newer views (see section 8).

1. Product Overview

Atlas is a case-oriented WhatsApp forensic analysis application. It creates or opens a case workspace, acquires or imports WhatsApp data, normalizes platform-specific databases into an analysis model, calculates forensic analytics, performs integrity checks, and presents the results through an interactive analytics interface.

Core capabilities

Typical workflow

Case → Platform → Acquire/Import → Review detected inputs → Parse → Analyze → Investigate → Export/Report → Preserve case.

2. Installation and First Launch

2.1 Installer requirements

2.2 Installing Atlas

1. Run AtlasSetup-<version>.exe.

2. Accept the installer prompts and allow the requested Windows administrator elevation.

3. Choose the optional desktop shortcut if desired. The shortcut is not selected by default in the installer configuration.

4. Complete installation. Atlas is installed under Program Files.

5. Optionally enable “Launch Atlas now” on the final installer screen.

2.3 First launch

On first launch, Atlas checks its license state. If no usable license is present, the activation dialog requests a license key in the ATLAS-XXXX-XXXX-XXXX-XXXX format.

2.4 Installation/upgrade behavior

The installer can replace an existing Atlas installation. Close Atlas before upgrading. The installer removes the previous installed application tree before copying the new release so stale binaries do not remain.

3. Licensing and Activation

Atlas uses a license-based activation system. A license is associated with the machine and the license service. The application performs license checks at important checkpoints, including device extraction and case access.

Activate a license

1. Start Atlas.

2. When the Activate Atlas dialog appears, enter the license key provided by your organization/vendor.

3. Select the activation action and wait for confirmation.

4. If activation succeeds, continue to the Case Wizard.

5. If activation is rejected, verify that the key is correct and that it has not already been activated on another machine.

Common license messages

4. Case Creation

The Case Wizard is the starting point for examination. The case folder becomes the working location for the case's analytics and outputs.

4.1 Create a case

1. On the Case Wizard page, select Browse… beside Case folder.

2. Select an existing folder or create/select a dedicated case folder.

3. Enter Case name. Example: “John Doe WhatsApp”.

4. Enter Case number / ID. Example: “CASE-2026-001”.

5. Choose the Time zone for this case. The default is India (IST).

6. Select Continue.

4.2 Case folder recommendations

• Use one dedicated folder per forensic case.

• Do not use the Windows Program Files installation folder as a case folder.

• Use a storage location with adequate capacity and controlled access.

• Keep original evidence in a separate evidence repository; use acquired/working copies for processing.

• Do not manually rename or remove Atlas-generated case files while the case is open.

4.3 Platform selection

The platform page presents Android and iOS cards. Select the platform matching the source evidence. Atlas then asks whether you want to extract from a connected device or proceed with an existing acquisition/backup.

5. Choosing Android or iOS

6. Android Workflow

6.1 Live Android extraction

When Android is selected, Atlas can pull WhatsApp data from a connected Android device using ADB. USB and Wi-Fi devices are treated as ADB devices once connected.

1. Connect the Android device and enable the required USB/Wireless Debugging functions according to your examination procedure.

2. Select Android and answer Yes to “Extract from device?”.

3. Atlas checks for ADB and lists detected devices.

4. If multiple devices are present, select the correct device and choose Use selected device.

5. For an unauthorized device, unlock it and accept the “Allow USB debugging?” prompt, then Retry.

6. Leave “Attempt root/run-as internal-data recovery (decryption key, contacts)” enabled when your authorized workflow permits it.

7. Wait for extraction to complete. Review warnings in the extraction dialog.

8. Choose Continue. Atlas uses the extracted data to pre-fill the Android case fields.

6.2 Android Wi-Fi acquisition

The Android extraction dialog provides three network options:

• Switch selected USB device to Wi-Fi — changes an already connected USB device into an ADB-over-network connection.

• Connect — connect to an Android device whose wireless debugging endpoint is already available. Enter the device IP and port.

• Pair — for Android 11+ wireless debugging, enter the pairing IP, pairing port, and six-digit pairing code shown by the device.

6.3 Manual Android acquisition

The Android case setup supports an acquisition folder or ZIP. If selected, Atlas searches the tree for relevant WhatsApp structures and automatically fills detected fields.

6.4 Multi-DB mode

Enable “Multi-DB mode” when the acquisition folder contains multiple msgstore snapshots and you want Atlas to compare them. Atlas searches for the live database and every historical encrypted snapshot, such as msgstore-YYYY-MM-DD.N.db.crypt1x. If only one database is found, Atlas behaves like a normal single-database run.

• The newest snapshot becomes the main analysis case. It receives the normal analytics, case report and HTML chat export.

• Each older snapshot is processed as its own independent case under multi_db\<label>\, so it can also be reviewed on its own.

• Older snapshots are compared against the newest snapshot. Chats, messages, edited or revoked messages, media and document references present in an older snapshot but absent from the newest are surfaced as deletion-related evidence.

• Whole deleted chats are recovered as HTML, using the same exporter as a normal run, under multi_db\deleted_chats\index.html (see 12.6).

• Incremental backups found in the acquisition folder are decoded and used to confirm and date deletions (see 6.5).

• Findings are added to the Integrity view and the case report. A standalone deletion report is written under reports\multi_db_deletion_report.json.

6.5 Incremental backups

WhatsApp on Android also writes small daily incremental backups, named like msgstore-increment-N-YYYY-MM-DD.S.db.crypt14. An incremental backup is not a database. Once decrypted it is an archive of changes: it records that a message was removed or edited, and when, but not what the message said. Atlas decodes these backups and, where possible, recovers the text from an older full snapshot or an earlier increment.

1. Place the increment files in the acquisition folder, or next to the encrypted backup. Already-decrypted increment ZIP archives are also accepted.

2. Provide the key as usual. The same key file or 64-character hexadecimal key is used to decrypt the increments.

3. Run the Android parse, with or without Multi-DB mode. Increments are recognised by file name and kept out of the main/older snapshot ranking.

4. Open the Deleted Msg tab and review the Incremental backups panel (see 9.11).

6.6 Run Android Parse

1. Review the auto-filled backup/key/media fields.

2. Select Multi-DB mode if historical snapshot comparison is required.

3. Select Skip OCR only if scanned or photographed PDFs do not need to be searchable.

4. Optionally provide a custom HTML template.

5. Select Run Android Parse.

6. Monitor the progress bar and Run log.

7. Wait for completion before opening the analytics workspace.

7. iOS Workflow

7.1 Live iOS extraction

The live iOS workflow takes a full device backup through the iOS acquisition component and then extracts the WhatsApp data needed for analysis. It is not a WhatsApp-only device backup operation.

1. Connect the iPhone/iPad by USB and unlock it.

2. Select iOS and answer Yes to “Extract from device?”.

3. If the device asks “Trust This Computer?”, tap Trust and enter the device passcode.

4. If multiple devices are detected, select the correct UDID and choose Use selected device.

5. Optionally enable WhatsApp Business if the target data is from WhatsApp Business.

6. If the backup is encrypted, enter the backup password in the password field.

7. Allow the full backup to complete. Keep the device connected and unlocked as required.

8. Select Continue after a successful backup.

7.2 Manual iOS backup

7.3 Run iOS Parse

1. Select the backup folder or use the folder populated by live extraction.

2. Enter the backup password if the backup is encrypted.

3. Optionally provide a person name and custom HTML template.

4. Select Skip OCR only if scanned or photographed PDFs do not need to be searchable.

5. Select Run iOS Parse.

6. Monitor the progress and Run log.

7. After completion, open the analytics workspace to review the case.

7.4 iOS call-history caveat

On iOS, Atlas can enrich the Calls view from Apple's system CallHistory.storedata. This is system-level call activity associated with CallKit-capable apps, not a WhatsApp-only call database. Where WhatsApp contact resolution is unavailable, the UI may fall back to a raw phone number/handle.

8. Analytics Workspace

After successful parsing, Atlas opens a case analytics workspace. The navigation is organized around investigation tasks. Most views can be scoped to a focused chat and/or date range where supported. Some tabs are populated only when the source data supports them; each says so when it is empty.

8.1 Date-range filtering

Several views respond to the case timeline/date-range selection. Use a narrow date range when examining a specific incident, then return to the full case range for context. Views such as Groups, Contacts and Integrity may include case-wide information that is not constrained in the same way as message-centric views.

8.2 Focused chat

Selecting a chat can focus Content, Locations, Links & Mentions, Media, Calls and Signals on that conversation. Use “All chats” where available to return to a case-wide view.

8.3 Case time zone

All dates and times in analytics, reports and chat exports are displayed in the time zone selected when the case was created. The zone is fixed for the life of the case. Stored evidence timestamps remain in UTC, so a different examiner can still reconstruct the original values. State the case time zone whenever you quote a time from Atlas.

9. Investigative Views

9.1 Overview

Use Overview as the initial orientation screen. Review the case metadata, message and chat volume, the activity timeline, media present/missing counts, top contacts and integrity findings before drilling into individual chats. Overview also holds the date-range selector and the Generate report control (see section 11).

9.2 Chats and the Chat Details window

Use Chats to locate conversations by name or JID. Each row shows message and media counts, first and last activity and a status. Select a row to see that chat’s activity ribbon. Open chat opens the Chat Details window; Export… saves the chat’s HTML and media to a folder.

Chat Details window. Details are on the left and the chat’s exported HTML is on the right, in the same window. The left side has three tabs: Overview, Message provenance and Device timeline.

Message provenance (Android). Search and filter the chat’s messages. Selecting a message shows the sending device (number, primary or linked, identity); the device, server and received times with a neutral verdict; delivered, read and played status for each recipient; per-device delivery acknowledgements; edit and revoke events; and the media hashes (as sent, original and encrypted) with an on-demand “Verify against file on disk”. Show in chat scrolls to and highlights the message in the right-hand pane.

Device timeline. Shows the first and last message seen from each device number for each person, compared with the cached device list, as a lifeline chart. When the list carries no refresh date, Atlas infers the windows in which it can have been refreshed from the devices seen.

9.3 Content

Content provides the message-type breakdown, reaction emoji frequency, reactions given and received by contact, forwarded messages ranked by forward score, and polls. Use the chat selector to scope the view to one conversation.

9.4 Media

Media lists every image, video, audio or voice note, document, sticker and GIF in the case. Narrow the list with the kind tabs (which show counts), the chat selector, the sent/received filter, the filename/caption search, the sort order and the Grid/List toggle. Load more pages through large cases, and the left and right arrow keys step through items.

• The All / Missing only / Deleted (Multi-DB) toggle shows every item, only items whose file is missing from the case, or, when a Multi-DB comparison exists, media referenced only by older snapshots.

• The recovery status filter and the Recovery sources panel match missing media to extra evidence (see section 13).

• Selecting an item shows a preview and its details, including how the file was located on this machine and a flag if the recorded size differs from the file on disk. A ×N badge marks a file attached to several messages, with Open there links for the other chats.

• Open chat at this media opens the chat’s exported HTML in an in-app window, scrolled to and highlighting the exact message. In browser opens the same page in the default browser, which may ignore the message anchor and cannot highlight it.

• Open file works only for a list of safe types (images, audio, video, PDF and common Office and text files). Other types can only be shown in their folder. Opening a PDF or Office file hands the evidence to the operating system’s default application.

• Video and audio preview depends on the codecs available. If a file will not play, use Open file or Show in folder.

9.5 Groups

Groups ranks every group by roster churn (joins plus leaves and removals). Select a group to see its roster timeline, including past participants who left.

9.6 Calls

Calls is built from the Android call log. It shows KPIs (including missed calls), the busiest days, a leaderboard of one-to-one calls by contact, every group call with its own participant roster, and the complete call log. The log can be filtered by All, Incoming, Outgoing, Missed and Video. Export CSV writes every call in the case, regardless of the on-screen filter.

• Outgoing is any call placed from the device, whether or not it connected.

• Missed is an incoming call that never connected.

• Connected or Not connected is decided from the call duration (a duration above zero means connected). WhatsApp’s own call_result code is shown alongside it but is not interpreted, because there is no documented mapping of its values.

• The by-contact leaderboard covers one-to-one calls only. Group calls are listed separately, each with its participants.

9.7 Signals

Signals lists the chats where disappearing messages are currently enabled and the view-once media found in the case.

9.8 Links & Mentions

Review the domains shared, recent links and the mention leaderboard, then pivot back to the relevant chat and message. On iOS, mention rows come from shared contact-card matches rather than live @-mentions in message text.

9.9 Locations & Timeline

Use the chat selector and date range to constrain the view. Three sub-tabs are available.

Shared locations. A map of location-share messages (amber for sent by me, blue for received). Hover a point for the chat, time, coordinates and place name; click it to open the chat. Below the map, Frequent places groups repeated shares within roughly 100–150 m, and All shares lists the most recent shares (up to 500).

Live-location paths. Joins live-location shares into paths on a map, with one-shot pins shown separately. A table lists each path and notes explain how it was built. The view follows the focused chat and date range.

Combined case timeline. Merges calls, deletions and edits, confirmed system events and locations into a single list, with “notable windows” highlighted. Filter by event kind, optionally include routine security notices or unnamed system codes, choose the sort order, and use Show more to page through the list.

9.10 Contacts & Map

Contacts lists every contact by message volume; selecting one focuses the dashboard on that chat. The correlation map shows shared group membership and correlated activity patterns, with line thickness showing strength. Search for a person, drag nodes, click a node to pin it and trace its connections, and scroll to zoom; Reset layout restores the default. The Block / unblock timeline lists block events. Correlation edges are analytical relationships, not proof of identity or intent.

9.11 Deleted Msg

Deleted Msg gathers deletion evidence recovered by Multi-DB comparison and by incremental backups. If the case holds no such findings, the tab says so and explains how to produce them: run Multi-DB mode on the acquisition folder and include the incremental backups.

The main list has tabs for All, Deleted chats, Deleted messages, Revoked (recovered), Modified, Media and Documents. Search by name, number, chat id or message text; tick Resolved identities only or Confirmed by incremental backup to narrow the list; sort newest or oldest first; Load more pages through long lists. A Deletion windows panel shows the time windows derived from the snapshots and backups.

The Incremental backups panel lists deletions recorded day by day. Below it, “What the backups recorded, message by message” has four tabs: Edits & deletions, Added / updated messages, Group leaves and Calls. The panel appears even when Multi-DB mode was not used.

9.12 Activity

Activity looks beyond one-to-one chats. Communication classes separates people, groups, channels, Meta AI and bots, status/broadcast and other traffic. Business & Meta AI messages lists messages tagged as business templates, business notices or Meta AI. Payments and Channels list that content where present.

• Payments keep WhatsApp’s raw status and type codes and are not interpreted. Credential ids, payment methods, bank transaction ids and free-form payment metadata are never imported.

• Existing statistics are not changed. Overview and KPI figures still count every chat; channels and bots are separated only in this view and in the report.

9.13 Identity

Identity assembles a change timeline for the people and groups in the case: phone-number changes and histories (including numbers that changed back), links between @lid identifiers and phone numbers, masked-number names, push and saved names, usernames, old group names, group icon changes (with the old and new thumbnails), the admin roster and role-change events. Search by name, number, group or username, filter by event kind and choose the sort order.

• Group-name changes store only the old name. The new name is derived (from the next change, or the current subject) and is marked as derived.

• Admin promotion dates are not stored. Role changes are shown as a raw code with the target’s current role.

• Only system codes confirmed against detail tables are named. Unnamed codes are hidden by default in the timeline views.

• Real push names come from the contacts database (wa.db) when it is supplied; otherwise only masked numbers may be available.

9.14 Fraud pack

Fraud pack collects indicators that may help a reviewer: payments, suspicious-flagged media, heavily forwarded content (and the same content in several chats), business and template messages (one-time-passcode text is masked) and the foreign-number mix. Two controls adjust it: Heavily forwarded from score (default 4) and Home country prefix (automatic unless you enter one), then Apply.

9.15 Integrity

Integrity is the principal evidence-quality review area. Examine media completeness, integrity findings, deleted-chat/deletion-related signals and any warnings before drawing conclusions. When a Multi-DB comparison exists, a panel summarises deleted chats and messages across snapshots, with a button to open the Deleted Msg tab. The deleted-chat and anti-forensic section is Android-only bookkeeping that can survive a chat being deleted on the device; it is empty on iOS cases by design.

10. Search and Document Search

10.1 Message keyword search

1. Open Search.

2. Enter a keyword or phrase in Search message text.

3. Optionally select a chat.

4. Set From/To dates when a time window is required.

5. Run the search.

6. Review matching messages and use the available open/export actions to preserve relevant context.

10.2 Document search

Atlas can search text extracted from document attachments. PDFs with a text layer can be searched directly; where a PDF lacks a usable text layer, Atlas can OCR the document to make text searchable.

OCR uses Tesseract. If Tesseract is not found when Atlas starts, a warning explains how to install it and offers Locate tesseract.exe… for a non-standard location; OCR then applies to cases processed afterwards. Selecting Skip OCR on the setup page bypasses OCR entirely (text-based PDFs are still indexed). The Search page can show a banner describing the OCR status of the case.

1. Open Search → Document search.

2. Enter a document-text query.

3. Select Search.

4. Review matching documents and associated chat context.

5. Use Export documents + chats… when you need an examination bundle.

10.3 Export search results

Search results can be exported with Export all matching chats… (message search) or Export documents + chats… (document search). Exported bundles are intended to preserve useful context and associated media/documents rather than replacing the original forensic evidence.

11. Reports and Exports

11.1 Automatic case report

After a normal Android or iOS analysis run, Atlas can generate a latest.wareport.html and latest.wareport.json report in the case reports directory. The report contains case/environment information, evidence metadata, methodology/results, discrepancies/integrity findings and a conclusion section.

11.2 Interactive report generation

On the Overview tab, set an optional date range, choose HTML or PDF and select Generate report. A Report options dialog then lets you choose the summary level, which media to include and an optional company logo. The report follows the focused chat and date range.

Newer builds add report sections for call activity, media recovery by hash, communication classes and payments, the identity and change timeline, the fraud pack, live-location paths (with a path map) and the combined case timeline. Short summaries include only the notable-window events of the timeline.

11.3 Chat export

Chat export can bundle a conversation's HTML representation with associated media. This is useful for sharing a self-contained review package while preserving the underlying case separately.

11.4 Calls CSV

The Calls view provides an Export CSV action that writes every call in the case, ignoring the on-screen filter. Preserve the exported CSV as a derived artifact and document its relationship to the source case.

11.5 Export discipline

• Do not edit an exported report and represent it as an original Atlas-generated artifact.

• Record the export date/time and examiner in your case notes.

• Retain the original case workspace separately from distributed report copies.

• When a report is provided to a third party, include the relevant attachments/media bundle where required.

• State the case time zone whenever you quote times from an export.

12. Integrity and Deletion Analysis

12.1 Input hashing

Atlas calculates SHA-256 hashes for important normalized input database artifacts and records them in the case manifest. These hashes help detect changes to processed inputs between runs.

12.2 Integrity findings

The Integrity view collects discrepancies and evidence-quality findings detected during normalization and analytics. Findings can relate to database/media inconsistencies, missing attachments and other conditions that affect interpretation.

12.3 Media completeness

Atlas compares message/media references with files that can be resolved in the case workspace. A high missing-media count does not automatically prove deletion; it can also result from an incomplete acquisition, unavailable external media, path differences or source-tool limitations. Where media is missing, section 13 describes how to attempt recovery by hash.

12.4 Android multi-DB deletion analysis

When multiple msgstore snapshots are available, Atlas can compare older snapshots with the newest snapshot. Records that existed in older snapshots but are not present in the newest snapshot are surfaced as deletion-related evidence.

12.5 Incremental backup findings

Incremental backups (see 6.5) record changes rather than content, so they are interpreted differently from full snapshots.

12.6 Recovered deleted chats

In Multi-DB mode Atlas renders each whole deleted chat as HTML, using the same exporter as a normal run and reading from the newest older snapshot that still contains the chat. The results are written under multi_db\deleted_chats\, with an index.html that lists every recovered chat. Only the attachments that the recovered chats reference are copied alongside them.

13. Media Recovery by Hash

A chat can reference an attachment whose file is not in the case. Media recovery matches such items to files in extra, read-only evidence sources by the SHA-256 value WhatsApp stored for the attachment. It is optional, and it applies to Android cases (the iOS media table carries no hash columns).

13.1 Add recovery sources and match

1. Open the Media tab and select Recovery sources.

2. Select Add folder… or Add zip… for each extra evidence source, for example a second acquisition or a media folder produced by another tool. ZIP files are never extracted.

3. Select Index & match. Atlas hashes the files in the sources and compares them with the stored hash of every missing item.

4. Review the summary and the coverage table, then use the recovery status filter on the Media tab to inspect the results.

• Sources are read-only. A matched file is referenced in place and is not copied into the case.

• Files are hashed as a stream, with a size pre-filter. Cancel keeps a valid partial index, and re-running reuses files that have not changed.

• A match means an identical SHA-256. Several files can match one item, and one file can match several items; both are recorded.

• Identical file in this case needs no extra source: a missing item is matched to another message’s file with the same stored hash, but only after that file’s actual bytes are hashed and equal the stored value. It ranks below a match from an external source.

13.2 Recovery statuses

13.3 Optional re-download from WhatsApp

For an item that carries the data a download needs, the item details offer Try re-download from WhatsApp…. Atlas asks for confirmation first (the default answer is No), because this contacts a WhatsApp server. Nothing is contacted unless you ask for it.

• Atlas checks the downloaded data against the stored encrypted-file hash and its message authentication code, then checks the decrypted file against the stored file hash. Only a file that passes every check is saved, under recovered_media\cdn_download\ in the case folder.

• Server refusals (403, 404, 410) and network failures are normal results, because WhatsApp removes media after a time. They are reported, not treated as errors.

• Every attempt is recorded in an audit table. The media key is held separately from the media table and is never written to logs, reports or the interface.

• If an item cannot be re-downloaded the details say why.

13.4 Coverage and reporting

The Recovery sources panel includes a coverage table: missing media per month (in the case time zone) and per file type, split into recovered, thumbnail only and missing, with a count of unrecovered items that could be re-downloaded. The case report gains a “Media recovery by hash” section giving the number checked, matched, unmatched and thumbnail only, with the sources used and their file counts.

14. Case Files and Output Structure

A typical case workspace contains Atlas-managed metadata, analysis data, reports and chat/export material. Exact contents vary by platform, acquisition type and release.

Do not manually delete protected case files

Atlas uses an encrypted analysis database and licensing/case-key workflow. Do not copy only individual internal case database files and expect them to open independently. Preserve the case folder as a unit.

15. Evidence, Security and Privacy

15.1 Case data protection

Atlas protects the analysis database at rest using a server-issued case key. The application keeps the active case key in memory during a case session rather than treating a local plaintext key file as the authoritative long-term storage mechanism.

15.2 Licensing data

The application's per-user license data is stored outside the Program Files installation directory. The installer does not remove this license data during ordinary uninstall, allowing a later reinstall to reuse the activation state where the license remains valid.

15.3 Sensitive evidence

• Treat WhatsApp content, attachments, locations, contacts and call information as sensitive personal data.

• Restrict case-folder permissions to authorized examiners.

• Avoid placing case data in consumer-synced folders unless permitted by your evidence-handling policy.

• Do not include passwords, decryption keys or device passcodes in general-purpose report distributions.

• Keep a record of who accessed/exported the case.

15.4 Originals and working copies

Atlas should normally operate on an acquired copy. If your laboratory procedure requires a pristine original image, mount or copy it according to the laboratory's validated workflow rather than allowing Atlas to modify the original.

15.5 Network activity

Atlas processes evidence locally. It uses the network only in these cases:

• License activation and license/case-key verification.

• The Locations & Timeline maps load the Leaflet map library and OpenStreetMap tiles online, and place names are looked up with the Nominatim geocoding service, which means coordinates from the case are sent to that service.

• Media re-download contacts a WhatsApp server, and only after you confirm it (see 13.3).

16. Troubleshooting

16.1 Capture useful troubleshooting information

• Atlas version/installer version

• Windows version

• Android/iOS device model and OS version, where relevant

• Case ID

• Exact operation being performed

• The visible Run log/error message

• Whether the problem occurs with another known-good acquisition

• Case time zone and whether the case was processed by an earlier build

17. Recommended Examination Procedure

Minimum examination notes

18. Limitations and Platform Notes

Android

• Successful WhatsApp decryption depends on obtaining the correct backup/key material and on the source acquisition containing the relevant files.

• ADB access does not automatically guarantee access to protected application data. The live extractor attempts supported recovery paths and reports what it can obtain.

• Media analysis depends on the external WhatsApp/Media content being acquired.

• Multi-DB comparisons depend on having multiple usable snapshots.

• Incremental backups record that a message was removed or edited, not its original text. Text is recoverable only from older snapshots or earlier increments.

• Message provenance, the device timeline, payments and most deletion indicators come from Android-only tables.

• Media recovery by hash depends on the stored hash values and on the extra evidence you supply.

iOS

• Live acquisition creates a full device backup rather than a WhatsApp-only backup.

• Encrypted iOS backups require the correct backup password.

• iOS call records come from the system CallHistory.storedata and should not automatically be treated as WhatsApp-only calls.

• Some contact/call resolution is best-effort and can fall back to raw phone numbers/handles.

• iOS stores no sending device and keeps receipts in a format Atlas does not decode, so there is no message provenance.

• The WhatsApp iOS database holds no call history and no media hashes for recovery; iOS revoked-message and system-event tables are not modelled, so iOS deletions and system events are absent from the timeline.

Analytics

• Correlation graphs represent analytical relationships such as shared groups or temporal activity; they are not identity attribution.

• Location maps represent location records present in the acquired dataset; absence of a location is not evidence that the device was never at a location.

• OCR text is derived data and should be validated against the source document.

• Missing media can have several causes and must be interpreted in context.

• A live-location path is a set of straight lines between recorded positions, not a recorded route.

• Fraud pack and Activity figures are indicators for a human reviewer. Undocumented codes are shown raw and are not interpreted.

• A thumbnail-only item is a preview, not the original file. A hash match proves identical content, not where the file was held.

Reports

Generated reports are derived analytical artifacts. They should be retained alongside the underlying case and source evidence, not used as a substitute for the source acquisition.

19. Quick Reference

Recommended first five checks after parsing

1. Confirm case name/ID and platform.

2. Confirm message/chat counts look plausible.

3. Check media completeness.

4. Check Integrity findings, the Deleted Msg tab and deletion-related indicators.

5. Run targeted searches for known dates, contacts, terms and documents.

Appendix A — Glossary

Appendix B — Examiner Checklist

☐ Authorization/legal basis confirmed

☐ Case ID assigned

☐ Evidence source documented

☐ Original/acquisition copy preserved

☐ Source hashes recorded where required

☐ Atlas license verified

☐ Case folder created

☐ Case time zone confirmed

☐ Correct platform selected

☐ Acquisition/backup source validated

☐ Android key/password or iOS backup password handled securely

☐ Parse completed successfully

☐ Run log reviewed

☐ Media completeness reviewed

☐ Missing-media recovery attempted; sources and any re-download documented

☐ Integrity findings reviewed

☐ Multi-DB comparison performed if historical snapshots exist

☐ Incremental backups included where available; Deleted Msg tab reviewed

☐ Targeted message/document searches completed

☐ Relevant chats/media/documents exported

☐ Calls/locations/links reviewed where relevant

☐ Provenance, Identity, Fraud pack and Timeline reviewed where relevant

☐ Online lookups (maps, place names, re-download) avoided or documented per procedure

☐ Report generated and reviewed

☐ Limitations documented

☐ Final case workspace preserved