I'm creating an encrypted zip file using DotNetZip using WinZip AES 256. However I'm able to read the directory and even to remove some of the zipentries without having the encryption key.
As far as I understand the directory visibility is a limitation of the Zip format. I just wonder, if this also applies for any changes in removing / adding components to the zip file or does there exist a way for preventing such changes.
EDIT:
A quick read of Zip File Format seems to show, that double zipping seems to be the only solution to prevent random removal / addition of comoponents in a zipfile, regardless of encryption of the single entry.
From the kb of the Winzip last update last updated 20 Feb, 2013:
To hide the names of the files in your encrypted Zip file, you can double zip them. To do this:
So I'll say no :-)
Winrar has an option to encrypt the filenames, sadly the algorithm isn't public.
Related
I have this C# code which unzip a zip file.
ZipFile.ExtractToDirectory(_downloadPath, _extractPath);
To test download process, I use the file size and compare them. But for extraction process, how do we ensure that the extraction process is successful? It could be corrupted (extraction process stop half way). Can I use file count to compare?
I suggest you go ahead and compare md5 hash of files in archive and the ones that were extracted. Though it is definitely not the fastest process, this way you'll be 100% sure the data is not corrupted.
You can find how to get md5 of a file inside archive here:
I have to take the directory of a file in zip file
Context:
To save more space, I want to further compress some files in a zip archive with an algorithm, and other files in same archive with another algorithm. Later I need to revert the process to get the original zip archive, because the zip files are owned by users.
How to locate compressed bits of certain files in a zip archive for further processing?
Language: Guess this kind of code is usually C/C++ for performance, but C# is good too.
OS: Windows Server 2012 R2 or later.
Edit:
I learned that in zip(zlib) format, compressed files are organized in blocks. We should be able to locate the files by searching headers. Still checking on how to code it.
The zip file format is fully documented. e.g. http://www.fileformat.info/format/zip/corion.htm
You can find other sources and descriptions easily.
What you have to do is to read bytes according to the format and you have exact knowledge about where a certain file's compressed bits are. You can find open source libraries for this or you can roll your own in your preferred language.
As a side note, compressing an otherwise compressed file in a zip archive may not worth the efforts.
Is it possible to encrypt a Zip file? I know encryption is used to make .txt files unreadable until decrypted with a key. Although I want to do the same with a .zip file.
I have multiple files I want users to download from the internet through my program I'm creating, so I thought I'll compress them files in a .zip and then encrypt the Zip for added security. (I don't want users to access the file within the .zip without a serial code)
I was going to keep the 'serial key' in a database online which the program would get.
Am going about this in the wrong way?
Both DotNetZip and SharpZipLib support encrypting the contents of zips and are free.
Use the dotnetzip library to perform your zipping/unzipping operations.
It supports AES encryption. From the website:
The library supports zip passwords, Unicode, ZIP64, stream input and output, AES encryption, multiple compression levels, self-extracting archives, spanned archives, and more.
Yes you can use third party zip libraries as shown by other answers, but keep in mind that your method of protecting files is rudimentary... it would not be terribly difficult to observe your program operating and recover the files after your program helpfully decrypts them. If you are storing the key as a constant in the program, that is pretty trivial to extract as well.
Software protection is a complex field, and it's very difficult to prevent determined users from viewing data that is stored on systems they control. Commercial software goes to great lengths to prevent this, and the solutions are quite complicated. (e.g. try hooking a debugger to Skype and see what happens)
I am using Sharpziplib version 0.86 to extract a zip file. It is working fine but while extracting a winzip file through code,Lastwritetime is changing in seconds...
Have used this also File.SetLastWriteTime(fullPath, theEntry.DateTime);
Actual file Lastwritetime:4/8/2010 2:29:03PM
After zipping that file using winzip and while extracting that file using the code,extracted file Lastwritetime changes to 4/8/2010 2:29:04PM...Is there any fix for this???
I got this response from Sharpziplib Forum
Hi
This appears to be a WinZip bug. I have not noticed this before.
I did this test:
1) Use WinZip to add a file to a zip. In WinZip click Properties and Details. Look through the details list and find the file time stamp.
2) Use SharpZipLib to create a similar zip file with the same inputfile. Open the result in Winzip and look at the Properties > Details for the file time stamp.
My input file has a Modified timestamp (file properties) of 2010-12-14 15:51:28 and in my test, SharpZipLib stored it correctly in the zip, while WinZip stored it as 2010-12-14 15:51:30
In other words WinZip added 2 seconds when putting it into the zip.
After extracting (either with WinZip or SharpZip), the Modified is now 15:51:30 instead of the original 15:51:28.
it is amazing that such an obvious bug in WinZip can have gone unreported and unfixed for so long. If you have a paid version you should certainly raise a bug fault with them.
I just remembered something about 2 second granularity in the old 8.3 file system timestamps.
Quick google found this ...
Quote "Original DOS file system had only 32 bytes to represent a file in the directory. The very restrictive 8.3 filename and the limited granularity (2 second) in file date are corrected in the Win32 file systems (VFAT)."
from http://www.xxcopy.com/xxcopy15.htm
The Zip format only allows 2 second granularity in the standard time stamp entry.The date and time are encoded in standard MS-DOS format.
An optional NTFS Extra Data field (0x000a) can be included, which may hold last modification time, last access time and creation time. WinZip does not appear to create it. SharpZip will use it if present but as far as I can see, it is not created when using FastZip to create a zip. That might be a useful option to add to the code. You can certainly create it manually if using ZipFile.
Hope this helps,
David
I think it might just be the operating system that is causing this. I've tried what happens in Explorer. I've got a text file with a modified time stamp of 17:06:45. I right click on the file and choose Send to | Compressed (zipped) folder. Then I right click on the new zip-file and choose Extract All... followed by Next, Next, Finish. Now the extracted text file has a time stamp of 17:06:46.
The same happens when I use 7-Zip, or WinRar. But then it only happens when using a .zip file. If I let them create a .7Z or a .RAR file the time stamp isn't changed.
Found an article on Wikipedia about the zip format. If you search it for "seconds" you'll find a section describing that the ZIP file system mimics the DOS FAT file system, which only has a time resolution of two seconds.
I have an automated job that pulls files that are uploaded to our servers via a client facing site using xcopy.
Is there any way to only pull files that are fully uploaded?
I have thought about creating a second "inProcess" folder that will be used for uploading and then move those files once fully uploaded, but that still creates a window of time when the file is in transition to a "Done" folder...
Any thoughts?
use the .filepart extension for temporary files.
It's probably the most simple and clear way of doing this.
WinSCP does this.
You can upload an MD5 hash of the file and then upload the file and if the file uploaded doesn't match the MD5 then it's not finished (or if it takes to long, perhaps it didn't upload properly)
MD5 is often used to check the integrity of a file by creating a hash that represents the file. If the file varies at all, it will almost always (as in, basically never for our purposes) generate a different MD5 hash. The only reason a file would not match it's previously uploaded MD5 hash is if it wasn't finished or the MD5/file was corrupted on upload.
There is also this. but it's perl and from expert exchange (ick)