Package: foremost
Version: 1.5.7-8
If foremost is launched with "-t all" option then recovered
zip files has an extra byte.
Prepare a test file
dd if=/dev/urandom of=random.data bs=1k count=1000
zip test.zip random.dat
cp -pi test.zip test.img
truncate --size 1025000 test.img
Try to recover the zip file
foremost -o result-orig -t all test.img
Compare
ls -l test.zip result-orig/zip/00000000.zip
-rw-rw-r-- 1 user user 1024333 Apr 27 18:58 result-orig/zip 00000000.zip
-rw-rw-r-- 1 user user 1024332 Apr 27 18:56 test.zip
7z t result-orig/zip/00000000.zip
...
WARNINGS:
There are data after the end of archive
--
Path = result-orig/zip/00000000.zip
Type = zip
WARNINGS:
There are data after the end of archive
Physical Size = 1024332
Tail Size = 1
Everything is Ok
...
"-t zip" works correctly
foremost -o result-orig-zip -t zip test.img
ls -l result-orig-zip/zip/00000000.zip
-rw-rw-r-- 1 user user 1024332 Apr 27 19:21 result-orig-zip/zip/00000000.zip
I think it happens due to different description of signatures used
for "zip" and for "all" mode in the state.c file:
301 init_builtin(state,
302 ZIP,
303 "zip",
304 "\x50\x4B\x03\x04",
305 "\x4b\x05\x06\x00",
306 4,
307 4,
308 100 * MEGABYTE,
309 TRUE);
548 init_builtin(s,
549 ZIP,
550 "zip",
551 "\x50\x4B\x03\x04",
552 "\x50\x4b\x05\x06",
553 4,
554 4,
555 max_file_size,
556 TRUE);
I suggest to apply the following patch:
cat debian/patches/avoid-zip-tail-byte.patch
--- a/state.c
+++ b/state.c
@@ -302,7 +302,7 @@
ZIP,
"zip",
"\x50\x4B\x03\x04",
- "\x4b\x05\x06\x00",
+ "\x50\x4b\x05\x06",
4,
4,
100 * MEGABYTE,
