Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 3 Sep 2021 14:13:23 +0200
From: magnum <>
Subject: Re: Pkzip Hash

On 2021-09-03 13:42, Cameron Palmer wrote:
> I am looking at a file that contains a hash produced by zip2john
> ./$pkzip$2*2*1*0*8*24*766a*36edfc284d1b1ba0d35f068099947bb13a81d8b6ae0d62c40ae086513fa83b0827b315b6*3*0*1cd331*1d1000*80c8926f*0*39*8*1d*81f4*./*$/pkzip$
> Is this an older hash type? $pkzip$

Yep, it's the oldest version of zip archives still in common use. Newer 
ones would produce something starting with $zip2$ or $zip3$. This older 
type is faster to attack. Unfortunately we do not yet have GPU support 
for that format, but hashcat has.

> The zip contains both a zImage and jffs2.img file. I assume the zImage is for Renesas SuperH processors.
> I’ve tried a couple of known plain text attacks against what I thought the first 12 bytes of the jffs2.img might be, but any advice as to what I might try in terms of brute forcing?

Using guessed magic like that only works if the corresponding file in 
the attacked archive is *stored* (and encrypted), not deflated. If it is 
deflated, your "plaintext" has to be deflated as well, with the *exact 
same parameters and virtually the same version of deflate code* as the 
file in the encrypted archive. There are many moving parts and it takes 
a while to understand it all. Basically, your only chance to succeed 
with that is if one of the files is some standard and known one such as 
a GPL LICENSE file, where you have the exact same full file (confirmable 
with CRC and sizes).


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.