2010-11-10 45 views
5

Trong dự án tôi đang làm, tôi muốn cung cấp cho người dùng tùy chọn 'an toàn' xóa tệp - như trong, ghi đè lên bằng các bit ngẫu nhiên hoặc 0. Có một cách dễ dàng-ish làm điều này trong C# .NET? Và nó sẽ hiệu quả như thế nào?Xóa an toàn tệp trong C# .NET

+1

bản sao có thể có của [Các tệp băm nhỏ trong .NET] (http://stackoverflow.com/questions/1046635/shredding-files-in-net) –

+0

Bạn hoàn toàn bỏ lỡ câu trả lời của tôi, không có cách nào để đảm bảo rằng dữ liệu bạn đang cố gắng ghi vào một tệp sẽ thực sự chiếm cùng một vị trí trên đĩa như dữ liệu mà nó đang thay thế, vì vậy bạn không thể làm những gì bạn đang yêu cầu. – mikerobi

+0

Bạn có muốn xóa nội dung một cách an toàn không hoặc bạn có muốn ghi đè lên nó bằng các bit ngẫu nhiên không? Chúng không giống nhau. Chỉ cần ghi đè lên tập tin sẽ không làm những gì bạn muốn, tôi nghĩ. –

Trả lời

5

Bạn có thể gọi sysinternals SDelete để thực hiện việc này cho bạn. Điều này sử dụng API chống phân mảnh để xử lý tất cả các trường hợp khó xử này.

Sử dụng API chống phân mảnh, sdelete có thể xác định một cách chính xác mà cụm trên đĩa được chiếm bởi các dữ liệu thuộc nén, thưa thớt và file mã hóa.

Nếu bạn muốn đóng gói lại logic đó ở dạng thuận tiện hơn, API được mô tả here.

2

Bạn không thể xóa an toàn tệp trên hệ thống tệp nhật ký. Hệ thống không ghi nhật ký duy nhất vẫn được sử dụng nhiều là fat32. Trên bất kỳ hệ thống nào khác, cách duy nhất để xóa an toàn là băm nhỏ toàn bộ ổ cứng.

EDIT

Lý do an toàn xóa không hoạt động, đó là dữ liệu sử dụng để ghi đè lên một file có thể không được lưu trữ trong cùng một vị trí như các dữ liệu mà nó được ghi đè.

Có vẻ như Microsoft không cung cấp công cụ xóa an toàn, nhưng dường như nó không phải là thứ mà bạn có thể sử dụng để thay thế.

Cách duy nhất để ngăn chặn việc khôi phục tệp đã xóa, rút ​​ngắn đĩa, sẽ mã hóa tệp trước khi được ghi vào đĩa.

+0

Cảm ơn bạn đã trả lời, tôi đã lặp lại một câu hỏi một chút . Nó không quan trọng nếu tập tin được _totally_ xóa, tất cả những gì quan trọng là tôi sử dụng phương pháp tương tự như một chương trình xóa tập tin chuẩn bog – Chris

+0

@Andrey, tôi không hiểu ý bạn là gì – mikerobi

+0

nếu tệp là, giả sử, 100mb trong kích thước, hoàn toàn không thực tế để giữ toàn bộ tập tin được mã hóa và nguyên bản trong RAM ... – DividedByZero

-1

Trước tiên, tôi chỉ cần thử mở tệp và ghi đè nội dung của tệp như tôi thường làm. Khá tầm thường trong C#, tôi thậm chí sẽ không bận tâm để viết nó. Tuy nhiên tôi không biết chắc chắn thế nào. Đối với một điều, tôi khá chắc chắn nó sẽ không hoạt động trên ổ đĩa flash và SSD sử dụng các thuật toán phức tạp để cung cấp san lấp mặt bằng mặc. Tôi không biết những gì sẽ làm việc ở đó, có lẽ nó sẽ cần phải được thực hiện trên trình điều khiển cấp, có lẽ nó sẽ là không thể ở tất cả. Trên các ổ đĩa bình thường, tôi không biết Windows sẽ làm gì. Có lẽ nó sẽ giữ lại dữ liệu cũ.

+1

Nó sẽ không hoạt động trên bất kỳ tập tin ghi nhật ký nào, bất kể loại ổ đĩa nào (xem câu trả lời của tôi để được giải thích). – mikerobi

+0

@mikerobi - Tôi biết, nhưng ngoài điều đó - đây là điều tốt nhất tiếp theo. Ít nhất các tiện ích phục hồi điển hình sẽ bị lừa. –

1

Nó sẽ không được an toàn chút nào. Thay vào đó, bạn có thể muốn xem xét các giải pháp thay thế như mã hóa.

Một giải pháp là mã hóa nội dung của tệp dữ liệu. Một khóa mới sẽ được sử dụng mỗi khi tập tin được cập nhật. Khi bạn muốn "xóa an toàn" dữ liệu chỉ đơn giản là "mất" khóa mã hóa và xóa tệp. Tệp sẽ vẫn nằm trên đĩa vật lý nhưng không thể khôi phục khóa mã hóa là không thể.

Dưới đây là lời giải thích chi tiết hơn là tại sao "an toàn" ghi đè các tập tin là bảo mật kém:

Nếu không có một công cụ ở mức độ thấp (ngoài thời gian chạy .net) bạn không có quyền truy cập vào các vị trí đĩa vật lý. Lấy một tập tin trên NTFS, khi bạn "mở một tập tin để ghi truy cập" bạn không đảm bảo rằng bản sao "cập nhật" (trong trường hợp này là phiên bản 101010 ngẫu nhiên) sẽ được lưu trữ ở cùng một nơi (do đó ghi đè lên tập tin gốc).Trong thực tế hầu hết thời gian này là những gì sẽ xảy ra:

1) Tệp x.dat được lưu trữ bắt đầu tại cụm 8493489 2) Bạn mở tệp x.dat để ghi truy cập. Những gì được trả về cho bạn bởi hệ điều hành chỉ đơn thuần là một con trỏ tới dòng tập tin được trừu tượng bởi không chỉ hệ điều hành mà là hệ thống tập tin cơ bản và trình điều khiển thiết bị (ví dụ phần cứng RAID) và đôi khi bản thân đĩa vật lý (SSD). Bạn cập nhật nội dung của tệp một cách ngẫu nhiên 1 & 0 và đóng luồng phim.

3) Hệ điều hành có thể (và có khả năng sẽ) ghi tệp mới vào cụm khác (nói cụm 4384939). Sau đó, nó sẽ chỉ cập nhật MFT cho biết tệp x hiện được lưu trữ tại 4384939.

Với người dùng cuối, có một bản sao của tệp và bây giờ có dữ liệu ngẫu nhiên trong đó, nhưng dữ liệu gốc vẫn tồn tại trên đĩa.

Thay vào đó, bạn nên xem xét mã hóa nội dung của tệp bằng một khóa khác nhau mỗi lần tệp được lưu. Khi người dùng muốn các tập tin "xóa" xóa chìa khóa và tập tin. Tệp vật lý có thể vẫn tồn tại nhưng không thể khôi phục khóa mã hóa là không thể.

+0

không thể khôi phục tệp mà không có khóa nên về cơ bản nó bị mất đúng không? sai rồi. chính là CSONG có thể phục hồi giống như cách mà tệp sẽ có trừ khi người ta biết chính xác những gì anh ta đang làm – DividedByZero