Open gisms opened 3 years ago
Be aware the internal parser needs sha-256 to be enabled and it does not recover deleted messages for now, please check this https://github.com/sepinf-inc/IPED/issues/309#issuecomment-721463990
and please report back if that's not the case.
Wow, I looked it up on the forum before, but I think the name of the comment you linked wasn't as directed to my case, although it helped me.
I generated the ufdr report including 256 and md5 and also used ipedconfig with both.
External parser: actually brought all chats.
Internal parser: still missing some chats as explained
@fmpfeifer any idea? @gis-msouza could you share privately the WA database to reproduce this?
@fmpfeifer any idea? @gis-msouza could you share privately the WA database to reproduce this?
I never came across something like that. A Chatstorage.sqlite that triggers the bug would be really useful to undestand what is going on.
- Internal parser: still missing some chats as explained
@gis-msouza just to confirm, are those missing messages or chats flagged as deleted in external parser output?
apologies for the delay.
cellebrite did not bring deletion information. The chat is not marked as deleted. But, I managed to confront in reality and is without the messages.
For greater visualization of the scenario, just out of curiosity, I took a look at ChatStorage, there is an entry in ZWACHATSESSION with reference to the contact who sent the conversations. There are the messages entries in the ZWAMESSAGE, but no reference to the contact who sent them, ZFROMJID status@broadcast.
In ZWAMEDIAITEM, the fields ZMEDIAURL and ZXMPPTHMBPATH and ZMETADATA are filled in and in fact only the thumbs are are available in the ufdr.
There are the messages entries in the ZWAMESSAGE, but no reference to the contact who sent them, ZFROMJID status@broadcast
This is a good tip. Please keep this Chatstorage.sqlite so you could help us to test a possible future solution to this if you cannot share the database privately.
@fmpfeifer if you have time (or not) to take a look at this in the near future, please let me know.
Yes it is possible for me to test again any time. Let me know.
Ps: sorry i closed by mistake.
I think I can take a look at it in a few days. I think that this status@broadcast is used for the whatsapp status messages, and as far as I can remember, we are not decoding those messages yet.
@gis-msouza could you confirm the missing messages refer just to status changes? What thumbs are available in the UFDR? Contact thumbs or some thumb referenced by the missing messages?
yes, they are chats with id filled in with phone@status. so that's the reason. the images are not contact thumbs, thumbs from random images posted i think.
I still didn't understand how the images are related with missing status changes, could you describe with more detail as we don't have your database?
If there is some issue here beyond status messages not supported, maybe it won't be possible to fix it without a sample database to reproduce the issue.
I will send you an email.
Final enhancement identified:
Today the items explained below are included in Cellebrite as whatsapp "chats" and are not being decoded by the IPED internal parser:
a) "chats" created from images posted by contacts in the "Status" functionality of whatsapp (similar to instagram stories). The previewed images can be seen in a larger way, the ones that were not previewed exist only in thumbnails. In the ZWACHATSESSIONS table there are 2 different entries for the same contact, one for status (phone@status) and another for normal conversation (phone@s.whastapp.net) -- in cases where both exist for a particular contact.
b) Change in a contact's profile, such as change in profile picture, appear on cellebrite as a chat, without any message and the conversation has only 01 participant.
It doesn't seem to us that treating both items as chats is the best solution, but that's how Cellebrit does today.
Thanks @gisms for your detailed investigation. I also don't think status and profile changes should be shown as chats (like done by Cellebrite software). But we could decode that info and show in another way...
I'm indexing some .ufdr files, so far only iphones, and I've noticed less conversations coming up on iped. I didn't get to analyze it in depth, but in general it seems to me that the missing conversations are those that only have media attached, or a link sent, without any text input, without even that standard system text input. Did you experience something similar?