sepinf-inc / IPED

IPED Digital Forensic Tool. It is an open source software that can be used to process and analyze digital evidence, often seized at crime scenes by law enforcement or in a corporate investigation by private examiners.
Other
924 stars 217 forks source link

Handle other WhatsApp Message Types #1923

Closed gfd2020 closed 5 months ago

gfd2020 commented 10 months ago

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/

wladimirleite commented 8 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.

wladimirleite commented 8 months ago

The unhandled message types (or subtypes) I found:

wladimirleite commented 8 months ago

An example with messages of type 90. After each call (video or audio) a redundant "unknown message" is currently displayed.

patrickdalla commented 8 months ago

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: @.***>

gfd2020 commented 8 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.

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.

patrickdalla commented 8 months ago

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.

gfd2020 commented 8 months ago

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 ).

wladimirleite commented 7 months ago

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:

wladimirleite commented 7 months ago

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.

wladimirleite commented 6 months ago

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

lfcnassif commented 6 months ago

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.

wladimirleite commented 6 months ago

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.

wladimirleite commented 6 months ago

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.

wladimirleite commented 5 months ago

@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?

lfcnassif commented 5 months ago

Great! Sure, this same issue can be used, since 4.2 will take some time to be out.