Secara otomatis 'brute force' beberapa byte untuk memulihkan file yang rusak


35

Apakah ada orang di luar sana yang tahu cara brute force nilai pada offset tertentu dalam file? Ini 4 byte berturut-turut yang harus dipaksa paksa. Saya tahu SHA-1 yang benar dari file yang rusak. Jadi, yang ingin saya lakukan adalah membandingkan file SHA-1 yang lengkap, setiap kali ia mengubah nilai byte.

Saya tahu persis 4 byte yang diubah, karena file itu diberikan kepada saya oleh seorang ahli pemulihan data, sebagai tantangan pemulihan. Bagi mereka yang tertarik untuk mengetahui, file rar memiliki 4 byte yang sengaja diubah. Saya diberitahu offset 4 byte yang diubah dan SHA-1 asli. Orang itu mengatakan TIDAK MUNGKIN untuk memulihkan file yang tepat dalam arsip setelah 4 byte diubah. Bahkan jika itu hanya beberapa byte dan Anda tahu persis di mana korupsi itu berada. Karena tidak memiliki catatan pemulihan. Saya mencoba untuk melihat apakah ada cara untuk 4 byte tertentu untuk diisi dengan benar sehingga file akan didekompresi tanpa kesalahan. Ukuran file sekitar 5mb.

contoh :

Saya mengunggah foto sehingga lebih jelas apa yang ingin saya lakukan. Saya percaya seseorang dapat mempostingnya di sini untuk saya dengan lebih banyak perwakilan.

Tangkapan layar One

Tangkapan layar Dua

Contoh offset yang saya fokuskan adalah di 0x78mana gambar pertama menunjukkan nilai karena CA saya ingin skrip mengambil nilai hingga 1 sehingga menjadi CBseperti yang ditunjukkan pada gambar kedua. Saya ingin terus meningkatkan nilainya 1dan kemudian membandingkan seluruh file SHA-1 setiap kali. Hanya membuat perubahan pada 4 byte tersebut pada offset yang ditentukan.

Ini akan mencoba CAC5C58Adan membandingkan SHA-1. Jika tidak cocok, maka akan mencoba. CBC5C58AKemudian setelah nilai pertama mencapai FFitu kemudian akan pergi ke 00C6C58Adan seterusnya. Pada dasarnya, saya ingin dapat pergi dari 00000000-FFFFFFFFtetapi juga memiliki pilihan untuk memilih di mana Anda ingin memulai dan mengakhiri. Saya tahu itu bisa memakan waktu tetapi saya masih ingin mencobanya. Perlu diingat saya tahu offset yang tepat dari byte yang rusak. Saya hanya perlu nilai yang benar.

Jika Anda mencari di Google: "Cara memperbaiki file yang rusak dengan kekerasan" Ada orang yang menulis program Linux. Namun, itu hanya berfungsi terhadap file yang disertakan dengan program. Saya mencari beberapa cara untuk menggunakan proses yang sama dengan file saya.


3
Selamat Datang di Pengguna Super! Saya telah mengedit pertanyaan Anda untuk menghapus permintaan untuk suatu program, yang akan di luar topik. Bisakah Anda mengedit pertanyaan Anda untuk memasukkan (beberapa) contoh yang Anda lihat? Ada baiknya Anda telah melakukan penelitian, tetapi menunjukkan kepada kami penelitian apa yang akan sangat membantu :)
bertieb

20
dapatkah saya bertanya bagaimana Anda bisa mendapatkan file ini dan bagaimana Anda dapat yakin bahwa hanya 4 byte yang rusak itu?
Edoardo

1
Apakah Anda tahu format file? Jika Anda melakukannya, Anda mungkin dapat menentukan nilai yang benar atau membatasi rentang, daripada mencoba memaksakannya. Namun secara umum, saya menyarankan file yang rusak harus dibuang karena alasan keamanan.
StephenG

11
@ eddyce Saya benar-benar tertarik pada bagian kedua dari pertanyaan Anda - mengapa 4 byte itu?
Craig Otis

2
Karena penasaran, bagaimana file tersebut bisa rusak? Dan bagaimana Anda tahu itu empat byte itu?
JohnEye

Jawaban:


27

Berikut adalah program Python kecil yang melakukan apa yang Anda uraikan.

#!/usr/bin/env python3
from hashlib import sha1

with open('binaryfile', 'rb') as bin:
    binary = bin.read()

base = 0x0078
# ... is not valid Python; add more sequences, or take it out (or see below)
for seq in [[0xCA, 0xC5, 0xC5, 0x8A], [0xCB, 0xC5, 0xC5, 0x8A], ...]:
    copy = binary[0:base]
    copy += bytes(seq)
    copy += binary[base+len(seq):]
    if sha1(copy).hexdigest() == '9968733ce3ff0893bbb0a19e75faaf2fb0000e19':
        print('success with bytes {0}'.format(seq))
        break
else:
    print('no success')

UnHanya diuji sebentar ; tolong ping saya jika Anda menemukan kesalahan ketik.

The basemenspesifikasikan di mana untuk mencoba menerapkan empat byte, dan string yang panjang '996873... adalah representasi hex dari SHA1 diharapkan. Garis for seq in... mendefinisikan byte untuk dicoba; dan tentu saja ganti 'binaryfile'dengan jalur ke file yang ingin Anda coba selamatkan.

Anda dapat mengganti daftar literal [[0xCA, 0xC5,... ]]dengan sesuatu untuk benar-benar mengulang semua nilai yang mungkin tetapi pada dasarnya hanya pengganti untuk sesuatu yang lebih berguna karena saya tidak benar-benar yakin apa yang sebenarnya Anda inginkan di sana.

Sesuatu seperti for seq in itertools.product(range(256), repeat=4)):akan mengulang semua nilai yang mungkin dari 0 hingga 2 32 -1. (Anda perlu menambahkan di import itertoolsdekat bagian atas itu.) Atau mungkin Anda bisa menambahkan offset; perbarui skrip untuk mengganti yang sekarang for seq indengan yang berikut (di mana lagi importharus pergi sebelum program utama);

import struct

for n in range(2**32):
    val=(n+0x8AC5C5CA) % 2**32  # notice reverse order
    seq=list(reversed(struct.pack(">I", val)))
    copy = ...

Saya membalik urutan byte sehingga secara alami bertambah dari 0x8AC5C5CA ke 0x8AC5C5CB tapi kemudian kenaikan berikutnya adalah 0x8AC5C5CC dll. Sihirnya structadalah mengonversinya ke urutan byte (harus mencarinya dari https: // stackoverflow. com / a / 26920983/874188 ). Ini akan mulai dari 0x8AC5C5CA dan pergi ke 0xFFFFFFFF, kemudian membungkus ke 0x00000000 dan naik kembali ke 0x8AC5C5C9.

Jika Anda memiliki beberapa rentang kandidat yang ingin Anda periksa dalam urutan tertentu, mungkin semacam itu

for rge in [(0x8AC5C5CA, 0x8AFFFFFF), (0x00C6C58A, 0x00FFFFFF),
        (0x00000000, 0x00C6C589), (0x01000000, 0x8AC5C5C9)]:
    for val in range(*rge):
        seq=list(reversed(struct.pack(">I", val)))
        copy = ...

tapi kemudian Anda harus memastikan diri bahwa (awal, akhir) pasang di rgesampul semua ruang antara 0x00000000 dan 0xFFFFFFFF jika Anda benar-benar ingin memeriksa semua itu. (Dan lagi, perhatikan bahwa rentang meningkatkan byte terakhir dan yang seqmenerapkan byte nilai secara terbalik, sesuai dengan persyaratan yang Anda nyatakan.)

Jika Anda ingin menggunakan dua basealamat yang berbeda , Anda dengan cepat berlari melampaui batas dari apa yang layak dilakukan dalam hidup Anda dengan kekuatan kasar; tetapi Anda dapat, misalnya, membagi angka 4-byte menjadi dua bagian 2-byte dan menerapkannya pada offset yang berbeda.

base1 = 0x1234
base2 = 0x2345

for seq in range(whatever):
    copy = binary[0:base1]
    copy += bytes(seq[0:1])
    copy += binary[base1+2:base1+base2]
    copy += bytes(seq[2:3])
    copy += binary[base2+2:]

Komentar bukan untuk diskusi panjang; percakapan ini telah dipindahkan ke obrolan .
Journeyman Geek

4

Tidak, tidak, tidak, dan lagi TIDAK!

Jarang jawaban yang Anda dapatkan bukanlah yang Anda harapkan.

Beberapa pertanyaan untuk Anda:

  • Apakah mungkin seorang ahli tidak tahu bahwa mungkin untuk memaksa string untuk byte dan iteratif mencoba SHA-1 sampai konvergen? Tidak
  • Apakah mungkin dia melupakannya? Tidak
  • Apakah mungkin Anda tidak dapat melakukannya pada file rar? Tidak
  • Apakah jawaban yang lain salah? sama sekali TIDAK

Terus? ... Waktu.

Intinya adalah Anda harus mengubah sedikit byte ... hanya 4!

Apa artinya? 256 4 yaitu 256x256x256x256 kemungkinan, jumlah yang sangat besar.
Jika komputer Anda dapat memproses 1 operasi per detik (substitusi dalam file + sha1) ...
Anda harus menunggu lebih dari 136 tahun , atau jika Anda lebih suka lebih dari 49710 hari.

Anda cukup beruntung, file pre-cache 5MB (sudah dimuat dalam ram dan cache) hanya meminta sekitar 0,03 detik (min 0,025 detik), pada komputer lama. Itu menyusutkan waktu perkiraan Anda menjadi 1242-1492 hari (lebih dari 3 tahun).

Memang benar, BTW, bahwa secara statistik Anda harus memiliki jawaban positif di separuh waktu . Meskipun demikian Anda harus menunggu sampai Anda akan mencoba semua kemungkinan untuk memastikan bahwa hanya ada 1 subtitusi yang akan memberi Anda checksum SHA-1 yang sama ...

Sekarang IMPOSSIBLE terdengar sebagai "tidak mungkin dalam jumlah waktu yang SANGAT BAIK ".


Bagaimana cara melanjutkan

Sebuah jawaban yang lebih tepat untuk pertanyaan teknis Anda: ketika Anda berbicara tentang kekuatan kasar itu tidak harus menjadi kekuatan kasar buta.

  • Itu hanya dinyatakan dalam komentar di jawaban lain bahwa Anda tidak perlu menghitung checksum sha1 pada bagian sebelum korupsi. Anda melakukan yang pertama kali dan Anda menghemat waktu untuk setiap iterasi yang berurutan (mungkin faktor 2 tergantung dari posisi).

  • Sesuatu yang dapat mengubah upaya yang tidak berharga adalah menulis kode paralel yang akan berjalan pada GPU. Jika Anda memiliki kartu grafis yang baik, Anda mungkin memiliki sekitar 1000 core yang dapat dihitung untuk Anda secara paralel (bahkan lebih tetapi mereka memiliki frekuensi lebih rendah dari cpu, tetapi masih banyak). Jika Anda dapat mengurangi waktu dari 1400 menjadi 1,4 hari mungkin Anda bahkan dapat melakukannya.

  • Sebuah pendekatan yang berbeda dapat membawa Anda ke solusi yang lebih cepat.
    Anda bilang itu file rar. The struktur file rar dibagi menjadi blok-blok. Jika Anda menghitungnya, Anda dapat melihat di mana korupsi berada. Jika ada di bagian data, di bagian header atau di keduanya. Maka Anda dapat bertindak secara konsekuen. Demi kesederhanaan mari kita anggap itu atas data:
    Anda dapat melakukan brute force dari offset Anda, periksa untuk setiap CRC positif dari blok itu jika itu bahkan positif SHA1 pada seluruh file. Sekali lagi Anda dapat melakukan kode paralel.

Catatan akhir

Jika mereka 6 byte bukannya 4 Anda keluar dari permainan dengan teknologi saat ini.


Jawaban yang bagus - seseorang tidak perlu menghabiskan seluruh ruang meskipun karena rar itu sendiri dalam contoh ini tidak akan terkompresi karena pemeriksaan internal bahkan jika sha1 bekerja dengan hash duplikat. Menekan 4 byte yang memecahkan sha1 secara salah DAN CRC internal akan sangat sangat tidak mungkin.
rrauenza

@rrauenza Terima kasih. BTW tidak hanya (periksa ulang). Memang blok harus lebih pendek dari seluruh bagian dari byte yang rusak ke akhir file, dan CRC harus lebih ringan untuk menghitung maka algoritma sha1 ...
Hastur

@rrauenza Apakah Anda tahu bagaimana cara mendapatkan kode paralel yang sebenarnya untuk dijalankan pada GPU? Saya memiliki GPU yang bagus. Terima kasih.
Sbt19

Tidak, saya tidak. Anda dapat menggunakan beberapa CPU dengan mempartisi ruang pencarian.
rrauenza

@ Sbt19 Apa pun yang mereka katakan tentang hal itu, google tidak terlalu takut untuk menggunakannya ;-). Cari (jika nvidia) Cuda, brute force, sha1dan Anda akan memiliki banyak petunjuk, misalnya kode sumber . BTW menjaga perhatian tinggi Anda karena browsing dari google jalan, oh anakku, dapat menyebabkan Anda pada salah satu sisi gelap dari net ... :-). (Tidak di github ... di situs lain yang dapat Anda temui dengan jenis penelitian ini). PS> Ada banyak makalah ilmiah tentang topik terkait, misalnya yang ini ...
Hastur
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.