How to decrypt WhatsApp end-to-end media files
blog.erratasec.com
blog.erratasec.com
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.
Any forensics expert ought to know about them.
The fact these didn't probably means we should question the rest of the report.
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.
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.
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....
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?
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.
And as others note, if the key had been deleted, they should have said that it had.
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.
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).
Hahaha I was hoping for a bit more in depth detail about this 'step'