Skip to content

add testdata for files with regular ZIP passwords. #25

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
armijnhemel wants to merge 2 commits into
base: main
Choose a base branch
from
Open

add testdata for files with regular ZIP passwords. #25

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0c2cf03
add testdata for files with regular ZIP passwords. Different unpackers
armijnhemel Jan 15, 2026
5e43670
add note about directories never being encrypted
armijnhemel Jan 15, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
146 changes: 146 additions & 0 deletions testdata/readme.password
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,146 @@
# Encryption

Entries in ZIP files can be encrypted with a variety of methods. The standard
password encryption in ZIP is weak and prone to a known plaintext attack. If an
entry is encryted with this encryption method then the "encryption" bit in the
general purpose bit flag should have been set.

In case an encrypted entry is found and there is no password available then it
still possible to do structural checks (extract file name, CRC32, and so on)
and verify if the data is sound and skip the encrypted data, while unpacking
data that has not been encrypted (such as directories, which are only stored).

This can be easily demonstrated by building an encrypted ZIP file with a file
inside a directory:

```
$ zip -r zip_password.zip dir -e -Ptest
adding: dir/ (stored 0%)
adding: dir/bar (stored 0%)
adding: dir/empty/ (stored 0%)
```

and then extracting it with `unzip`. If the correct password is not given the
directory (which has not been encrypted, but merely stored) will still be
unpacked/created:

```
$ unzip zip_password.zip
Archive: zip_password.zip
creating: dir/
[zip_password.zip] dir/bar password:
skipping: dir/bar incorrect password
creating: dir/empty/
```

and no files will have been unpacked:

```
$ find dir/ -type f | wc -l
0
```

Interestingly, and unlike `unzip`, when running `p7zip` an empty placeholder
file will be created:

```
$ 7z x zip_password.zip

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,8 CPUs Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz (506E3),ASM,AES-NI)

Scanning the drive for archives:
1 file, 482 bytes (1 KiB)

Extracting archive: zip_password.zip
--
Path = zip_password.zip
Type = zip
Physical Size = 482


Enter password (will not be echoed):
ERROR: Wrong password : dir/bar

Sub items Errors: 1

Archives with Errors: 1

Sub items Errors: 1
```
The directory `test` will now contain an empty file:

```
$ find dir/ -type f | wc -l
1
$ du -h dir/
0 dir/empty
0 dir/
$ du -h dir/bar
0 dir/bar
```

Directories seem to be not encrypted, so they can always be created, as can
be seen in the field `file security status` when using `zipinfo` on a file and
searching for a directory entry:

```
Archive: zip_password.zip
There is no zipfile comment.

End-of-central-directory record:
-------------------------------

Zip archive file size: 482 (00000000000001E2h)
Actual end-cent-dir record offset: 460 (00000000000001CCh)
Expected end-cent-dir record offset: 460 (00000000000001CCh)
(based on the length of the central directory and its expected offset)

This zipfile constitutes the sole disk of a single-part archive; its
central directory contains 3 entries.
The central directory is 231 (00000000000000E7h) bytes long,
and its (expected) offset in bytes from the beginning of the zipfile
is 229 (00000000000000E5h).


Central directory entry #1:
---------------------------

dir/

offset of local header from start of archive: 0
(0000000000000000h) bytes
file system or operating system of origin: Unix
version of encoding software: 3.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 1.0
compression method: none (stored)
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2026 Jan 15 21:15:18
file last modified on (UT extra field modtime): 2026 Jan 15 21:15:18 local
file last modified on (UT extra field modtime): 2026 Jan 15 20:15:18 UTC
32-bit CRC value (hex): 00000000
compressed size: 0 bytes
uncompressed size: 0 bytes
length of filename: 4 characters
length of extra field: 24 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
Unix file attributes (040755 octal): drwxr-xr-x
MS-DOS file attributes (10 hex): dir

The central-directory extra field contains:
- A subfield with ID 0x5455 (universal time) and 5 data bytes.
The local extra field has UTC/GMT modification/access times.
- A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes:
01 04 e8 03 00 00 04 e8 03 00 00.

There is no file comment.
```

Other encryption methods are stronger. Depending on the encryption method the
encryption bit flag might or might not be set. For example: for AE-x it will
be set (APPENDIX E), while for other encryption methods it might not. The flag
should not be used as the sole indicator of encryption.
Binary file added testdata/zip_password.zip
View file
Open in desktop
Binary file not shown.
Loading