Questions about whatsapp audios

[dressito]

Hello!
In the evidences I'm analysing, I have identified that the Whatsapp audios come from some different sources, mostly:
(1) .../Library/Mobile Documents/.../Accounts/[phone users number]/backup/Media.tar...
(2) .../Containers/Shared/.../media/[phone number/group number]@/...

Everything that comes from (1) is ok (except for a few empty files). I can export, listen, and the metadata looks correct.
On the other hand, all the audios that are from (2) have size, some Ufed: columns, md5 hashes, but none of them work. I cannot listen or export. The metadata shows duration and size, but the hex for all of them seems to be "0", like an empty file.
And two of the evidences doesn't have audio files from (1), only from (2).
In many cases, I have the same audio in (1) and (2), which shows that (1) is really a backup.

But one problem is, when the chat is reconstructed in the preview pane, like below, the link always points to the audio in (2), and it doesn't play ("attachment not found"), even though the copy in (1) exists.

My questions:
a) Is this the expected behavior when working with Whatsapp artifacts?
b) Or is it something related to the iOS/iPhone enviroment? (the evidences seems to be from 4 different iPhones)
c) Does the path indicates that some of the audio came from the cloud and some from the phone? Or the backup is on the phone?
d) Since all the audios from the (2) folder are not working, it means the UFED extraction had some problems, or it is not possible to extract the audios from this folder? Is a cryptographic key needed?

These evidences were processed by another agency (Gaesf/MP), so I currently don't have access to the originals, logs, etc., only what was extracted using UFED and processed by IPED (4.0.1).
I can share some more info/screenshots if needed.

Thanks!

[lfcnassif]

On the other hand, all the audios that are from (2) have size, some Ufed: columns, md5 hashes, but none of them work. I cannot listen or export. The metadata shows duration and size, but the hex for all of them seems to be "0", like an empty file.

Is the Hex content empty or filled up with lots of zeros? Does the MD5 hashes differ or all of them start with D41D8...?

a) WhatsApp parser tries to link attachments to chats using the attachments SHA-256, so the location of the file shouldn't cause differences in results, if the attachments were extracted properly from the evidence;
b) Not sure. Was SHA-256 enabled when processing the case? Just check if it is shown in the case for some files. If not, that can explain why the attachments from folder (1) were not linked properly.
c) Unfortunately I'm afraid I can't help with this doubt. If some of the audios came from the cloud, things may be a bit more complicated, see #486 for example.
d) It is possible that a Full File System extraction was not done and not all files were extracted correctly, but I'm not sure if references are created to the original files instead of extracting them, in this case. If you have the original UFDR report, try to open it using CellebriteReader.exe software and check if files from folder (2) can be opened. If not, some issue with the extraction may have occurred, if yes, some issue with IPED processing, or some misconfiguration with the used profile, may have happened.

[dressito]

Hi Nassif, thanks for the reply!

Sorry I wasn't clear in the first message... every .opus file that was found in the (2) .../Containers/Shared/.../media/[phone number/group number]@.../... folders have a different MD5, which matches the MD5 in the Ufed:MD5 column, but the HEX is empty (I've found some with a few zeroes, I think), like the image below:

But none of these audios work.

a and b) All the files have md5, sha-1 and sha-256 hashes. It seems like, when creating the html that mimics the whatsapp chat, in cases where the attachment have duplicates, only one is linked. In this evidence, looks like it was the files from (2), that doesn't work.
c) no problem, I will look into it.
d) By exploring it, I think they've sent us an IPED case without the original .ufrd file. Other file categories are not opening as well, like pictures and documents. Those inside a .tar container, like in (1), are ok. This brings other questions:

e) Whenever I process an IPED case, when I explore it later, if IPED cannot find the source evidence file, it will prompt me, so I can correctly point to its location and then open the selected file. Why this is not happening in this case, and it shows me only the metadata but I cannot see the file contents nor get this prompt? Was it some processing option they've used?
f) As far as I've searched, the UFDR file is not in the material they've sent. Is there something in the IPED folder that points me to the name/location of the evidence file (like the prevTempDir.txt or newDataSourceLocations.txt)?
I will reach Gaesf/MP to know about the evidence file anyway.

Also g) Is there a way to select all the audios related to a specific chat?
I can find all messages using ParentID, and I can filter for messages that have audio. But I couldn't find a way to list the audio files themselves. The parent of an audio file is not the message. The "reference" tab shows the message and the chat, but I cannot find this info in the metadata, so I could search for something like "all audio/opus files that have this chat as reference"?

Thanks again! (Sorry for so many questions...)

[lfcnassif]

Since those files have MD5 and SHA-256 hashes, seems they were extracted and processed fine. In fact, if attachments weren't found while processing the chats, the attachments checkboxes wouldn't be present.

The absence of the UFDR file seems the more likely issue cause here. You can look at the dataSourcePath column, it should point to the original UFDR file location, if the case is still dependent on it (if automaticExportFiles option in IPEDConfig.txt wasn't used, please check it inside the case/iped folder). If that's the situation, IPED should ask for the UFDR file location, maybe it is an issue with the old 4.0.1 version, it is outdated, I suggest you replacing the contents of the case/iped/lib and iped/localization folders for those from 4.0.7, maybe the new evidence dialog location will show up.

SubItems inside tar/zip and other containers are expanded and copied to a database inside the case folder, so IPED never needs the original evidence to open subitems.

About selecting all audios or attachments referenced by a specific chat, this can be done with the new (outgoing) References Tab from 4.1.0 or a later version. It has the opposite behavior of the old (incoming) References tab. To do this manually, you can go to the Chat metadata and copy the values from linkedItems property and search for them in the search bar (I don't remember if the values already come with sha-256 prefix, if not, use it as the search field), it should bring all chat attachments, then you can filter by Audio category.

[dressito]

dataSourcePath points to the .ufdr file in a relative path that's not present in the sent material.
automaticExportFiles is set to false in IPEDConfig.txt, but it's not asking for the source file... when you click on an item it just does nothing. Then I've tried replacing the folder for the 4.0.7 version like you said and IPED asked for the source path again. Nice. So it's settled that the problem is the lack of the evidence file. Since I didn't know that contents from containers were copied to a local DB, I was confused.

I saw the new outgoing references tab in 4.1.2, although I cannot reprocess the evidence without the .ufdr file to test on this particular case. But the linkedItems workaround gave me the results I was expecting, so thanks a lot! I will share this procedure with the analysts, so they can follow the conversations/audios like they want (at least the ones on the .tar backup).

[lfcnassif]

Good to know my tips helped, you're welcome.