Investigate WhatsApp deleted messages with "trash" status

[lfcnassif]

Copied from #2287 (comment):

About commit ce22a6c, has anyone observed some new column in WA messages table with a name similar to "deleted" and values like "trash" or meaning that? A colleague reported to me CellebriteReader reports several messages as deleted=trash, while the same messages are displayed by IPED's internal parser as allocated messages (not deleted). Just a guess, maybe WA is just tagging messages as deleted to later (in the night?) delete them from database in idle moments...

PS: On cellphone screen, I think those deleted=trash messages are not shown, I will double check with him.
PS2: Or maybe there is another table with the trash status column that could be joined with the messages table...

[aberenguel]

I found deleted_state attribute as "Trash" in Instant Messages that were quoted by not found in the Chat.
It happens in some cases like when the quoted message was deleted or replied after the user joins a group.

[wladimirleite]

In Android DBs, there is a table named "deleted_chat_job", which design is quite confusing.
It is not new, but we currently don't handle it.
From what you described, my guess is that this table is not empty (which usually is, but I found some samples here with data), and the messages marked to be deleted are shown as "trash" by UFED parser.
If you can get and send me this DB, I can take a look to confirm if that is the case and try to add the support.

[wladimirleite]

PS: Found some WhatsApp Android DB's from 2021 which already have this table. So it is definitely not new.
@lfcnassif, the case you are talking about is from an Android DB, right?!

[aberenguel]

I found deleted_state attribute as "Trash" in Instant Messages that were quoted by not found in the Chat.
It happens in some cases like when the quoted message was deleted or replied after the user joins a group.

This case was seen in iOS.

[lfcnassif]

@lfcnassif, the case you are talking about is from an Android DB, right?!

Waiting user feedback... I'll try to get the DB with him.

[lfcnassif]

Waiting user feedback... I'll try to get the DB with him.

It's Android, he will share the DB on Monday.

[wladimirleite]

PS: On cellphone screen, I think those deleted=trash messages are not shown, I will double check with him.

Sorry, but the strikethrough means this still has to be checked, or the messages are actually shown in the app?

[lfcnassif]

Sorry, but the strikethrough means this still has to be checked, or the messages are actually shown in the app?

Needs to be checked, the user didn't check it on the phone.

PS: The phone is not with him anymore.

[wladimirleite]

If it really is related to the "deleted_chat_job" table, it should enough to check against UFED parser.

[lfcnassif]

If it really is related to the "deleted_chat_job" table, it should enough to check against UFED parser.

I did't get it... if it is related to that table it shows up or not on phone screen?

[wladimirleite]

I did't get it... if it is related to that table it shows up or not on phone screen?

I believe such messages are not visible on the device.

[wladimirleite]

It's Android, he will share the DB on Monday.

Any follow up on this?

[lfcnassif]

Any follow up on this?

I asked the user for the DB again.

[wladimirleite]

Thanks @lfcnassif!
I received and analyzed the DB.
The messages are not deleted (they don't have anything different from other messages).
Either there is an error in the PA parser (highly unlikely) or there is more than one database in the UFDR, and there was some kind of misinterpretation.

While investigating this issue, I found a regression caused by #2337.

[wladimirleite]

The reported issue is not related to "deleted_chat_job" table, as it is empty (at least in the DB I received).

[wladimirleite]

... or there is more than one database in the UFDR...

In fact, there were 7 databases (the active one plus 6 backups).

The messages shown as trash are not present in the backups because they were very recent (sent/received after the last backup).
In the main database (which I already received and analyzed before), thes messages are active.
So my conclusion is that internal parser interpretation is correct (i.e. messages were not deleted).

I will try to process the databases using PA, and see if I can reproduce the behavior reported by the user.

[wladimirleite]

I will try to process the databases using PA, and see if I can reproduce the behavior reported by the user.

I tried a few things, but couldn't manage to make PA process these databases (which are already decrypted and extracted from their original UFD).
All available information indicates that the internal parser is correct, and the "trash" flag was incorrectly added by PA.
As the device is not available anymore, I don't see anything else we can do.
@lfcnassif, unless you have other ideas, I think this can be closed as "not a problem".

[lfcnassif]

Thank you very much @wladimirleite for all your tests! I agree we can't do additional tests without the original phone, so let's close this. If we find a similar situation in the future, with the original phone in hands, we can reopen. Thanks again!