Hacker News new | past | comments | ask | show | jobs | submit login

For the work I do, I also conducted a mini-experiment where I checked the WhatsApp security in regards to the media transmitted.

In the cited documentation below ([0]), it claims that media will not be saved for either method 1 or 2 ("To stop media from all your individual chats and groups from being saved" and "To stop media from a particular individual chat or group from being saved").

I found out that the media is in fact written to storage, straight to the "Private" directory ("Internal Storage/WhatsApp/Media/WhatsApp Images/Private"). Said directory includes a ".nomedia" file which inhibits the Gallery app from your phone to see such media. So if you were to copy the "Media" directory into your PC, such "unsaved media" would come with it.

Also, when sending View Once media ([1]), it can be easily screenshot on your smartphone, or if you're using WhatsApp Web, use the DevTools while image is open, so you can grab it in their transmitted resolution.

Want to grab a status from a contact? Go to "Internal Storage/WhatsApp/Media/.Statuses" (enable view hidden directories in your Files Explorer application) and copy/move the file elsewhere, so it goes out of reach when WhatsApp tries to delete it.

Not to spill poisonous words around here, but I highly doubt they take security seriously.

[0]: https://faq.whatsapp.com/android/how-to-stop-saving-whatsapp... [1]: https://faq.whatsapp.com/general/chats/about-view-once/?lang...




View once media is always susceptible to this problem. I can always put a capture card between my screen and the device or use a vm - or just take a picture using a second device.

Likewise touching file storage makes sense, the media files have to sit somewhere. Any vaguely modern android phone has full disk encryption, so it's only apps with global filesystem access that present a threat.


That's not true. It's possible to manipulate file-like objects without ever touching the filesystem. BytesIO in Python for example ([0]).

I'm not an expert in Java Android, but I'm pretty certain there must be something like that.

[0]: https://docs.python.org/3/library/io.html


Let’s assume we don’t want to make memory constrained devices keep large video files buffered in memory and constantly re-download them over the network?


For the View Once media, have it buffered in memory and be done with it. Delete from the server once it's inaccessible (or keep it a few days it need be... for reporting reasons).

For the non-private media, just write it to storage straight away.


You're still susceptible to me owning a second device that can take photos. If it can be displayed, it can be copied.


encrypt with in-memory nonce


Still hit the issue with large media that doesn't fit in memory and your gain is still minor (resist a compromised filesystem.. maybe.. if they didn't compromise the binary too)


How does that hit an issue with large media that doesn't fit in memory? The encrypted media is on flash. The key is in memory. The key is small.


I have 1gb of ram. I want to watch a 4gb video file that's encrypted, starting at 0:32 and I want to jump back to that timecode a few times.

You can't check chapter markers or frame counts because they are encrypted.You can't usually partially decrypt a file either.


If use use AES-CTR you can decrypt any arbitrary 16-byte block of data from the file as long as you know its offset from the beginning. You don't need to know any other data of the file. As long as you don't need to insert or shift parts of the file without re-encrypting, this works fine. And you have to be OK with the file being padded at the end to a multiple of 16 bytes long.

Every time you want to read some data off flash, you read it then immediately decrypt it. Any time you want to write data to flash, you decrypt it first. Checking chapter markers or frame counts will be the same as before as long as you decrypt those bytes immediately after reading them from flash.


How does that prevent me from lifting it right off the framebuffer?


> I can always put a capture card between my screen and the device or use a vm

Nope, look up HDCP. They could enforce that on desktop if they wanted to.

> or just take a picture using a second device.

Yes, but you will lose quality.


Additional pills:

If you have your phone rooted, go to the "/data/data/com.whatsapp" using a terminal, and copy the messages database to the Internal Storage (wherever that is, I don't have any rooted device right now with me).

Then extract that file to your computer and use any SQLite3 viewer. It's not encrypted.

You'll find messages since the very first install of WhatsApp, even if you deleted these.

Last tested: about the year 2017.


Regarding storing files: They either are using https://developer.android.com/training/data-storage/app-spec... and other apps would not be able to access those files at all, or they should be using it instead of just using "external storage".


I agree, I see it currently uses the "unprivileged storage" (the user-space storage called "Internal Storage").

"My Files" ("com.sec.android.app.myfiles" on Samsung Android) is an app and certainly has access to those files.

If that app has access to that directory, certainly many other apps do have access, such as Samsung Gallery ("com.sec.android.gallery3d" on Samsung Android). Of course, in the case of the Gallery app it's just used as an image viewer, but that is not an inhibition for another app to exfiltrate these directories into a server.

What if some malicious app synced WhatsApp directories into a 3rd party server? I don't see it too hard.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: