キャプチャーザフラッグのサンプルを実行していたところ、ファイルのハッシュが提供されました。John The Ripperを実行し、サンプルのパスワードを取得しました。
問題は、ハッシュが私に与えられたということです。与えられていない場合、そのファイルのハッシュを見つける方法はありますか？
パスワードを破るために解決する必要がある2つのポイントがあります：ハッシュと暗号化アルゴリズム。
私はパスワードで保護されたzipファイルを使って練習していたので、zip 2.0か何かまたはある種のAESを使用していると思いましたが、Googleの助けを借りてそれを理解できます。
しかし、私が見つけられないのは、そのハッシュされたデータのzipファイルのメタデータにアクセスする方法です。これは標準であるため、パスワードを保存するときに何かを圧縮するためにアルゴリズムを含める必要はありません。ただし、ある種のハッシュが必要です。
パスワードで保護されたzipファイルのこの例で、これがどのように行われるかを誰かが知っていますか？
現在、MacBookProを使用しています。
パスワードハッシュはファイルから抽出されません。John the Ripper（JtR）は実際にはこれを行いません。JtRのコードをダウンロードして、それがどのように行われるかを理解することができます。zip2johnおよびrar2johnを使用して.zipおよび.rarファイルのいわゆる「非ハッシュ」情報を取得する方法に関する小さな記事を次に示します。http：//www.cybercrimetech.com/2014/07/how-to-cracking- zip-and-rar-protected.html
誤称を修正するために、JtRは実際にはファイルから「ハッシュを取得」しません。たとえば、rar2johnコードに記載されているように、ファイルから特定の情報を抽出します。
出力ラインフォーマット：
*
*「rar-hp...」オプションで暗号化されたファイルのタイプ=0の場合
* archive_name：$ RAR3 $ \ * type \ * hex（salt）\ * hex（partial-file-contents）：type ::
:: archive_name
*
*「rar-p...」オプションで暗号化されたファイルのタイプ=1の場合
* archive_name：$ RAR3 $ \ * type \ * hex（salt）\ * hex（crc）\ * PACK_SIZE \ * UNP_SIZE \ * 0 \ *
archive_name \ * offset-for-ciphertext \ * method：type :: file_name
*
* また
*
* archive_name：$ RAR3 $ \ * type \ * hex（salt）\ * hex（crc）\ * PACK_SIZE \ * UNP_SIZE \ * 1 \ *
hex（完全に暗号化されたファイル）\ * method：type :: file_name
したがって、上記のように、「パスワードハッシュ」は抽出されません。また、ファイルが「完全に」暗号化されているとは完全に信じられません（同様の質問に答える他の人が示唆しているように）。代わりに、ソルトなどの重要な暗号化されていないファイルアイテムが取得され、「非ハッシュ」が生成されます。これらのアイテムは、復号化をテストするためにさまざまなパスワード推測を使用してJtRによって使用されます。zipまたはrarパスワードハッシュ生成関数を使用して、推測からハッシュを作成し、それを使用して暗号化キー値を生成します。生成された暗号化キーの値は、暗号化されたファイルの小さく、抽出され、明確に定義された部分に対してテストするために使用されます。
したがって、JtRは、古いpassword-hash-checker-rainbow-table-lookup-thingyに送信できる「パスワードハッシュを抽出」していませんが、次善の策、つまり重要なクラッキング情報を抽出しています。解読する手順は基本的に次のとおりです。1）パスワードの推測からハッシュが生成され、2）復号化が成功または失敗する（多くの失敗）ことを確認するためにいくつかの追加手順が追加され、3）繰り返します。rarクラッキングを非常に困難にしているのは、rarファイルごとに異なるソルトであり、さらに重要なことに、復号化テストを実行する前に必要なハッシュの反復回数が大きく変動することです。新しいzipプロセスも同様ですが、反復は可変ではなく（最後に確認しました）、多少簡単になります。
これは、尋ねられた「それがどのように行われるか」の要点であり、答えは、ファイルがクラックされる直前まで、zipファイルの実際のパスワードハッシュを取得しないことです。
質問のCTF演習の例は、誤解を招く可能性があります。与えられた「ハッシュ」は、古いクラッカーによる学生のクラッキングプロセスを簡素化するために演習用に準備された単純なパスワードハッシュである可能性があります。または、特定のzip2john「非ハッシュ」である可能性があります。推測するJtR-短い、一般的な、またはその両方。質問者は、どちらの方法でも検証するための「ハッシュ」または「ハッシュファイル」を提供しませんでした。
なぜハッシュが必要なのですか？zipファイルは圧縮されてから暗号化されます。これは、認証ではなく、復号化するため、ファイルにハッシュを保存する必要はありません。使用する暗号化に応じて、ファイルに保存できるのはソルトだけです。
どのように行われたかはわかりませんが、John the Ripper（JtR）には、zipファイルからハッシュを作成する小さな実行可能ファイル（zip2john）があります。コードが開いているので、これがどのように抽出されるかを見ることができます。もちろん、これはファイルがPKZIP暗号化で暗号化されていることを前提としています（したがって、たとえばWinRarによって作成されたファイルでは機能しませんでした）。
私は7zipで圧縮され、単純なパスワードが使用され、まともなワードリストを備えたJtRがミリ秒でそれをクラックした単純なファイルでそれを試しました。ここで（オプションで）自由に与えられたワードリストがトリックを行いました。
乾杯
John The Ripperの主要な開発者の1人は、アーカイブ、特にpkzip2アーカイブのパスワードの解読がどのように機能するかを明らかにしています。
これは私の質問であり、JtRメーリングリストでの回答です。
2021-06-03 10:28に、MatthiasBraunは次のように書いています。
ソースファイル（ https://github.com/openwall/john/blob/bleeding-jumbo/src/zip2john.c ）でzip2johnの出力の説明を読んだ後、これが私の現在の仮定です。アーカイブには含まれていないため暗号化に使用されるパスワードのハッシュ（デフォルトでは、JtRはワードリストを使用してzip2johnの出力のDA位置に格納されているデータを復号化し、結果に対してCRC32を実行し、そのチェックサムをCR位置に格納されているチェックサムと比較します。
しかし、大きなファイルのパスワードを解読する場合、復号化にはかなりの時間がかかり、各パスワードの推測にコストがかかると思います。
あなたは基本的に正しいです。
JtRはpkzip2アーカイブをどのようにクラックしますか？
まず、zip2johnは、作業を最小限に抑えるために、アーカイブから最小のファイルを選択するだけです。ただし、小さなファイルがない場合もあります。
2番目のトリック：pkzipアーカイブには、各ファイルのパックされたデータのごく一部の別の小さいチェックサム（1バイトまたは2バイト）も含まれています。それが一致しない場合は、早期に拒否できます。ただし、一致する場合（残念ながら、1バイトのチェックサムは256のケースのうち約1つでランダムに一致します）、ファイル全体（潜在的に大きい）をチェックサムする必要があります。
したがって、バッグの3番目のトリックは、このような小さなチェックサム（最大8ファイル）をいくつか収集し、ファイル全体のCRCを計算する前に、それらすべてを一致させる必要があることです。ファイルの数が少なければ、もちろん8未満になる可能性があります。ちなみに、理論的には、1つのアーカイブ内のファイルは異なるパスワードを使用する可能性があり、それによってこのトリックが無効になります（実際、フォールスネガティブが発生する可能性があります）。これはかなり珍しいことなので、デフォルトでは、すべてが同じパスワードを持っていると想定しています。
したがって、私たちにとって最良のケースは、8つ以上のファイルと少なくとも1つの小さなファイルを含むアーカイブです。最悪の場合は、巨大なファイルが1つしかないアーカイブです。
マグナム