Trải qua nỗi đau đớn hoặc lịch sử lâu dài của một nỗ lực khôi phục dữ liệu

Đó là năm 2019. Phòng thí nghiệm của chúng tôi đã nhận được một ổ đĩa QUANTUM FIREBALL Plus KA có dung lượng 9.1GB, một ổ đĩa này không phổ biến ở thời đại chúng ta. Theo chủ sở hữu của ổ đĩa, sự cố xảy ra vào năm 2004 do nguồn điện bị hỏng, khiến ổ cứng và các thành phần PC khác bị ảnh hưởng. Sau đó, có những lượt truy cập vào nhiều dịch vụ khác nhau với nỗ lực sửa chữa ổ đĩa và khôi phục dữ liệu nhưng không thành công. Trong một số trường hợp, họ hứa rằng nó sẽ rẻ, nhưng họ không bao giờ giải quyết được vấn đề, trong một số trường hợp khác, nó quá đắt và khách hàng không muốn khôi phục dữ liệu, nhưng cuối cùng đĩa đã phải qua nhiều trung tâm bảo hành. Nó đã bị thất lạc nhiều lần, nhưng nhờ chủ nhân đã quan tâm ghi lại thông tin từ nhiều nhãn dán khác nhau trên ổ đĩa trước nên anh ta đã đảm bảo rằng ổ cứng của mình đã được trả lại từ một số trung tâm bảo hành. Các cuộc đi bộ không hề trôi qua mà không có dấu vết, nhiều dấu vết hàn vẫn còn trên bảng điều khiển ban đầu và việc thiếu các phần tử SMD cũng được cảm nhận rõ ràng (nhìn về phía trước, tôi sẽ nói rằng đây là vấn đề nhỏ nhất của ổ đĩa này).

Trải qua nỗi đau đớn hoặc lịch sử lâu dài của một nỗ lực khôi phục dữ liệu
Cơm. 1 ổ cứng Quantum Fireball Plus KA 9,1GB

Điều đầu tiên chúng tôi phải làm là tìm kiếm trong kho lưu trữ của nhà tài trợ một người anh em song sinh cổ xưa như vậy của ổ đĩa này với một bảng điều khiển đang hoạt động. Khi nhiệm vụ này hoàn thành, các biện pháp chẩn đoán mở rộng có thể được thực hiện. Sau khi kiểm tra các cuộn dây động cơ xem có bị đoản mạch không và đảm bảo không có đoản mạch, chúng tôi lắp bo mạch từ ổ phụ vào ổ bệnh nhân. Chúng tôi cấp nguồn và nghe thấy âm thanh bình thường của trục quay lên, vượt qua bài kiểm tra hiệu chuẩn khi tải chương trình cơ sở và sau vài giây, ổ đĩa sẽ báo cáo bằng các thanh ghi rằng nó đã sẵn sàng đáp ứng các lệnh từ giao diện.

Trải qua nỗi đau đớn hoặc lịch sử lâu dài của một nỗ lực khôi phục dữ liệu
Cơm. 2 đèn báo DRD DSC cho biết mức độ sẵn sàng nhận lệnh.

Chúng tôi sao lưu tất cả các bản sao của mô-đun phần sụn. Chúng tôi kiểm tra tính toàn vẹn của các mô-đun phần sụn. Không có vấn đề gì với việc đọc các mô-đun, nhưng việc phân tích các báo cáo cho thấy có một số điều kỳ lạ.

Trải qua nỗi đau đớn hoặc lịch sử lâu dài của một nỗ lực khôi phục dữ liệu
Cơm. 3. Bảng vùng.

Chúng ta chú ý đến bảng phân bố vùng và lưu ý rằng số lượng hình trụ là 13845.

Trải qua nỗi đau đớn hoặc lịch sử lâu dài của một nỗ lực khôi phục dữ liệu
Cơm. 4 Danh sách P (danh sách chính - danh sách các lỗi phát sinh trong chu kỳ sản xuất).

Chúng tôi thu hút sự chú ý đến số lượng lỗi quá nhỏ và vị trí của chúng. Chúng tôi xem xét mô-đun nhật ký ẩn lỗi của nhà máy (60h) và thấy rằng nó trống và không chứa một mục nào. Dựa trên điều này, chúng ta có thể giả định rằng tại một trong các trung tâm dịch vụ trước đó, một số thao tác có thể đã được thực hiện với vùng dịch vụ của ổ đĩa và vô tình hay cố ý một mô-đun nước ngoài đã được ghi hoặc danh sách các lỗi trong bản gốc một đã được xóa. Để kiểm tra giả định này, chúng tôi tạo một tác vụ trong Trình trích xuất dữ liệu với các tùy chọn “tạo bản sao theo từng ngành” và “tạo trình dịch ảo” được bật.

Trải qua nỗi đau đớn hoặc lịch sử lâu dài của một nỗ lực khôi phục dữ liệu
Cơm. 5 Tham số nhiệm vụ.

Sau khi tạo tác vụ, chúng ta xem xét các mục trong bảng phân vùng ở khu vực 0 (LBA XNUMX)

Trải qua nỗi đau đớn hoặc lịch sử lâu dài của một nỗ lực khôi phục dữ liệu
Cơm. 6 Bản ghi khởi động chính và bảng phân vùng.

Tại offset 0x1BE có một mục nhập duy nhất (16 byte). Loại hệ thống tệp trên phân vùng là NTFS, bù vào đầu các cung 0x3F (63), kích thước phân vùng 0x011309A3 (18).
Trong trình soạn thảo ngành, mở LBA 63.

Trải qua nỗi đau đớn hoặc lịch sử lâu dài của một nỗ lực khôi phục dữ liệu
Cơm. 7 Khu vực khởi động NTFS

Theo thông tin trong khu vực khởi động của phân vùng NTFS, chúng ta có thể nói như sau: kích thước khu vực được chấp nhận trong ổ đĩa là 512 byte (word 0x0 (0) được viết ở offset 0200x512B), số lượng khu vực trong cụm là 8 (byte 0x0 được ghi ở offset 0x08D), kích thước cụm là 512x8=4096 byte, bản ghi MFT đầu tiên nằm ở offset 6 cung từ đầu đĩa (ở offset 291x519 bốn từ 0x30 0 00 00 00 00C 00 0 (00) số của cụm MFT đầu tiên. Số khu vực được tính theo công thức: Số cụm * số khu vực trong cụm + offset về đầu phân khu 00* 786+432= 786).
Hãy chuyển sang khu vực 6.

Trải qua nỗi đau đớn hoặc lịch sử lâu dài của một nỗ lực khôi phục dữ liệu
Hình 8

Nhưng dữ liệu chứa trong khu vực này hoàn toàn khác với bản ghi MFT. Mặc dù điều này cho thấy có thể có bản dịch không chính xác do danh sách lỗi không chính xác nhưng nó không chứng minh thực tế này. Để kiểm tra thêm, chúng tôi sẽ đọc đĩa theo 10 cung theo cả hai hướng tương ứng với 000 cung. Và sau đó chúng ta sẽ tìm kiếm các biểu thức chính quy trong những gì chúng ta đọc.

Trải qua nỗi đau đớn hoặc lịch sử lâu dài của một nỗ lực khôi phục dữ liệu
Cơm. 9 Ghi MFT đầu tiên

Trong khu vực 6, chúng tôi tìm thấy bản ghi MFT đầu tiên. Vị trí của nó khác với vị trí được tính toán theo 291 lĩnh vực và sau đó là một nhóm gồm 551 bản ghi (từ 32 đến 16) liên tục theo sau. Hãy nhập vị trí của ngành 0 vào bảng dịch chuyển và tiến lên 15 ngành.

Trải qua nỗi đau đớn hoặc lịch sử lâu dài của một nỗ lực khôi phục dữ liệu
Hình 10

Vị trí của bản ghi số 16 phải ở offset 12, nhưng chúng tôi tìm thấy số 551 ở đó thay vì bản ghi MFT. Hãy tiến hành một cuộc tìm kiếm tương tự ở khu vực xung quanh.

Trải qua nỗi đau đớn hoặc lịch sử lâu dài của một nỗ lực khôi phục dữ liệu
Cơm. 11 mục nhập MFT 0x00000011 (17)

Một đoạn MFT lớn được phát hiện, bắt đầu từ bản ghi số 17 với độ dài 53 bản ghi) với sự dịch chuyển 646 cung. Đối với vị trí 17, đặt dịch chuyển +12 ngành vào bảng dịch chuyển.
Sau khi xác định được vị trí của các mảnh MFT trong không gian, chúng ta có thể kết luận rằng đây không giống như một lỗi ngẫu nhiên và việc ghi lại các mảnh MFT ở độ lệch không chính xác. Một phiên bản có người dịch không chính xác có thể được coi là đã được xác nhận.
Để bản địa hóa hơn nữa các điểm dịch chuyển, chúng tôi sẽ đặt chuyển vị tối đa có thể. Để thực hiện việc này, chúng tôi xác định mức độ dịch chuyển của điểm đánh dấu cuối của phân vùng NTFS (bản sao của khu vực khởi động). Trong Hình 7, ở độ lệch 0x28, tứ giác là giá trị kích thước phân vùng của các cung 0x00 00 00 00 01 13 09 A2 (18). Hãy cộng phần bù của chính phân vùng từ đầu đĩa vào chiều dài của nó và chúng ta sẽ có phần bù của điểm đánh dấu NTFS cuối 024 + 866= 18. Đúng như dự đoán, bản sao bắt buộc của khu vực khởi động không có ở đó. Khi tìm kiếm khu vực xung quanh, người ta thấy nó có sự dịch chuyển ngày càng tăng +024 khu vực so với đoạn MFT cuối cùng.

Trải qua nỗi đau đớn hoặc lịch sử lâu dài của một nỗ lực khôi phục dữ liệu
Cơm. 12 Bản sao của khu vực khởi động NTFS

Chúng tôi bỏ qua bản sao khác của khu vực khởi động ở offset 18 vì nó không liên quan đến phân vùng của chúng tôi. Dựa trên các hoạt động trước đó, người ta xác định rằng trong phần này có 041 lĩnh vực “xuất hiện” trong chương trình phát sóng, giúp mở rộng dữ liệu.
Chúng tôi thực hiện đọc toàn bộ ổ đĩa, để lại 34 khu vực chưa đọc. Thật không may, không thể đảm bảo một cách đáng tin cậy rằng tất cả chúng đều là những khiếm khuyết bị loại khỏi danh sách P, nhưng khi phân tích sâu hơn, nên tính đến vị trí của chúng, vì trong một số trường hợp, có thể xác định một cách đáng tin cậy các điểm chuyển đổi bằng độ chính xác của lĩnh vực chứ không phải của tập tin.

Trải qua nỗi đau đớn hoặc lịch sử lâu dài của một nỗ lực khôi phục dữ liệu
Cơm. 13 Thống kê đọc đĩa.

Nhiệm vụ tiếp theo của chúng tôi sẽ là thiết lập các vị trí gần đúng của các ca làm việc (theo độ chính xác của tệp nơi chúng xảy ra). Để thực hiện việc này, chúng tôi sẽ quét tất cả các bản ghi MFT và xây dựng chuỗi vị trí tệp (đoạn tệp).

Trải qua nỗi đau đớn hoặc lịch sử lâu dài của một nỗ lực khôi phục dữ liệu
Cơm. 14 Chuỗi vị trí của tập tin hoặc các đoạn của chúng.

Tiếp theo, di chuyển từ tệp này sang tệp khác, chúng tôi tìm kiếm thời điểm sẽ có dữ liệu khác thay vì tiêu đề tệp dự kiến ​​​​và tiêu đề mong muốn sẽ được tìm thấy với một sự thay đổi tích cực nhất định. Và khi chúng tôi tinh chỉnh các điểm thay đổi, chúng tôi sẽ điền vào bảng. Kết quả của việc lấp đầy nó sẽ là hơn 99% tệp không bị hư hỏng.

Trải qua nỗi đau đớn hoặc lịch sử lâu dài của một nỗ lực khôi phục dữ liệu
Cơm. 15 Danh sách tệp người dùng (đã nhận được sự đồng ý từ khách hàng để xuất bản ảnh chụp màn hình này)

Để thiết lập các dịch chuyển điểm trong các tệp riêng lẻ, bạn có thể thực hiện công việc bổ sung và nếu bạn biết cấu trúc của tệp, hãy tìm các phần chứa dữ liệu không liên quan đến nó. Nhưng trong nhiệm vụ này nó không khả thi về mặt kinh tế.

Tái bút Tôi cũng muốn nói chuyện với các đồng nghiệp của tôi, những người trước đây đã sở hữu chiếc đĩa này. Hãy cẩn thận khi làm việc với chương trình cơ sở của thiết bị và sao lưu dữ liệu dịch vụ trước khi thay đổi bất kỳ điều gì và không cố tình làm trầm trọng thêm vấn đề nếu bạn không thể đồng ý với khách hàng về công việc.

Ấn phẩm trước: Lưu trận đấu hoặc khôi phục dữ liệu từ ổ cứng HDD Seagate ST3000NC002-1DY166

Nguồn: www.habr.com

Thêm một lời nhận xét