Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.