1

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?

trejder
  • 3,329
  • 5
  • 23
  • 33
  • 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 03 '20 at 08:19
  • Can you please explain what you mean by "knows"? – John Wu Nov 03 '20 at 08: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 03 '20 at 09:31
  • BTW, I would assume that the **server** rejects your file, not the client mail application... – Serge Ballesta Nov 03 '20 at 10:25
  • 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 03 '20 at 10:25
  • Encode the executable as base64, compress the base64 file and send. – ThoriumBR Nov 03 '20 at 11:16
  • 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. –  Nov 03 '20 at 12:15
  • @schroeder You appear to be generalising that each and every piece of software out there that deals with 7zip has this functionality. Unfortunately, not. My files and folders browsing client (namely Solid Explorer) only offers compression type selection (Zip or 7Zip), compression level (from None to Ultra) and "Protect with password" option. There is no separate option for encrypting filenames that I can find in my PC version of 7zip for Windows. – trejder Nov 03 '20 at 14:14
  • @JohnWu By "knows" I mean that whatever I do to a file (listed in this question and in linked one) mobile Gmail still "knows" that I am trying to send .apk file and disallows me from doing so, by displaying a proper message ("Couldn't send attachment"). – trejder Nov 03 '20 at 14:18
  • @SergeBallesta Your assumption is most likely correct. The error message appears n client mail application and user is blocked from even sending such message (with such attachment), but -- as we all know -- Gmail sends files to its servers even during message compose, so I assume that ultimately it is Google server who rejects attachment. – trejder Nov 03 '20 at 14:20
  • @ThoriumBR Sounds like a good idea, unfortunately my mobile client (file browsers), similairly to _schroeder_ suggestion does not have such functionality. I can only archive files in zip or 7zip. There is a separate "Encrypt" option, but it creates ".sec" files of file format or encryption method that I don't know. I can decrypt such files in Solid Explorer itself and I can send them over Gmail, but recipient of my message don't know what software to use to decrypt them. – trejder Nov 03 '20 at 14:24
  • @MechMK1 For me the question is pretty straightforward and self-explanatory. If Gmail servers are able to check type of my files, stored inside password-protected archives then how can I consider them safe and how can I transfer sensitive data in this case. For me security means that the only entities able to read it is sender and recipient and no 3rd party in between. The whole Gmail blah-blah is just an example. – trejder Nov 03 '20 at 14:26
  • No generalization on my part at all. I'm using 7zip for Windows. You said that you had "faith in 7zip". Did you mean that you had faith in the compression format or the program? That's why I posed a *question*. – schroeder Nov 03 '20 at 15:22
  • So, now that we have more info; you know that manifests are in the clear (from your 7 year old question) you use different compression methods in the Solid Explorer app on Android. You do *not* check if the manifests are still in the clear, and then ask "why should I encrypt files at all?" Your issue appears to be that that you are using a known weakness and an app that does not do what you want. It has nothing to do with "encryption" at all. – schroeder Nov 03 '20 at 15:27

1 Answers1

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.

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • Or tick the box in 7zip to encrypt the filenames ... – schroeder Nov 03 '20 at 13:48
  • @schroeder Answered above. I don't have such option / possibility. – trejder Nov 03 '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 03 '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. –  Nov 03 '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 03 '20 at 15:29