Whapa 2.00 reads the WhatsApp database WhatsApp changed in 2021

Why the 2021 schema change broke earlier releases

Whapa 2.00 exists because WhatsApp changed its database layout in 2021. The README is direct about the consequence: older releases stopped returning anything useful after that change. A parser that assumes a column layout silently produces an empty or wrong report rather than an error, which is the worst failure mode for forensic work.

The fix was to read both schemas. Whapa handles the current Android layout and the legacy one, and the same parser now also handles iOS through ChatStorage.sqlite, which the README marks as new in this version. Alongside the schemas came decryption for crypt15 in addition to crypt12 and crypt14, and recognition of message types introduced since: polls, video notes, view-once media, events, albums, edits, reactions, channels and communities.

That last item is the one an examiner should note. Message types the parser does not recognise become invisible rows in a report. If a conversation contains channel posts or community announcements and the parser predates them, the gap looks like missing evidence.

Five scripts that do one job each, and a GUI that only builds commands

The toolset is deliberately decomposed. On Android there is whapa.py as the database parser for current and legacy schema, whacipher.py for decryption and encryption, whagodri for Google Drive backup extraction, whamerge for merging databases, and whachat for exported chat text. On iOS there is whapa.py against ChatStorage.sqlite, whacloud for iCloud extraction, and whachat again for exported chats.

The graphical interface adds no logic of its own, which the README states plainly: it builds the command and calls the matching tool in libs/, so the panel output is exactly what the console would produce. One tab per tool, fields to fill in, output shown live, plus an Install requirements button that uses the same Python running the interface. Settings edits cfg/settings.cfg in place, holding case details that land on the report cover and the Google Drive and iCloud credentials, and the interface switches between Spanish and English.

That design has a practical benefit for a case: what you click is what you can reproduce on the command line and paste into your notes.

Installation and the first report, start to finish

You need Python 3.11 or later, checked with python3 --version. The clone and dependency install differ only by path separator:

git clone https://github.com/B16f00t/whapa.git && cd whapa
pip3 install --upgrade -r ./doc/requirements.txt

If you only need the command line and will not touch Google Drive or iCloud, the README says pycryptodome and colorama are enough. The toolset reports missing dependencies itself instead of throwing a traceback, naming the tool and the package:

python3 libs/whacipher.py -f msgstore.db.crypt15 -d key -o msgstore.db
python3 libs/whapa.py msgstore.db -i 3

The first line decrypts, the second prints what is inside. Then you build the report:

python3 libs/whapa.py msgstore.db -m -a -wa wa.db -r EN -o ./report

Open report/report/index.html by double-clicking it; no web server is involved, which matters for a case file you may need to hand over as a single directory. On iOS the invocation is the same shape against the other file name, ChatStorage.sqlite. Decryption accepts the key file, encrypted_backup.key, or 64 hexadecimal characters of the root key, with the format detected automatically.

One search engine shared by console, GUI and report

Filtering is where a forensic tool earns its keep, and Whapa applies the same engine in all three places: the command line, the graphical interface and the report itself. The README states the consequence, that the same criteria always return the same result.

The vocabulary covers free text with -t, regular expressions with -re, whole-word matching with -ww, case sensitivity with -cs, chat selection by user or group identifier, sender with -sn, a date range with -ts and -te, direction with -d sent or -d received, and then message property filters: only deleted with -td, only starred with -s, only with an attachment using -md, forwarded or edited with -fw and -ed, messages carrying coordinates with -gp, and the read receipt states -lr and -lu. Type filters cover image, audio, video, poll and view once, and a raw type code list such as -rt 66,112 is available for values you cannot name.

A full run can emit the interactive report, the printable one and the CSV together from one command, which saves repeating the same long filter line three times.

Attachments are not in the database, and that trips up most first runs

This is the limitation the README spends the most space on, for good reason. A WhatsApp database stores only the path where each file used to live, for example under /storage/emulated/0/WhatsApp/Media/WhatsApp Images/. An exported chat .txt likewise only names the files. Media recovery from Google Drive or iCloud is a separate tool, and the README does not describe pulling media from a cloud backup, only the database side.

So you copy the WhatsApp folder off the handset with its structure intact, Media subfolders for images, audio, video, documents, voice notes and stickers. On iOS the equivalent is under Message/Media/, and either layout works. If you exported the chat from the app instead, the attachments arrive in the same folder as the .txt, and that folder is already the media folder.

Then you tell whapa where it is:

python3 libs/whapa.py msgstore.db -m -a -r EN -mp /path/to/WhatsApp -o ./report

With -mp, images render inline and audio and video play in place. Without it you get a report full of paths. The last decision the README describes is whether to copy files into the report or link to them, controlled by -cm, and a copy operation matters because a report that links is only valid on the machine that produced it.

Versioning, platform claims and the missing license

The README header reads Version 2.00, July 2026, while the repository description still says WhatsApp Parser Toolset v1.59, and the repository has no tagged releases. That mismatch is worth knowing before you cite a version in a report: use the changelog at doc/CHANGELOG.md rather than the badge text as the version of record.

The code is Python 3.11 and the README states it was tested on Linux, Windows and macOS. The layout is small: libs/ holds the tools, doc/ holds the requirements and changelog, cfg/ holds settings.cfg, and whapa-gui.py plus whapa-gui.bat start the interface.

The last push was on 2026-08-02, and the repository lists no license. That is the one item to settle before using the output professionally: without a license file, the terms for redistribution of the tool and for derived artefacts such as reports are not stated in the project, so ask the author rather than assuming a permissive default. The tools decrypt user data, so scope them to devices you are authorised to examine.

Editorial conclusion

Whapa suits an examiner who already has an unlocked device image or an encrypted msgstore database and wants a readable timeline plus a CSV in one run. It is not a full acquisition tool: media has to be copied off the phone separately and pointed at with -mp, and the project carries no license, which leaves redistribution and derived reports on unclear ground. Before a case, confirm your device layout matches what whapa expects, check the legacy and current schema both parse, and read doc/CHANGELOG.md for what 2.00 changed.

Frequently asked questions

Official sources

1. B16f00t/whapa on GitHub
2. Issues
3. README