Broken links in Whatsapp chats when attachments file names contain emojis

[gfd2020]

I found a small bug in the emoji transformation. If the filename contains any emoji, the javascript link 'javascript:openIfExists' will be broken. Within IPED, the link will work, but not within reports. Example:

href="javascript:openIfExists('../../D/2/D2DED8529B0FBF1F60D700CE8B199999.pdf','file:///C:/test/files/books<img class="e1f4da">.pdf')"

Real path:
C:/test/files/books📚.pdf

PS: I don't know how whatsapp stores this filename internally, however it is possible to send files with emoji in the filename and they work normally.

This case that I tested and gave an error, it was a simulated whatsapp database.

[wladimirleite]

I just reproduced the issue here and will try to fix it.
Thanks @gfd2020!

[wladimirleite]

I think I fixed the emoji related issue, but it seems there is another issue.

@gfd2020, if you repeat the same test with a regular file name (like "books.pdf"), does it work?
I mean, when you open the HTML externally and click on the PDF, does the file open?

For reports (when items are exported as individual files using their hash as the file name) it works. However, when a folder is processed, it is not working here for audios, videos, documents and other file types, only for images.

[lfcnassif]

I mean, when you open the HTML externally and click on the PDF, does the file open?

Hi @tc-wleite, I tested this yesterday with master after an user question and it is working for images, audios and videos when a mounted folder is processed. Not sure about 4.1.4, I'll check it.

[wladimirleite]

Hi @tc-wleite, I tested this yesterday with master after a user question and it is working for images, audios and videos when a mounted folder is processed. Not sure about 4.1.4, I'll check it.

Please, test for a document (like a PDF) too.
Opening the HTML in the browser, it seems that it is failing to open the actual file (from the mounted folder) and falling back to the "../../X/Y/HASH.PDF", which does not exist.

[wladimirleite]

Please, test for a document (like a PDF) too. Opening the HTML in the browser, it seems that it is failing to open the actual file (from the mounted folder) and falling back to the "../../X/Y/HASH.PDF", which does not exist.

Probably I am doing something wrong here, as I tested using the version I just changed to fix the report issue.
I will repeat the tests more carefully.

[gfd2020]

@gfd2020, if you repeat the same test with a regular file name (like "books.pdf"), does it work? I mean, when you open the HTML externally and click on the PDF, does the file open?

Yes, it works.
Except for um case that one file was 0 bytes after make report, but I think is not related. I will test tomorrow.

[wladimirleite]

Yes, it works. Except for um case that one file was 0 bytes after make report, but I think is not related. I will test tomorrow.

Ok, thanks!
Just to be clear, the issue I think I found is when opening the chat HTML externally without creating a report, just processing a folder with the chat database and the files.
The JavaScript function openIfExists(url2, url1) seems to work fine for images, but not for other types of files. That seems to make sense, as this function creates an "Image" with url1 (the actual file if a folder was processed) and then check "onload" and "onerror" events.

[lfcnassif]

I didn't find a WA sample with an attached PDF yet.

The JavaScript function openIfExists(url2, url1) seems to work fine for images, but not for other types of files. That seems to make sense, as this function creates an "Image" with url1 (the actual file if a folder was processed) and then check "onload" and "onerror" events.

Makes sense! For audios and videos, there are a special handling.

[lfcnassif]

Actually I remember this issue with non image (documents) attachments from the past, but I didn't come up with a solution to open them from an alternative source if the first fails...

[wladimirleite]

For audios and videos, there are a special handling.

For audios, when I open in Chrome, the embedded audio player (in the right) works, but not the link (in the left).
Can you check if happens to you too?

[lfcnassif]

For audios, when I open in Chrome, the embedded audio player (in the right) works, but not the link (in the left).
Can you check if happens to you too?

It doesn't work. Sorry, I just tested the embedded player before.

[wladimirleite]

Thanks @lfcnassif!
So I will first fix the emojis issue, which is simple.

Later I will try to examine in more detail this non-related issue, and see if there is a reasonable solution.
In practice, WhatsApp chats come from UFDRs. So the direct access to attachments from the browser won't work anyway. Improving this would be nice, but not relevant in most scenarios.

[gfd2020]

For audios and videos, there are a special handling.

For audios, when I open in Chrome, the embedded audio player (in the right) works, but not the link (in the left). Can you check if happens to you too?

Off-topic. The audio and video tags are not well rendered ( just like the picute). Today I manage to make a css selector to fix this. Should I open another issue? The resolution is quite simple.

[lfcnassif]

Off-topic. The audio and video tags are not well rendered ( just like the picute). Today I manage to make a css selector to fix this. Should I open another issue? The resolution is quite simple.

Yes, please!

[gfd2020]

Yes, it works. Except for um case that one file was 0 bytes after make report, but I think is not related. I will test tomorrow.

Ok, thanks! Just to be clear, the issue I think I found is when opening the chat HTML externally without creating a report, just processing a folder with the chat database and the files. The JavaScript function openIfExists(url2, url1) seems to work fine for images, but not for other types of files. That seems to make sense, as this function creates an "Image" with url1 (the actual file if a folder was processed) and then check "onload" and "onerror" events.

I make more tests and did not work for documents, only images.

[wladimirleite]

I make more tests and did not work for documents, only images.

Thanks again, @gfd2020!
I managed to find a solution for audios and videos so far.

[gfd2020]

I make more tests and did not work for documents, only images.

Thanks again, @gfd2020! I managed to find a solution for audios and videos so far.

I'm confused now. When I generate the report with just a chat and I leave unchecked "Do not auto export chat attachments", images open and PDF does not. If I generate a report with a chat and individually tag an image and a pdf, both work. Shouldn't the "Do not auto export chat attachments" option export all media?
The openifexits is working, right?

[lfcnassif]

Shouldn't the "Do not auto export chat attachments" option export all media?

It should. Are you testing attachment opening from the HTML report or from the IPED UI from the report?

The openifexits is working, right?

Just for images. @tc-wleite just created #1841 fixing it for audios and videos. We are still not sure how to make it work for PDFs and other documents for these 2 situations at the same time: if you are opening them from a Chat into IPED HTML report or if you double clicked the Chat on UI after processing a mounted folder.

[wladimirleite]

Adding to @lfcnassif response...

Shouldn't the "Do not auto export chat attachments" option export all media?

Is the PDF file in the exported folder?

The openifexits is working, right?

You mean the current version, right?
For any files other than images (PDFs, audios, videos etc.), the current version always points to the "exported" file, not the original file (even if it exists). So it should work fine if attachments (of any type) were exported, both using the internal viewer or opening the chat HTML externally.
After the change I made, it should locate original files (if they are present in a folder) for audios and videos (images are already located today).

[gfd2020]

Is the PDF file in the exported folder?

I think it was a bug in my development environment.

You mean the current version, right? For any files other than images (PDFs, audios, videos etc.), the current version always points to the "exported" file, not the original file (even if it exists). So it should work fine if attachments (of any type) were exported, both using the internal viewer or opening the chat HTML externally. After the change I made, it should locate original files (if they are present in a folder) for audios and videos (images are already located today).

Yes. Ok then.

I just make more tests. I believe the behavior is as intended.

Tested on IPED 4.1.4

Just check one whatsapp chat on IPED interface and make a report. Nothing more.
I double-checked the results.

---

Smartphone unzip ufdr ( image folder mounted to view report ):
Unckeced "Do not auto export chat attachments"
Result: Report Working all files ( PDF, video, audio, images)

Checked "Do not auto export chat attachments"
Result: Report working files ( video, audio, images) . PDF does not work.

---

Smartphone unzip ufdr ( image folder unmonted to view report ):
Unckeced "Do not auto export chat attachments"
Result: Report Working all files ( PDF, video, audio, images)

Checked "Do not auto export chat attachments"
Result: Report does not work on any file ...

---

Smartphone ufdr file ( image folder mounted to view report ):
Unckeced "Do not auto export chat attachments"
Result: Report Working all files ( PDF, video, audio, images)

Checked "Do not auto export chat attachments"
Result: Report does not work on any file ...

---

Smartphone ufdr file ( image folder unmonted to view report ):
Unckeced "Do not auto export chat attachments"
Result: Report Working all files ( PDF, video, audio, images)

Checked "Do not auto export chat attachments"
Result: Report does not work on any file ...