Thank you, Greg. I will try using bin extension.
Even with .bin extensions still files Libs.bin and Resources.bin arenât downloaded.
At this point I am sure there is something wrong with users profile under Windows domain, since on my PC and my profile (I am Administrator and I have no domain) everything is OK.
Still I donât understand why one of the 3 zip files is correctly downloaded.
I will report the issue to the domain administrators.
Thanks to Sascha, Arnaud, Emile and Greg!
1 Like
Do you mean the files have also been encrypted by you and wonât pass thru with this bin extension?
âBinâ is also an extension used for compressed files. As a last resort, Iâd still try with a non-existing extension (.abc) or no extension at all (still with the content encrypted).
The goal is to not give any clue to the checking software what your file is.
But Iâd understand if you donât want to try anymore (if it was me, Iâd try that still, be it just for the sake of knowing).
Believe me: you do not care to know. All I want to know is how to achive my goal correctly, the other stuff is useless to me (so many things I do not knowâŠ).
Did you try using these names (at write and read time):
Nedi1.abc, Nedi2.abc and Nedi3.abc
Do not forget to BASE64 the filesâŠ
I have just tried with .abc extensions for all files, but this is the error:
This error occurs when the file extension of the requested URL is for a MIME type that is not configured on the server. You can add a MIME type for the file extension for files that are not dynamic scripting pages, database, or configuration files. Process those file types using a handler. You should not allows direct downloads of dynamic scripting pages, database or configuration files.
Ah, thereâs a list of allowed extensions⊠What if you try with, say, jpg, which is probably allowed? (even if the encrypted data arenât valid jpg data)
I think there is no attempt that can be successful: the basic question is that there are two files of three that arenât correctly downloaded, and this, despite what Emile says, tells me (but I could be wrong, obviously) that itâs not a matter of permissions, itâs not a matter of encryption and itâs not a matter of file extension. The most reasonable matter itâs related to the user account and the Windows domain.
However I am ready to do any other test you suggested, that can lead to a solution.
Thank you all! This forum is fantastic!!
Why are you trying to circumvent the firewall rules put in place by whoever is hosting your server? The reasons some files work and some donât is that some of the files match some heuristic scan while others donât, those that do are blocked. The firewall will detect that the file is a zip even though youâre trying to mask it by renaming the file, it will open the zip and check the contents, and something in three it isnât allowing out. Speak to your host or IT department about ignoring your servers outbound data (at your own peril of course).
Hi Julian, I agree with you, but now you could explain to me why the file DLL.zip (wich contains a number of dll files) is correctly downloaded (and unzipped) and why the file Libs.zip (which also contains a number of dll files) is not.
There is another possibility here. It could be an antivirus issue. Many of them will peek inside compressed files and especially donât like those that attempt to hide their contents.
Now that youâre talking about Windows Domains and User Profiles, is this a corporate environment where the machine is locked down in some way? It could just be that some policy doesnât allow installing apps and that preventing DLLs is the way they do that.
Yes, Greg, what you say would be very reasonable, if file DLL.zip was treated as file Libs.zipâŠbut DLL.zip is downloaded, while Libs.zip isnât.
Right, but the fact that Libs doesnât say that it contains DLLs may be part of the issue. Or it could be which DLLs are in there. Have you tried using another name like LibsDLLs.zip to see if that will let you by?
Or even removing the contents one by one to see if one in particular is a problem?
It doesnât work! I renamed the Libs.zip to LibsDLL.zip, but nothing has changedâŠ
It IS a FIREWALL issue as Sasha suspected. You need to review your firewall DLP rules. It is looking for some mix of extensions/content. Your message is a known message of the Fortinet Firewall. Check with the admins of the system.
1 Like
Is there any reason why the firewall allows the user to download the DLL.zip file and instead blocks the download of the Libs.zip file?
Both contain .dll filesâŠ
There will be a certain file(s) in the libs zip that the firewall isnât allowing out of the network.
You could find out which by trying to transfer each file separately and see which are denied or ask for the firewall to be altered or encrypt the files and send them that way.
Iâm with Greg on this one, it really seems like antivirus. To the server, browser, firewall, etc. the three DLL files are equal. The MIME errors are because the web server doesnât know the MIME type to advertise for the given extension. Itâs possible to manually add a MIME type of application/octet-stream to your browser for the given extension, but it wonât matter.
The malware protection on the userâs computer sees that it is compressed content and takes a look inside. It then detects the dlls as a problem. Not any dlls, but at least one of the dlls in each of the problem files are setting off its detection. Itâs probably some awful heuristic antivirus causing a false positive.
This is why the previous advice about tampering with the file contents - not the name, extension, or MIME type - is how you may be able to defeat the detection. By messing with the first four bytes, you can make the file look like random data instead of a compressed zip archive.
The trouble becomes actually using the zip file. Youâd probably need to read the archive into memory, fix the header bytes, and use something like MBS Compression to decompress the archive in memory. Any disk access will be a potential point of failure. And that brings us to the next problem. Even if you manage to do all that, itâs likely the antivirus will flag the decompressed dlls as soon as you put them on the disk to make them actually usable.
The fact of the matter is youâre fighting against something that is designed to prevent you from getting that code onto the userâs computer. Itâs a fight I donât believe you can win. You probably need your application added to the antivirusâs whitelist, which is likely impossible if this is a corporate environment.
Rock, meet hard place.
1 Like
Again, it is a known issue related to DLP. Check with the admins if they are using Fortinet products, if so, it is due to DLP rules. If you send an offending sample to them they can inspect what part of the content triggered the âblock leakageâ rule.
If it really is just the firewall, then encrypting the archive will work, while tampering with the archive will probably work. It canât peak inside what it canât understand.