USB giả dung lượng: chép “thành công” mà dữ liệu chưa từng được lưu (ca điển hình)

Trả lời nhanh: USB giả dung lượng là USB có chip nhớ thật nhỏ, ví dụ khoảng 512 MB, nhưng bị chỉnh để Windows báo 16, 32 hay 64 GB. Chép vượt dung lượng thật thì máy vẫn báo “xong”, nhưng phần vượt ra không được lưu. Dấu hiệu thường gặp: file mở ra lỗi hoặc trống, thư mục toàn file rác, Windows đòi kiểm tra ổ, xuất hiện thư mục FOUND.000 với nhiều file .CHK. Khi gặp, hãy ngừng ghi vào cả USB lẫn máy tính và đừng chạy sửa lỗi. Phần dữ liệu nằm trong vùng chip thật thường vẫn còn cơ hội lấy lại. Phần rơi vào vùng giả thì chưa từng được lưu, nên gần như không còn gì để lấy.

Tuần này bên mình nhận một chiếc USB vỏ kim loại vàng, có hoa văn và dây treo, kiểu USB quà tặng rất hay gặp. Khách, tạm gọi là chị V., kể lại: chị “cắt” (cut) Thư mục A từ máy tính sang USB. Chạy được hơn 80% thì quá trình bị ngắt. Cắm lại, chị không còn thấy Thư mục A đâu nữa, còn Windows thì đòi kiểm tra ổ. Đây là một ca điển hình. Bên mình kể lại để anh chị nào đang dùng USB, thẻ nhớ giá rẻ nhận ra sớm.

Chiếc USB vỏ kim loại khai 16 GB trong ca điển hình tại lab Cứu Dữ Liệu Bách Khoa
Chiếc USB vỏ kim loại khai 16 GB trong ca điển hình tại lab Cứu Dữ Liệu Bách Khoa

Khách thấy gì trên máy

Sau khi Windows kiểm tra ổ xong, USB hiện ra một thư mục lạ tên FOUND.000. Trong đó có 4.134 file tên FILE0000.CHK, FILE0001.CHK…, tổng cộng khoảng 11 GB. Các thư mục cũ trên USB (Thư mục C đến H) mở ra chỉ toàn file không tên, file nào cũng cỡ 1.153 KB. Windows vẫn báo USB 14,6 GB, còn trống 1,23 GB, nhìn như một chiếc USB 16 GB bình thường.

Thư mục FOUND.000 đầy file .CHK sau khi Windows kiểm tra ổ
Thư mục FOUND.000 đầy file .CHK sau khi Windows kiểm tra ổ
Thư mục cũ trên USB chỉ còn hàng nghìn file rác cùng cỡ 1.153 KB
Thư mục cũ trên USB chỉ còn hàng nghìn file rác cùng cỡ 1.153 KB
Windows vẫn báo USB 14,6 GB, còn trống 1,23 GB
Windows vẫn báo USB 14,6 GB, còn trống 1,23 GB

Chị V. nghĩ các file .CHK chính là Thư mục A bị Windows đổi tên, chỉ cần đổi đuôi lại là xong. Rất nhiều khách đến quầy cũng nghĩ như vậy. Ca này thì không phải.

Bên mình xử lý thế nào

Việc đầu tiên luôn giống nhau: đặt USB ở chế độ chỉ đọc ngay khi cắm, để Windows không tự ghi thêm gì (sửa lỗi, tạo thư mục hệ thống). Sau đó tạo ảnh toàn bộ USB và làm mọi phân tích trên bản ảnh. Nếu chạy công cụ “sửa lỗi” thẳng lên USB, các dấu vết bên dưới sẽ bị xáo trộn thêm và rất khó đọc ra.

Phần dưới đây dành cho anh chị muốn biết bên mình đọc ra bệnh bằng cách nào. Mọi con số và byte hex đều đo trên ảnh đĩa của ca này.

1. Manh mối đầu tiên: cấu trúc FAT còn nguyên, dữ liệu thì không

  • Ảnh đĩa dài 15.728.640.000 byte, đúng bằng con số bộ điều khiển (controller) báo cho Windows: 30.720.000 sector × 512 byte. Windows hiển thị 14,6 GB vì tính theo đơn vị 1.024. Phân vùng FAT32, cụm (cluster) 64 KB.
  • Hai bảng FAT (FAT1, FAT2) giống nhau hoàn toàn, chuỗi cụm của mọi file vẫn đọc được. Vì vậy CHKDSK mới dựng được 4.134 file .CHK với kích thước trông “hợp lý”.
  • Nhưng cụm thư mục của Thư mục A và Thư mục C–H, đọc theo cấu trúc FAT, không ra một tên file nào. Mỗi cụm 64 KB biến thành 2.048 mục (entry) rác.
  • Lúc tạo ảnh không gặp sector lỗi nào, lệnh đọc nào cũng trả về rất nhanh. Vậy đây không phải chip hỏng hay đọc lỗi. USB “đọc tốt”, nhưng thứ nó trả về không phải dữ liệu.

2. So sánh hex: cùng một sector ở khắp nơi

Bên mình đọc thô sector đầu tiên ở những vị trí cách xa nhau trên ảnh đĩa:

mốc 300 MB  : (byte đa dạng, là dữ liệu thật của khách, đã che)
mốc 1 GB    : 13 03 14 03 15 03 16 03 17 03 18 03 19 03 1A 03 ...
mốc 8 GB    : 13 03 14 03 15 03 16 03 17 03 18 03 19 03 1A 03 ...
mốc 8,87 GB : 13 03 14 03 15 03 16 03 17 03 18 03 19 03 1A 03 ...   (cụm thư mục của Thư mục A)
mốc 12 GB   : 13 03 14 03 15 03 16 03 17 03 18 03 19 03 1A 03 ...
  • Mốc 300 MB nằm trong vùng thật: byte đa dạng, đúng là nội dung file. Từ mốc 1 GB trở đi, cả 512 byte giống hệt nhau ở mọi vị trí. Đọc theo số 16-bit, đó là một dãy có quy luật: 0x0313, 0x0314 … 0x03FF, rồi 0x0001, 0x0000, 0x0002 … 0x0012. Đây là một bảng số của firmware, không phải dữ liệu người dùng.
  • Kiểm thêm bằng hash: lấy mẫu 4 KB ở 200 vị trí, so với vị trí lệch 64 MB, 128 MB, 256 MB, 512 MB hay 1 GB, lần nào cũng trùng khoảng 96%. Nội dung không lặp theo chu kỳ, mà là hằng số: ở đâu cũng là cùng một sector.
Mã hex tại mốc 8,87 GB, đúng chỗ đáng lẽ là thư mục của khách: cùng mẫu 13 03 14 03… như các mốc 1 GB, 8 GB, 12 GB (ảnh dựng từ byte thật của ảnh đĩa)
Mã hex tại mốc 8,87 GB, đúng chỗ đáng lẽ là thư mục của khách: cùng mẫu 13 03 14 03… như các mốc 1 GB, 8 GB, 12 GB (ảnh dựng từ byte thật của ảnh đĩa)

3. Loại trừ kiểu “quay vòng”

USB giả dung lượng hay gặp nhất là kiểu ghi quay vòng: địa chỉ vượt dung lượng thật bị quay về đầu chip và ghi đè dữ liệu cũ. Nếu vậy, vùng 1–2 GB phải lặp lại nội dung vùng 0–1 GB.

Bên mình so từng khối 1 MB của GB đầu với từng GB phía sau. Lần nào cũng có khoảng 508 MB khác nhau, đúng bằng phần dữ liệu thật của GB đầu; phần còn lại trùng vì nó cũng là mẫu giả. Nghĩa là vùng cao không phản chiếu vùng thấp. Controller này không lưu dữ liệu ghi quá dung lượng thật ở đâu cả, đọc ra chỉ trả về sector mẫu.

4. Bản đồ toàn ổ

Bên mình phân loại từng cụm 64 KB trên ảnh đĩa:

  • 8.113 trên 240.000 cụm có dữ liệu thật (khoảng 507 MB, 3,4%), liền một khối từ đầu ổ.
  • Gần như toàn bộ phần còn lại (khoảng 14,1 GB, 96,6%) là vùng giả: sector nào cũng trùng từng byte với sector mẫu, tức gần 30 triệu sector giống hệt nhau.
  • Vài cụm lẻ trong vùng giả vẫn đọc lại được, trong đó có chính thư mục FOUND.000 (khoảng mốc 6,7 GB). Bên mình chưa lý giải hết chi tiết này, có thể do cách firmware ánh xạ địa chỉ.

Kết luận: chip nhớ thật chỉ khoảng 512 MB, trên một chiếc USB khai 16 GB.

Bản đồ BK Recover vẽ từ ảnh đĩa: phần xanh là dữ liệu thật (~507 MB), phần đỏ là vùng giả (~14,1 GB)
Bản đồ BK Recover vẽ từ ảnh đĩa: phần xanh là dữ liệu thật (~507 MB), phần đỏ là vùng giả (~14,1 GB)

5. Vì sao Windows không hề biết

  • Windows chỉ hỏi controller “ổ có bao nhiêu sector” (lệnh READ CAPACITY của chuẩn USB Mass Storage) và tin con số trả về: 30.720.000 sector. Windows không có cách nào tự kiểm tra chip thật bên trong.
  • Firmware bị sửa để khai con số đó. Lệnh ghi vào vùng không có chip vẫn được báo thành công, lệnh đọc thì trả về sector mẫu. Không có lỗi nào nên Explorer cứ chép “bình thường”.
  • Bảng FAT nằm ở đầu ổ, thuộc chip thật, nên vẫn được ghi đúng. Bảng thư mục và nội dung file nằm ở vùng cao thì mất. Đó là lý do cấu trúc trông gần đúng mà không mở được gì.

6. Giải mã hàng nghìn file “1.153 KB”

Ảnh Explorer ở đầu bài có hàng nghìn file tên là một ô vuông, cùng cỡ 1.153 KB. Đó không phải file thật. Cụm thư mục nằm ở vùng giả, nên Windows đọc sector mẫu như thể đó là danh sách file (mỗi sector 512 byte = 16 entry × 32 byte):

  • 15 entry đầu có byte thuộc tính (offset 11) = 0x03, tức chỉ đọc + ẩn, nên Explorer giấu đi.
  • Entry thứ 16 (offset 0x1E0) có thuộc tính 0x00, tức file thường, nên hiện ra. Tên bắt đầu bằng byte 0x03, một ký tự điều khiển, nên Explorer vẽ thành ô vuông.
  • Trường cụm đầu là 0x000D0010 = 851.984, vượt xa số cụm của cả ổ (239.969). Một file thật không thể bắt đầu ở đó.
  • Trường kích thước (4 byte cuối entry) là 11 00 12 00, tức 0x00120011 = 1.179.665 byte = 1.152,02 KB. Explorer làm tròn lên thành 1.153 KB.
Giải mã entry thư mục tại offset 0x1E0 (tên đã che): thuộc tính 0x00, cụm đầu 851.984, kích thước 1.179.665 byte
Giải mã entry thư mục tại offset 0x1E0 (tên đã che): thuộc tính 0x00, cụm đầu 851.984, kích thước 1.179.665 byte

Sector nào trong vùng giả cũng giống nhau, nên mỗi cụm thư mục 64 KB sinh ra đúng 128 “file” như vậy. Mỗi file “1.153 KB” trên màn hình thực chất là một mảnh của dãy số firmware bị hiểu nhầm thành entry thư mục.

7. Đối chiếu với các file .CHK

  • Lần theo chuỗi FAT của cả 4.134 file .CHK: 4.132 file bắt đầu trong vùng giả. Mở ra chỉ thấy mẫu lặp, ví dụ FILE0002.CHK (16.192 KB) từ byte đầu tiên đã là 13 03 14 03…
  • 2 file còn lại (FILE0000.CHK và FILE0001.CHK, mỗi file 64 KB) là bảng thư mục cũ của một thư mục con thuộc Thư mục B, không phải dữ liệu Thư mục A.
FILE0002.CHK trong FOUND.000: từ byte đầu tiên đã là mẫu lặp của vùng giả
FILE0002.CHK trong FOUND.000: từ byte đầu tiên đã là mẫu lặp của vùng giả

Như vậy dữ liệu Thư mục A chưa bao giờ thực sự nằm trên chip. Gần như toàn bộ những gì ghi vào vùng giả đều mất, phần mềm nào cũng không lấy lại được.

Kết luận đo trên ảnh đĩa: khai 16 GB, Windows báo 14,6 GB, dữ liệu thật khoảng 507 MB, vùng giả khoảng 14,1 GB
Kết luận đo trên ảnh đĩa: khai 16 GB, Windows báo 14,6 GB, dữ liệu thật khoảng 507 MB, vùng giả khoảng 14,1 GB

Vì sao Thư mục A mất, tóm lại

  • Phần chip thật gần đầy từ trước: Thư mục B cũ đã chiếm khoảng 480 MB. Toàn bộ Thư mục A rơi vào vùng giả.
  • Bảng thư mục của Thư mục A và Thư mục C–H cũng nằm ở vùng giả, nên Windows đọc ra thấy hỏng và CHKDSK gom thành file .CHK.
  • Dữ liệu cũ cũng đã hỏng từ trước mà khách không biết. Thư mục B có 582 mục, chỉ 490 file còn dữ liệu thật, 89 mục đã mất ngay từ lúc chép vào.

Kết quả trả cho khách

Bên mình trả lại 490 file của Thư mục B còn dữ liệu thật (469 MB), giữ nguyên cấu trúc thư mục và ngày giờ. Với Thư mục A, bên mình báo thẳng với chị V.: không thể lấy từ USB, vì dữ liệu chưa từng nằm trên chip.

Còn bản gốc trên máy tính thì sao? “Cắt” sang ổ khác thực chất là Windows chép từng file sang, rồi xoá bản gốc trên máy tính, không qua Thùng rác. Máy của chị V. dùng SSD NVMe, chức năng TRIM đang bật. Khi Windows xoá bản gốc, TRIM báo cho SSD dọn luôn các vùng đó. Vì vậy Thư mục A cũng không còn khả năng lấy lại trên máy gốc.

Ca này buồn ở chỗ: dữ liệu mất ở cả hai nơi mà không có thao tác nào “sai” rõ ràng, chỉ là một lệnh “cut” sang một chiếc USB giả. Nếu chị V. dùng “copy”, bản gốc trên máy vẫn còn nguyên.

Với anh chị gặp tình huống tương tự, khả năng còn lại trên máy tính tuỳ loại ổ:

  • Máy dùng ổ cứng HDD: file bị xoá thường vẫn nằm trên ổ cho tới khi bị ghi đè. Ngừng dùng máy ngay; càng dùng, càng dễ bị đè.
  • Máy dùng SSD: nếu TRIM bật (mặc định trên Windows), vùng vừa xoá thường bị dọn rất nhanh. Phần mềm khôi phục không lấy lại được. Chỉ một số trường hợp, tuỳ chip điều khiển và thời điểm tắt máy, mới còn cơ hội khi can thiệp bằng máy chuyên dụng. Không ai hứa trước được.

Dấu hiệu USB, thẻ nhớ có thể bị giả dung lượng

  • Giá rẻ bất thường so với dung lượng, không rõ nguồn gốc, hay gặp ở USB quà tặng, USB vỏ kim loại in logo.
  • Chép vào báo thành công, nhưng mở lại thì file lỗi, ảnh xám một nửa, video không chạy.
  • Thư mục cũ tự biến thành file rác không tên, cùng một kích thước.
  • Windows đòi kiểm tra ổ, sau đó xuất hiện thư mục FOUND.000 với nhiều file .CHK.

Cách tránh mất dữ liệu kiểu này

  • Thử dung lượng thật khi mới mua. Dùng phần mềm ghi đầy rồi đọc lại toàn bộ, ví dụ H2testw (Windows) hoặc F3 (Linux, macOS). Chỉ chạy trên USB, thẻ nhớ mới còn trống, vì phần mềm sẽ ghi đè toàn bộ.
  • Không dùng “cut” để chuyển dữ liệu quan trọng sang USB. Hãy dùng “copy”, mở thử vài file trên USB, rồi mới xoá bản gốc.
  • Không để USB là nơi giữ bản duy nhất. Dữ liệu quan trọng nên có ít nhất hai bản, ở hai thiết bị khác nhau.

Khi đã lỡ mất dữ liệu

  • Ngừng ghi vào cả USB lẫn máy tính vừa chép. Với máy tính, hạn chế dùng tiếp, tốt nhất là tắt máy.
  • Không chạy CHKDSK hay công cụ sửa lỗi, không format USB khi Windows hỏi.
  • Không đổi đuôi hay mở thử các file .CHK lung tung; giữ nguyên hiện trạng.
  • Mang USB (và ổ của máy tính, nếu dữ liệu vừa được “cắt” từ đó) tới trung tâm để tạo ảnh trước khi xử lý. Đoạn đã bị ghi đè thì không cứu được.

Bên mình nhận kiểm tra USB, thẻ nhớ, ổ cứng HDD và SSD. Kiểm tra xong mới báo tình trạng và chi phí, anh chị đồng ý mới làm.

Hỏi đáp

File .CHK trong thư mục FOUND.000 có phải là dữ liệu bị mất không?

Có thể có, có thể không. File .CHK là các mảnh mà công cụ kiểm tra ổ của Windows gom lại. Với USB thật, nhiều file .CHK vẫn chứa dữ liệu. Với USB giả dung lượng, phần lớn chỉ là mẫu rác do bộ điều khiển trả về. Cần kiểm tra nội dung từng file mới biết.

Làm sao biết USB của mình có bị giả dung lượng không?

Dùng H2testw hoặc F3 ghi đầy rồi đọc lại toàn bộ USB. Phần mềm sẽ báo dung lượng ghi đọc được thật. Chỉ làm với USB còn trống, vì phần mềm ghi đè dữ liệu.

Dữ liệu chép vào vùng giả có cứu được không?

Gần như không. Dữ liệu đó chưa từng thực sự được ghi lên chip, nên gần như không còn gì để lấy. Còn cơ hội với phần dữ liệu nằm trong vùng chip thật. Bản gốc trên máy tính thì tuỳ loại ổ: HDD còn cơ hội nếu chưa bị ghi đè; SSD đã TRIM thì gần như không còn.

“Cut” và “copy” khác nhau thế nào khi chép sang USB?

“Copy” giữ nguyên bản gốc trên máy. “Cut” sang ổ khác thì Windows chép xong sẽ xoá bản gốc, không qua Thùng rác. Nếu USB lỗi, giả dung lượng hoặc bị ngắt giữa chừng, anh chị có thể mất cả hai nơi.

Cần kiểm tra USB, thẻ nhớ đang có dữ liệu quan trọng?

Cứu Dữ Liệu Bách Khoa (BK Recover), hơn 19 năm làm cứu dữ liệu ổ cứng, SSD, USB, thẻ nhớ và máy chủ. Kiểm tra trước, báo rõ lỗi và chi phí, không đặt cọc.

  • Hotline: 1900 636 196 · Zalo: 0817 579 555
  • Cơ sở 1: 29 ngõ 40 Tạ Quang Bửu, Bách Khoa, Hà Nội
  • Cơ sở 2: 87 Trần Thái Tông, Cầu Giấy, Hà Nội

Xem thêm: Dịch vụ cứu dữ liệu USB, thẻ nhớ · Dịch vụ cứu dữ liệu SSD · Bảng giá cứu dữ liệu