[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 26 Mar 2018 14:12:53 -0400
From: Nick Shaw <nick.shaw@...blk.net>
To: john-users@...ts.openwall.com
Subject: Re: "No password hashes loaded" for zip2john output, pkzip
I can try, but I would have to get the user to make it which isn't likely.
I can assume they just archived and passworded the file on OS X.
I can also send the zip file as there isn't anything sensitive in it. This
was provided as a challenge (that I am failing miserably at) from a band to
get someone to "decrypt" the file holding a new song.
Here's the zipinfo:
Archive: Alice.zip
There is no zipfile comment.
End-of-central-directory record:
-------------------------------
Zip archive file size: 5345529 (00000000005190F9h)
Actual end-cent-dir record offset: 5345507 (00000000005190E3h)
Expected end-cent-dir record offset: 5345507 (00000000005190E3h)
(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 2 entries.
The central directory is 203 (00000000000000CBh) bytes long,
and its (expected) offset in bytes from the beginning of the zipfile
is 5345304 (0000000000519018h).
Central directory entry #1:
---------------------------
Users/Daniel/Desktop/Alice/
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): 2018 Jan 22 18:50:06
file last modified on (UT extra field modtime): 2018 Jan 22 18:50:05 local
file last modified on (UT extra field modtime): 2018 Jan 22 23:50:05 UTC
32-bit CRC value (hex): 00000000
compressed size: 0 bytes
uncompressed size: 0 bytes
length of filename: 27 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 f5 01 00 00 04 14 00 00 00.
There is no file comment.
Central directory entry #2:
---------------------------
Users/Daniel/Desktop/Alice/Alice.mp3
offset of local header from start of archive: 85
(0000000000000055h) 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: 2.0
compression method: deflated
compression sub-type (deflation): normal
file security status: encrypted
extended local header: yes
file last modified on (DOS date/time): 2017 Jul 18 19:44:06
file last modified on (UT extra field modtime): 2017 Jul 18 19:44:05 local
file last modified on (UT extra field modtime): 2017 Jul 18 23:44:05 UTC
32-bit CRC value (hex): d0e01601
compressed size: 5345109 bytes
uncompressed size: 5389429 bytes
length of filename: 36 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 (100644 octal): -rw-r--r--
MS-DOS file attributes (00 hex): none
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 f5 01 00 00 04 14 00 00 00.
There is no file comment.
On Mon, Mar 26, 2018 at 1:58 PM, Solar Designer <solar@...nwall.com> wrote:
> On Mon, Mar 26, 2018 at 11:36:37AM -0400, Nick Shaw wrote:
> > Updates to 1.8.0.13-jumbo as Solar suggested, re-ran zip2john, and now
> it's
> > giving me this:
> >
> > Alice.zip->Users/Daniel/Desktop/Alice/ is not encrypted!
> > ver 1.0 Scanning for EOD... FOUND Extended local header
> > Alice.zip->Users/Daniel/Desktop/Alice/ is not encrypted, or stored with
> > non-handled compression type
> >
> > Is this being caused by the folder structure within the zip? Again, in
> that
> > folder is a mp3 with a password on it.
>
> Probably not by the folder structure, but by other properties of this
> archive. Can you try to create a test zip archive (with a known
> password and non-sensitive content) using the same software that was
> used to create the target one? Try to get that one cracked. If you run
> into problems with that one as well, then provide it to JtR jumbo
> developers for testing and possibly adding support (if it's missing).
>
> I guess the MP3 file might not be compressible, and thus might not be
> stored in compressed form. Maybe there's some issue with handling of
> non-compressed data in zip2john and john. But that's just a guess.
>
> Maybe you can also run Info-ZIP's zipinfo on the original archive, and
> show us its output? On Linux, zipinfo is typically in unzip package.
>
> Thanks,
>
> Alexander
>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
