It's possible the forensics experts couldn't extract the video encryption key because the malware itself had decided to corrupt/remove it.

It would make sense - if you're distributing a (very expensive) zero day exploit to a target, you want to make sure that as soon as the exploit code runs and leaves the payload, the exploid code is removed and scrubbed, and any evidence of how the payload got there is hidden or removed. Deliberately changing the encryption key stored in whatsapps message database would be a good way to do that, as would locking down backups, usb ports, and generally things that make forensics difficult.

Sure its possible, but if they were actually forensics "experts" then they would have been able to explain exactly what you did. That the decryption key was removes from the device.

Another tool which was posted on HN a couple of days ago to demonstrates how to decrypt encrypted media files downloaded from WhatsApp: https://github.com/ddz/whatsapp-media-decrypt

I can confirm that there are opensource projects to send and receive (and hence encrypt and decrypt) WhatsApp media files, and they have been around for a long time.

Any forensics expert ought to know about them.

The fact these didn't probably means we should question the rest of the report.

Is there any reason why you can't name them please, for those of us who weren't aware?

For example: https://github.com/tgalal/yowsup

The code is a bit nightmarish, but it's hackable to do whatever you like. Whatsapp will ban you if they detect you using it, so make sure to update the client version numbers etc, and use a burner number for testing if using their live servers.

Thank you - especially for the hints :)

This is not a bug though. End to end encryption does mean the endpoints have access. So your own iPhone (obviously) has access to the videos you can see in the app.

I think there is some bit of over-simplification in the argument that just because video can't be decrypted, it is likely benign. The acknowledgement of a buffer overflow exploit by facebook through a CVE (https://www.facebook.com/security/advisories/cve-2019-11931) points to a definite vulnerability in Whatsapp which can be abused through a video. Timeline wise, it seems highly likely that it could have been abused.

I don't think the article is making a great argument the video is benign; however, they're making a decent argument that the investigation was incomplete and doesn't present any non-circumstantial evidence of Saudi involvement.

Like you say, the CVE is interesting, and I don't think there's a public description of the flaw. The article doesn't actually analyse the video: which is a bit odd since they are able to decrypt it. If the flaw is a buffer overflow in the MPEG stream parsing, it appears it would be reasonably easy to demonstrate that the MP4 file in question had been specially crafted, even if you couldn't directly demonstrate the exploit....

No, they couldn't decrypt the file on Bezos' phone. Because they don't have the phone, or even the file.

TFA actually says that clearly:

> Remember that this example is a video a friend sent to me, and not the original video sent by MBS to Bezos. But the same principle applies. Simply look in that file in the backup, extract the URL and mediakey, insert into this program, and you'll get that file decrypted.

What they've demonstrated is a method that should work on Bezos' phone.

Edit: OK, I see that they get the encrypted file from the WhatsApp server:

> mediaurl = https://mmg-fna.whatsapp.net/d/f/[string].enc

So might the Saudi file in question have been deleted from WhatsApp?

Could the Saudis have done that?

WhatsApp themselves may have deleted it, who knows. I guess the point is, they claim to have the file, but haven't attempted to analyse it.

I don't think anyone was claiming it wasn't video - it plays in the app, so clearly the majority of the data is indeed regular MPEG. And it's difficult to prove that an exploit _isn't_ present, especially if the payload could be hidden in the video stream (since you could control the video frames, you can likely hide a significant amount of data before you need to resort to actual steganography).

But, given the claim (that a remote exploit was used to gain C&C over the phone), there must be _something_ odd in there: metadata that doesn't make sense, frames of video not used, etc. - because there's an overflow (which probably means some byte index or something in the metadata is bad) and an exploit (there's a payload in there making use of the overflow). At the very least, some regular software like ffmpeg will complain during decoding that stuff doesn't make sense.

Sure.

But the point is that the file could have been decrypted by this approach. And it wasn't done, even though the data was available in the backup.

Unless there's something wrong with the approach described in TFA.

What an excellent post, thank you. The author discusses complex topics in an accessible way. It's gems like these that keep me coming back to HN every day.

Really? I was like "wao, he has found a way to break encryption" only to figure out he is decryption using the key. End to end encryption is all about preventing man in the middle attack. Not about preventing a second way for decrypting at end points.

I don't think he alluded to breaking / cracking the encryption. Decrypting messages is not that same thing as breaking encryption. In fact he demonstrates how Whatsapp have done things properly and at the same time demystifies how the whole thing works. He doesn't actually explain end-to-end encryption, but only indicates that that is the mechanism used to transfer the secret key from the sender to the receiver.

And further, it calls into question the ~FBI report's claim that the file was "end-to-end encrypted", so they couldn't inspect it.

And as others note, if the key had been deleted, they should have said that it had.

Related question: Does anyone know how to decrypt the Whatsapp database on Android without root?I'd like to do the same process described in the article but I'm using Android

You can probably use `adb backup` (described here: https://www.technipages.com/how-to-backup-your-entire-androi...), then extract the backup using `android-backup-extractor`: https://github.com/nelenkov/android-backup-extractor.

Whatsapp has disallowed backups this way for some time.

I've seen some people advocate replacing the installed version with an older one which does allow backups (by uninstall and reinstall, hoping the uninstall can be done in such a way as to not delete the app data) then use ADB backup on that one and reupgrade before launching it, but honestly it's easier to backup, restore on a rooted phone, extract the key, then restore again on the unrooted phone to get service back (the key doesn't change afaik).

You can do this on a different phone without messing about with SIM swapping etc, you just need access to receive SMS messages on the number the backup is tied to.

Seems like this is the easiest way - Thanks for your help!

For the whatsapp encryption scheme because the IV is fixed per a media key is there any reason not just to set it all to zeros or a fixed value instead of using the KDF to derive it.

There is no technicqal reason for using unique IVs in this case. But it does not hurt and looks better in security audits.

Edit: there is also an line of reasoning that you should not needlessly expose cryptographic primitives to "non-random"/"structured" inputs as a defense in depth against attacks on such primitives. But when that matters it simply means that the primitive is broken and should not be used (or at least should not be used in that particular way, eg. TEA as hash function in original Xbox firmware).

> decrypt the video, using a tool I just created on GitHub

Hahaha I was hoping for a bit more in depth detail about this 'step'

The article links to the code: https://github.com/robertdavidgraham/whats-enc/blob/master/b... and provides an explanation of what it does: AES decryption with CBC mode.

It's just below in the article. Scroll to "How to decrypt a WhatsApp media file". Then read the explanation, then the commented code.