-
Notifications
You must be signed in to change notification settings - Fork 208
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WhatsApp parser may lose recent messages #1791
Comments
Good catch! Thanks @tc-wleite for reporting and investigating this! This may deserve another release, what do you think? |
I don't think this issue is very common, but it can be critical when it happens, so maybe it justifies another release. |
It seems related to the way PA software deals with WAL files, shouldn't happen in original evidences. But since we process a lot of UFDR reports, it may be worthy. |
Ignore folders and items with different names in WAL search (#1791)
While working in a real case, I found important WhatsApp messages extracted from UFDR that were visible in Physical Analyzer but were not included in IPED's chat HTML. They were the most recent messages present on the device.
This is another tricky issue...
I found out that the messages came from the WAL (write-ahead log) that sometimes is present together (same folder and name, with suffix "-wal") with WhatsApp SQLite database.
IPED missed the WAL file, while PA handled it, although IPED's WA parser (and SQLite parsers in general) handles WAL files.
The issue was caused by the incorrect identification of the WAL file.
In this particular case, an image was embedded in the WAL file, which created two items (a folder and the image itself) with the names also found by the query that searches for the WAL file with the same path, as shown in the following image:
The parser found that the folder was the WAL file, missing the information contained in the actual WAL file.
I believe this issue is not very common, however it may happen not only with WhatsApp parser but any SQLite parser.
I will submit a PR making the search for the matching WAL a bit more robust.
EDIT: This issue may also affect SQLite journal files, which use the same search code.
The text was updated successfully, but these errors were encountered: