This app, using HTTPSocket, has to download from a page of my website 3 zip files.
This files are:
DLL.zip which contains some .dll files
Libs.zip which contains some .dll files
Resources.zip which contains .png image files
All of them have been uploaded with the extension .txt, to avoid problems with the server (Windows Server)
The first file (DLL.zip.txt) is correctly downloaded, then is renamed to DLL.zip, and finally is unzipped: everything is ok.
When my app tries to download the second file (Libs.zip.txt) the downloaded file is a small HTML file containing the error message “The transfer attempted appeared to contain a data leak”
I don’t know what is the problem and, of course, which is the solution.
The first file (DLL.zip.txt) is a .zip file which contains some .dll files, and it is downloaded with no issues.
The second file is very similar: a .zip file which contains some .dll files
So I don’t think it’s a Firewall matter (but I may not be right)
I’d vote for giving it a try… The fact alone that you have to use a “.txt Extension Trick” to avoid problems with the Server… But i may be wrong too. Who knows without trying?
Perhaps you could try swapping both files, as a test, to determine if it’s always the 2nd one which fails or always the same per-content file?
This may lead to further clues.
Hi Arnaud, I have done what you suggested, swapping the file downloads, but the issue still remains: DLL.zip is correctly downloaded and unzipped, while Libs.zip and Resources.zip are not downloaded.
The file that is downloaded has the following content:
Attention!!
The transfer attempted appeared to contain a data leak!
URL: http://www.lediafreguglia.it/MartiniNew/Libs.zip
User name: FORNASINIDA
Group name: Fsso-grp-INTERNET_UTENTI-Gatteo
If I run the program from my PC (I am an administrator user and I am not in any domain) everything works perfectly.
The issue comes when the program is run by my customer, who is in a LAN and is a “normal” user in a Domain.
This lets think there is an authorization or Firewall problem, but the strange thing is that DLL.zip is correctly handled.
Hi Nedi,
Ok, so it’s related to the content of the file itself.
I’d try one of these things, if one suits your needs, which would invalidate the check of the “unwanted” software:
• Encrypt the file before sending it to the server and decrypt it. You’d do both with your app, so it knows how it was encrypted when you decrypt it. Perhaps just changing (inverting) the first bit would make it (the blocking software wouldn’t be able to read the content as zip). Or use EncodeBase64 to write the data to the file in a manner that the software wouldn’t recognise it’s a zip file.
• Use another format than zip.
It all depends on how your making and using the files.
The DLL,zip contains the DLL generated by the compiler of a 64 bit app on Windows.
Libs.zip contains the dll generated by the compiler in the “Application Libs” folder.
Resources.zip contains what is generated by the compiler in the “Application Resources” folder.
I have some difficulties encrypting all these files or creating something else instead of a zip file.
Ok, if you can run an application after the zip has been created, there’s hope.
Here’s one simple way you can encrypted/decrypt a file:
Public Sub EncryptFile(FromFile As FolderItem, ToFile As FolderItem)
dim b1,b2 As BinaryStream
dim s As String
try
if FromFile<>nil and FromFile.Exists and ToFile<>nil then
b1=BinaryStream.Open(FromFile) 'Load the input file
b2=BinaryStream.Create(ToFile,True) 'Create the output file
s=b1.Read(b1.Length) 'Read the whole input file
s=EncodeBase64(s) 'Simple encoding
b2.Write s 'Write to the other file
end if
Catch e
MessageBox "An error occurred: "+str(e.ErrorNumber)
end try
End Sub
Just note: if your zip file is big (huge), the code may take some time, but probably not.
So, you’d make the zip file, use the function above with the zip file as input and your own file as output.
To decrypt the file on the other end, use the same method with just replacing “EncodeBase64” by “DecodeBase64”.
This is still an attempt: the code above was written from scratch just now and we have to validate it as a working solution (I expect it is).
Hi Arnaud, even with encrypted files nothing has changed: the DLL.zip file is correctly downloaded and unzipped, while Libs.zip and Resources.zip aren’t downloaded (the error message is always the same).
I don’t know if there is something else I can do…
The next step would be to try with a different file name (and extension). If your file is named, e.g. “MyFile.abc” and its content is encrypted, I can’t see how the “software” could still flag the file… (unless there’s a size limit?)
So, my next attempt would be to rename each file to a known name (and another extension, like “abc”); when you receive them, change them back accordingly (for testing, you can just see whether the download works and stop there).
I agree about the extension. Web servers and clients may interpret things with a .txt extension as actually being text. I suspect that if you were to use .bin instead, these problems would cease.
Remember, internet protocols are highly dependent on mime-types. They are assigned by many servers using a lookup table that converts from extension to mime-type, so choosing the wrong one may cause the data to be transferred as text instead of binary data.
I agree with all of you, but…there is still an unanswered question: why DLL.zip is correctly downloaded, while Libs.zip and Resources.zip are not?
However I will try using other extension (.abc as Arnaud suggested, or .bin as Greg suggested).
Thank you to all of you for your time! I will inform you of the t est result.
When files are downloaded, binary items are encoded using something like base64, but text is sometimes not. My suspicion is that the socket is dropping all data after a chr(0) somewhere in there because it’s not encoded properly. Just try the extension thing, I suspect it’ll work.
