Closed gfd2020 closed 5 months ago
Hi @gfd2020! I understand you created this issue but you are not working on it, right? Let me know if it is not the case. While working on #2030, I found these two message types you mentioned and a few others that are not handled. I started to use two phones to check the unhandled message type, comparing parser results with actual messages displayed on them, so I will work on this issue too. I am also changing it to include a few other types.
The unhandled message types (or subtypes) I found:
An example with messages of type 90. After each call (video or audio) a redundant "unknown message" is currently displayed.
Maybe there could be some alerts of any other yet unhandled messages types if found. In iped log, or even in a specific log/subitem report.
Em qui., 28 de dez. de 2023 06:51, Wladimir Leite @.***> escreveu:
The unhandled message types I found:
- 24
- 25
- 27
- 28
- 32
- 36
- 45
- 46
- 49
- 66 - Poll
- 90 - Call (redundant with audio and video calls already handled, but in messages table)
— Reply to this email directly, view it on GitHub https://github.com/sepinf-inc/IPED/issues/1923#issuecomment-1871051455, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG247S76KKNFBJU5CZRZ43LYLVFK3AVCNFSM6AAAAAA5ZLGPI6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZRGA2TCNBVGU . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Hi @gfd2020! I understand you created this issue but you are not working on it, right? Let me know if it is not the case.
Hi @wladimirleite . I just started looking at these codes and did just a few queries to start the reverse engineering process. I didn't make any relevant code, I just put code 25 as an image and 32 as text and both were already rendered by IPED. Any extra information I discover, I will report here to help you with its implementation.
I believe most of these codes you found are interactive messages.
Maybe there could be some alerts of any other yet unhandled messages types if found. In iped log, or even in a specific log/subitem report.
Another good alert, maybe in another issue, would be to show noncontinuous msg id. Msg row id is sequential, and missing ranges may indicate deleted messages.
I worked on a case that I recovered images with names like the names given by whatsapp and missing id ranges within the same date range of the created dates of the images. This info with others context info was enough to suggest that the found images were exchanged by whatsapp in that conversation.
I also found type 23 in a test. I don't know exactly what it does but the message_row_id references the message_media table ( file_path column with image path ).
Working with an iPhone, I will apply similar changes to ExtractorIOS, to at least handle most common messages that are not currently handled. Part of the code (like the report generation) and resources (messages to be shown) are used by both parsers (iOS and Android), so this should be simpler. I will update the handled message types below:
I also found type 23 in a test. I don't know exactly what it does but the message_row_id references the message_media table ( file_path column with image path ).
I found out that type 23 is used for "product" messages. They can have an associated media and other textual fields (like title, description, currency and amount) stored on another table.
Working with an iPhone, I will apply similar changes to ExtractorIOS, to at least handle most common messages that are not currently handled.
I just found a nasty bug (see below) in ExtractorIOS
that was setting many system group-related messages as APP_MESSAGE (they are rendered as an empty attachment message) .
After fixing it and processing a single iOS UFDR that I am working on, a few thousand of "unknown messages" appeared😅
I will try to add support to them in the next few days. Meanwhile, I will change the related PR #2048 to draft.
Two break
's are missing, after cases 6 and 7 (code from current master).
Going back on the history of this class, the issue was already present at 3.18.x (at least).
https://github.com/sepinf-inc/IPED/blob/183016b89418917cdae8532fcbaa3ef99167cd38/iped-parsers/iped-parsers-impl/src/main/java/iped/parsers/whatsapp/ExtractorIOS.java#L698-L722
Wow... Thank you @wladimirleite for catching this long standing bug! I always thought those APP_ MESSAGEs rendered as empty attachments quite strange, but never stopped to investigate. Actually I'm not sure exactly what an actual APP_MESSAGE means, maybe @fmpfeifer could clarify us.
Actually I'm not sure exactly what normal APP_MESSAGE means.
I believe that it is used for messages with other kinds of attachments (not audio, image or video). I can confirm that tomorrow.
Actually I'm not sure exactly what normal APP_MESSAGE means.
I believe that it is used for messages with other kinds of attachments (not audio, image or video). I can confirm that tomorrow.
Confirmed. It just a minor code detail, but probably DOC_MESSAGE would be clearer. I will rename it.
@lfcnassif, I am making a few more changes to handle other community-related message types, I found in a Android DB I am working on. Can I create a PR referencing this issue number (as it is a complement of it), or is it better to create a new issue?
Great! Sure, this same issue can be used, since 4.2 will take some time to be out.
I detected two new types of unimplemented WhatsApp messages ( Android NEW DB):
message_type equal to 32, appears to be text. message_type equal to 25, is an image type. It appears to be of type Jpeg.
It would be good to compare it with a WhatsApp conversation on a cell phone to find out.
I suspect they are related to robotic messages.
I think that they are interactive messages: 25 is the text option with image. 32 is the answer.
The info is on the tables: message_template_button, message_template, message_template_quoted
https://developers.facebook.com/docs/whatsapp/guides/interactive-messages/