If want to circumvent deep inspection, you need to follow some rules too to avoid the system detection. If you use base64, the system inspect it anyway.
Right. I meant messing with the header bytes, changing the extension, and making sure the server uses application/octet-stream as the MIME type. It needs to look nothing like a compressed archive. Simple Base64 is easy to defeat. Encryption is the better option.
Some servers (or folders of those servers) donât allow application/octet-stream for security reasons. If he works with the admins they can help him. But if he needs to circumvent the rules, he needs to make the file stream unknown and promote it as a 7bit char stream imitating a text, and rebuild it on the other side. Some proprietary encoding of the zip followed by base64 may be enough.
Well, thatâs what we have tried since almost the beginning of this thread and it hasnât worked either yet.
Well to be fair, I meant to say ânot just the nameâ and so on. I donât see any evidence in this thread that the file content has been changed, only its metadata.
This is the post, in the middle of the âencrypt attempt chainâ where I guided Nedi to encrypt the files:
I get that. It has been suggested, but I canât see any evidence that it has actually been tried.
Post number 13 (i.e. just after the one I quoted) reveals Nedi actually tried 
This didnât work, so I assumed it would need both encrypted content and a different extension.
But later, it wasnât clear whether Nedi tried with a different extension and encrypted content, both at the same time. I answered it would be a good attempt, but the discussion hasnât gone further there.
If you just do a Base64(ZipFile) you are not running away of a deep inspection. The system could suspect of a base64 encoding and look inside and find a zip file and deny it.
EncodedForDownload = Base64(ProprietaryScrambler(ZipFile))
If your ProprietaryScambler() produces just chars from asc(31) to asc(126) you can remove the Base64() part and do it directly.
@Thom_McGrath: I tried encrypting the files using the code of Arnaud (I also added b1.Close and b2.Close that were missing), but without any result.
In the meanwhile I found one interesting thing: the file Resources.zip contains 17 png files, 1 ico file and 1 wav file. Since the last two werenât used in the program any more, I deleted them from the zip fileâŠand now the file Resources.zip is correctly downloaded.
Since DLL.zip (which is correctly downloaded) contains 6 dll files, while Libs.zip contains 11 dll files, I thought that the problem could be the number of files contained in my zip file, so I tried to reduce it, but with no success. I leaved a single dll file in Libs.zip, but again with no success.
Probably something related to content, not file types, not number of files. Probably a random number of bytes in such files were hurting some rule, maybe even something sensible in their metadata.
Donât do that. Keep the content consistent with the file type.
They arenât required either. As soon as the BinaryStream object gets out of scope, the file is automatically closed.
Or perhaps its size. Do the problematic files have a bigger size than the working ones?
Why not?
If the content gets encrypted, thereâs no longer a linked file type anyway.
Because if the server says âthis is a jpegâ and the content isnât a jpeg, that looks suspicious.
1 Like
@Arnaud_N
About the b2.Close obviously you are right!
About the file size, DLL.zip (which is correctly downloaded) is the biggest one (13124k), while Libs.zip is 5700k)
At this moment I guess that it is useful to explain in detail the app and its goal.
I am using Xojo 2019r1.1 on Windows 10 Pro environment.
Since a couple of year in my apps I implemented an auto-update feature, which works like this:
- I have a web space on a Windows server. When I modify an app, I upload the new version of the exe in a folder of my web space. Before doing this I have to change the extension to .txt otherwise the server will not allow me to download an executable file; so MyApp.exe becomes MyApp.exe.txt,
At the same time I upload a simple text file which shows the version of the app in the web space.
This way my apps can download and copy a new version of the executable, when necessary. - If I add components in my app, or install a new version of some plugin, the auto-update function must download the new dlls as well as the new executable. These new dll may be in the application folder (64-bit app) or in âMyApp Libsâ folder. So I added in the simple text file containing the new executable version, three information: download DLL (the 64-bit app dll), download Libs (the dll of âMyApp Libsâ folder), download Resources (if I added some picture in my app: the content of âMyApp Resourcesâ folder). In my web space I upload three zip files: DLL.zip, Libs,zip and Resources.zip.
- When I run the app from my computer everything works fine (I am administrator of my computer and I am not in a Windows domain). The problems come, as I said in this thread, when the app is run by my customer, who is a ânormalâ user (not an administrator) and is in a Windows domain.
With these informations somebody might have a new idea, or might tell me am alternative way to do what I want.
Ok, point taken.
So, there must exist extensions that are both allowed there and canât be checked (a jpeg can be âopened as a pictureâ and contains known bytes, but some formats donât even have a specific âsignatureâ).
What about a simple txt file, which has not a defined format?
In which folder are you trying to download the file?
Try to see if there are Windows Defender messages in the Windows Notifications listing.
It could simply be windows defender blocking files to be downloaded/saved to some of the folders (User home, user documents etc.)