0

A follow up to my 7,5 years old question. Back 10-15 years ago, when I wanted to send an executable file over Gmail from my PC, all I had to do was to change file's extension to some meaningless one or compress that file with a password.

The mentioned question (and all answer to it) proven that contents of ZIP file can be browsed (or even changed) without knowing the password used to build up such ZIP archive. But I still had some (stupid?) faith in 7zip.

Today it turned out that mobile Gmail for Android "knows" that I am trying to send executable .apk file (or prevents me from doing so for any other reason) even when I am:

  • sending as plain file (obviously),

  • changing .apk extension to .dat or some other,

  • compressing with ZIP with no password,

  • compressing with ZIP (ultra compression) and encrypting archive with a password,

  • compressing with 7ZIP (ultra compression) and encrypting archive with a password,

  • using an 7 years old idea of double compression:

    • compress .apk file into .zip file without password,
    • compress resulting .zip file again into another .zip file with password / encryption.

The last one actually "killed me". If Gmail "knows" what type of file am I sending, even if I treat that file with a double compression, adding a password-based encryption on top of it, then how can I treat files sent over Internet (even encrypted ones) as secure or even safe?

I am by no mean an expert. This question may sound like a naive one. But, still... I wonder, why should I encrypt files at all, if a simple mail client is able to "break through" password-protected file and tell itself, what type of file is contained there?

14
  • 2
    You appear to be generalizing a particular encryption method to all encryption methods. You also appear to be neglecting that the zip archive will have an unencrypted manifest. So, you are making the whole thing to be a much bigger issue than it really is. Just because your expectations of full and total protection is not met in this one program without reading the prompts within the program, does not mean that there is a systemic problem with all encryption. It feels like I mentioned this before ... – schroeder Nov 3 '20 at 8:19
  • Can you please explain what you mean by "knows"? – John Wu Nov 3 '20 at 8:25
  • Did you use 7zip's function to also encrypt filename? The little checkbox right under the password entry field? That detail appears very, very relevant to your question and situation ... – schroeder Nov 3 '20 at 9:31
  • 1
    Of course Gmail has rule engines to recognize apks and discard them, at least when not encrypted, and by analysing the payload. Technology changed over the years and Gmail does not use static analysis engine – usr-local-ΕΨΗΕΛΩΝ Nov 3 '20 at 10:25
  • 1
    What exactly is the question? Whether or not Google can read the content of the encrypted archive? Or how to smuggle data past Google's eyes? The title suggests the former, the body the latter. – MechMK1 Nov 3 '20 at 12:15
1

This is the classic weapon/armor problem.

Sysadmins do their best to reject content that they think possibly harmfull, while users do their best to hide their data.

Here the most probable detection way used to detect the real content is the name of the file which is (by default) left unencrypted when you put it in an encrypted zip file.

So on a public network where no protection exist againts unreadable data, you should:

  • rename the data under an unrelated name
  • store it in an encrypted zip file, still with an unrelated name

On corporate network, encrypted files are often rejected by the mail servers, precisely because it is not possible to scan them for possible malwares. In that case, there are no bullet proof way except steganography, but encoding the payload as base64 in a plain text file is often enough.

5
  • Or tick the box in 7zip to encrypt the filenames ... – schroeder Nov 3 '20 at 13:48
  • @schroeder Answered above. I don't have such option / possibility. – trejder Nov 3 '20 at 14:14
  • I have followed your advise and this worked. Most likely renaming file twice (both source file and encrypted archive) did the magic. However I am still not confident about my main concern, expressed in my question. If 3rd party software can check files inside password-protected archive then something seems to be wrong here. – trejder Nov 3 '20 at 14:35
  • 2
    @trejder No, it's not. Neither google, not any other third party has access to the contents of the file. They simply make disallow archives containing .apk files. – MechMK1 Nov 3 '20 at 14:37
  • @trejder you mean, it can read the in-the-clear file manifests in the compressed archives made by the program you used? No, that's not a cause for concern. You just need to use a method that also encrypts the manifests. – schroeder Nov 3 '20 at 15:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.