SDV - Sichere Datenvernichtung

xcatpc · 2 Sep. 2011

Hallo!

Wenn eine Datei gelöscht wird, wird lediglich der Speicherbereich freigegeben.
Somit kann die gelöschte Datei mit speziellen Programmen, wiederhergestellt werden.

Abhilfe schafft meine Anwendung: SDV - Sichere Datenvernichtung

Meine Anwendung steht für euch unter:
http://sourceforge.net/projects/sdv/files/
kostenlos zur Verfügung.

Ich bitte lediglich um Feedback!

Anonymous · 3 Sep. 2011

Gute Idee, aber funktioniert leider überhaupt nicht. sprich ich kann deine ach so sicher geglaubt gelöschten Dateien problemlos wiederherstellen.

Code:

rob-linux:/mnt/testdir # cp /home/rob/Bilder/koeln/*.JPG .                 
rob-linux:/mnt/testdir # ls                                                
DSCN0754.JPG  DSCN0757.JPG  DSCN0760.JPG  DSCN0763.JPG  DSCN0766.JPG  DSCN0769.JPG  DSCN0772.JPG  DSCN0775.JPG  DSCN0778.JPG  DSCN0781.JPG    PICT0016.JPG
DSCN0755.JPG  DSCN0758.JPG  DSCN0761.JPG  DSCN0764.JPG  DSCN0767.JPG  DSCN0770.JPG  DSCN0773.JPG  DSCN0776.JPG  DSCN0779.JPG  PICT0013.JPG    PICT0017.JPG
DSCN0756.JPG  DSCN0759.JPG  DSCN0762.JPG  DSCN0765.JPG  DSCN0768.JPG  DSCN0771.JPG  DSCN0774.JPG  DSCN0777.JPG  DSCN0780.JPG  PICT0013_1.JPG  PICT0018.JPG
rob-linux:/mnt/testdir # sync
rob-linux:/mnt/testdir # cd ..
rob-linux:/mnt # ls           
lost+found  testdir           
rob-linux:/mnt # ls /tmp/sdv.c
/tmp/sdv.c                    
rob-linux:/mnt # cp /tmp/sdv.c .
rob-linux:/mnt # ls             
lost+found  sdv.c  testdir      
rob-linux:/mnt # gcc sdv.c -o sdv
rob-linux:/mnt # ls              
lost+found  sdv  sdv.c  testdir  
rob-linux:/mnt # ./sdv testdir     


####################################################################
### SDV-Sichere Datenvernichtung - Konsolenansicht ; Version 1.0 ###
### Copyright(C)2011 bei Roland K. ; Lizenz LGPL          ###       
### E-Mail: roland.mk@mail.ru                                    ###
####################################################################
Betriebssystem: Unix/Linux                                          

STARTE ARBEITSAUFTRAG...
Anzahl der Eingaben: 1  


### Auftrag abgeschlossen ###

PROTOKOLL:
Anzahl der Vernichteten Dateien:                         33
Anzahl der Vernichteten Verzeichnisse:                   1 
Fehleranzahl beim Oeffnen von Dateien/Verzeichnissen:    0 
Fehleranzahl beim Vernichten von Dateien:                0 

rob-linux:/mnt # cd /test
rob-linux:/test # umount /mnt
rob-linux:/test # ext4magic test.image -f /
Filesystem in use: test.image              


Dump internal Inode 2
Status : Inode is Allocated

Inode: 2   Type: directory    Mode:  0755   Flags: 0x0 
Generation: 0    Version: 0x00000000:00000004          
User:     0   Group:     0   Size: 4096                
File ACL: 0    Directory ACL: 0                        
Links: 3   Blockcount: 8                               
Fragment:  Address: 0    Number: 0    Size: 0          
 ctime: 1315000989:1150784900 -- Sat Sep  3 00:03:09 2011
 atime: 1315000876:0711806032 -- Sat Sep  3 00:01:16 2011
 mtime: 1315000989:1150784900 -- Sat Sep  3 00:03:09 2011
crtime: 1315000717:0000000000 -- Fri Sep  2 23:58:37 2011
Size of extra inode fields: 28                           
        2  d  755 (2)      0      0           4096  3-Sep-2011 00:03 .
        2  d  755 (2)      0      0           4096  3-Sep-2011 00:03 ..
       11  d  700 (2)      0      0          16384  2-Sep-2011 23:58 lost+found
<      12> d  755 (2)      0      0              0  3-Sep-2011 00:03 testdir   
       46  _  400 (1)      0      0          15118  3-Sep-2011 00:00 sdv.c     
       47  _  755 (1)      0      0          16466  3-Sep-2011 00:01 sdv       

ext4magic : EXIT_SUCCESS
rob-linux:/test # ext4magic test.image -m -d test.image.test
Warning: Activate magic-scan or disaster-recovery function, may be some command line options ignored
"test.image.test"  accept for recoverdir                                                            
Filesystem in use: test.image                                                                       

Using  internal Journal at Inode 8
Activ Time after  : Sat Sep  3 00:03:08 2011
Activ Time before : Sat Sep  3 00:04:27 2011
Inode 2 is allocated                        
--------        test.image.test/testdir/DSCN0754.JPG
--------        test.image.test/testdir/DSCN0755.JPG
--------        test.image.test/testdir/DSCN0756.JPG
--------        test.image.test/testdir/DSCN0757.JPG
--------        test.image.test/testdir/DSCN0758.JPG
--------        test.image.test/testdir/DSCN0759.JPG
--------        test.image.test/testdir/DSCN0760.JPG
--------        test.image.test/testdir/DSCN0761.JPG
--------        test.image.test/testdir/DSCN0762.JPG
--------        test.image.test/testdir/DSCN0763.JPG
--------        test.image.test/testdir/DSCN0764.JPG
--------        test.image.test/testdir/DSCN0765.JPG
--------        test.image.test/testdir/DSCN0766.JPG
--------        test.image.test/testdir/DSCN0767.JPG
--------        test.image.test/testdir/DSCN0768.JPG
--------        test.image.test/testdir/DSCN0769.JPG
--------        test.image.test/testdir/DSCN0770.JPG
--------        test.image.test/testdir/DSCN0771.JPG
--------        test.image.test/testdir/DSCN0772.JPG
--------        test.image.test/testdir/DSCN0773.JPG
--------        test.image.test/testdir/DSCN0774.JPG
--------        test.image.test/testdir/DSCN0775.JPG
--------        test.image.test/testdir/DSCN0776.JPG
--------        test.image.test/testdir/DSCN0777.JPG
--------        test.image.test/testdir/DSCN0778.JPG
--------        test.image.test/testdir/DSCN0779.JPG
--------        test.image.test/testdir/DSCN0780.JPG
--------        test.image.test/testdir/DSCN0781.JPG
--------        test.image.test/testdir/PICT0013.JPG
--------        test.image.test/testdir/PICT0013_1.JPG
--------        test.image.test/testdir/PICT0016.JPG  
--------        test.image.test/testdir/PICT0017.JPG  
--------        test.image.test/testdir/PICT0018.JPG  
MAGIC-1 : start lost directory search                 
MAGIC-2 : start lost file search                      
The MAGIC Funktion is currently only for ext3 filesystems available
ext4magic : EXIT_SUCCESS                                           
rob-linux:/test # cd test.image.test/testdir
rob-linux:/test/test.image.test/testdir # ls -l
total 62932                                    
-rw-r--r-- 1 root root 2193375 Sep  3 00:00 DSCN0754.JPG
-rw-r--r-- 1 root root 2278430 Sep  3 00:00 DSCN0755.JPG
-rw-r--r-- 1 root root 2332671 Sep  3 00:00 DSCN0756.JPG
-rw-r--r-- 1 root root 2355042 Sep  3 00:00 DSCN0757.JPG
-rw-r--r-- 1 root root 2360380 Sep  3 00:00 DSCN0758.JPG
-rw-r--r-- 1 root root 2300727 Sep  3 00:00 DSCN0759.JPG
-rw-r--r-- 1 root root 2198645 Sep  3 00:00 DSCN0760.JPG
-rw-r--r-- 1 root root 2268200 Sep  3 00:00 DSCN0761.JPG
-rw-r--r-- 1 root root 2188865 Sep  3 00:00 DSCN0762.JPG
-rw-r--r-- 1 root root 2088098 Sep  3 00:00 DSCN0763.JPG
-rw-r--r-- 1 root root 2218892 Sep  3 00:00 DSCN0764.JPG
-rw-r--r-- 1 root root 2265109 Sep  3 00:00 DSCN0765.JPG
-rw-r--r-- 1 root root 2296054 Sep  3 00:00 DSCN0766.JPG
-rw-r--r-- 1 root root 2349193 Sep  3 00:00 DSCN0767.JPG
-rw-r--r-- 1 root root 2288217 Sep  3 00:00 DSCN0768.JPG
-rw-r--r-- 1 root root 2233435 Sep  3 00:00 DSCN0769.JPG
-rw-r--r-- 1 root root 2086684 Sep  3 00:00 DSCN0770.JPG
-rw-r--r-- 1 root root 2080448 Sep  3 00:00 DSCN0771.JPG
-rw-r--r-- 1 root root 2224433 Sep  3 00:00 DSCN0772.JPG
-rw-r--r-- 1 root root 2260266 Sep  3 00:00 DSCN0773.JPG
-rw-r--r-- 1 root root 2126725 Sep  3 00:00 DSCN0774.JPG
-rw-r--r-- 1 root root 2187941 Sep  3 00:00 DSCN0775.JPG
-rw-r--r-- 1 root root 2121349 Sep  3 00:00 DSCN0776.JPG
-rw-r--r-- 1 root root 2022688 Sep  3 00:00 DSCN0777.JPG
-rw-r--r-- 1 root root 2140619 Sep  3 00:00 DSCN0778.JPG
-rw-r--r-- 1 root root 2288901 Sep  3 00:00 DSCN0779.JPG
-rw-r--r-- 1 root root 2208274 Sep  3 00:00 DSCN0780.JPG
-rw-r--r-- 1 root root 2346156 Sep  3 00:00 DSCN0781.JPG
-rw-r--r-- 1 root root  457884 Sep  3 00:00 PICT0013.JPG
-rw-r--r-- 1 root root  428977 Sep  3 00:00 PICT0013_1.JPG
-rw-r--r-- 1 root root  343546 Sep  3 00:00 PICT0016.JPG
-rw-r--r-- 1 root root  372769 Sep  3 00:00 PICT0017.JPG
-rw-r--r-- 1 root root  469986 Sep  3 00:00 PICT0018.JPG
rob-linux:/test/test.image.test/testdir # file *
DSCN0754.JPG:   JPEG image data, EXIF standard 2.2
DSCN0755.JPG:   JPEG image data, EXIF standard 2.2
DSCN0756.JPG:   JPEG image data, EXIF standard 2.2
DSCN0757.JPG:   JPEG image data, EXIF standard 2.2
DSCN0758.JPG:   JPEG image data, EXIF standard 2.2
DSCN0759.JPG:   JPEG image data, EXIF standard 2.2
DSCN0760.JPG:   JPEG image data, EXIF standard 2.2
DSCN0761.JPG:   JPEG image data, EXIF standard 2.2
DSCN0762.JPG:   JPEG image data, EXIF standard 2.2
DSCN0763.JPG:   JPEG image data, EXIF standard 2.2
DSCN0764.JPG:   JPEG image data, EXIF standard 2.2
DSCN0765.JPG:   JPEG image data, EXIF standard 2.2
DSCN0766.JPG:   JPEG image data, EXIF standard 2.2
DSCN0767.JPG:   JPEG image data, EXIF standard 2.2
DSCN0768.JPG:   JPEG image data, EXIF standard 2.2
DSCN0769.JPG:   JPEG image data, EXIF standard 2.2
DSCN0770.JPG:   JPEG image data, EXIF standard 2.2
DSCN0771.JPG:   JPEG image data, EXIF standard 2.2
DSCN0772.JPG:   JPEG image data, EXIF standard 2.2
DSCN0773.JPG:   JPEG image data, EXIF standard 2.2
DSCN0774.JPG:   JPEG image data, EXIF standard 2.2
DSCN0775.JPG:   JPEG image data, EXIF standard 2.2
DSCN0776.JPG:   JPEG image data, EXIF standard 2.2
DSCN0777.JPG:   JPEG image data, EXIF standard 2.2
DSCN0778.JPG:   JPEG image data, EXIF standard 2.2
DSCN0779.JPG:   JPEG image data, EXIF standard 2.2
DSCN0780.JPG:   JPEG image data, EXIF standard 2.2
DSCN0781.JPG:   JPEG image data, EXIF standard 2.2
PICT0013.JPG:   JPEG image data, JFIF standard 1.01
PICT0013_1.JPG: JPEG image data, JFIF standard 1.01
PICT0016.JPG:   JPEG image data, JFIF standard 1.01
PICT0017.JPG:   JPEG image data, JFIF standard 1.01
PICT0018.JPG:   JPEG image data, JFIF standard 1.01

und ein

Code:

xv *

zeigt mir alle Bilder ohne eine einzige Beschädigung.

Wer so leichtsinnig versucht Sicherheit zu verkaufen handelt grob fahrlässig. Wenn man so ein Programm schreiben will welches wirklich versucht Dateien sicher zu löschen, sollte man sich vorher mal mit der Arbeitsweise des Filesystems auseinandersetzen.

robi

framp · 3 Sep. 2011

robi schrieb:
...Wer so leichtsinnig versucht Sicherheit zu verkaufen handelt grob fahrlässig. Wenn man so ein Programm schreiben will welches wirklich versucht Dateien sicher zu löschen, sollte man sich vorher mal mit der Arbeitsweise des Filesystems auseinandersetzen.

Das erinnert mich an Krimis wo es doch immer wieder vorkommt dass jemand auf ein Blatt Papier etwas geheimes schreibt (darunter liegt natürlich auch Papier), das Papier vernichtet, aber vergisst, dass sein Schreibdurchdruck auf dem darunterliegenden zurückbleibenden Papier für jeden lesbar ist

Anonymous · 3 Sep. 2011

Das Problem ist folgendes. Wenn eine Datei geändert oder überschrieben wird, werden andere Datenblöcke für diese Datei verwendet. Die alten Datenblöcke werden also dabei nicht überschrieben, sondern im Filesystem nur als wieder frei verfügbar frei gegeben, wie hier zu sehen ist.

Code:

rob-linux:/test # mount -o loop test.image /mnt   
rob-linux:/test # ext4magic test.image -f /                                                                                                                           
Filesystem in use: test.image                                                                                                                                         

Dump internal Inode 2
Status : Inode is Allocated

Inode: 2   Type: directory    Mode:  0755   Flags: 0x0 
Generation: 0    Version: 0x00000000:00000004          
User:     0   Group:     0   Size: 4096                
File ACL: 0    Directory ACL: 0                        
Links: 3   Blockcount: 8                               
Fragment:  Address: 0    Number: 0    Size: 0          
 ctime: 1315000989:1150784900 -- Sat Sep  3 00:03:09 2011
 atime: 1315000876:0711806032 -- Sat Sep  3 00:01:16 2011
 mtime: 1315000989:1150784900 -- Sat Sep  3 00:03:09 2011
crtime: 1315000717:0000000000 -- Fri Sep  2 23:58:37 2011
Size of extra inode fields: 28                           
        2  d  755 (2)      0      0           4096  3-Sep-2011 00:03 .
        2  d  755 (2)      0      0           4096  3-Sep-2011 00:03 ..
       11  d  700 (2)      0      0          16384  2-Sep-2011 23:58 lost+found
<      12> d  755 (2)      0      0              0  3-Sep-2011 00:03 testdir   
       46  _  400 (1)      0      0          15118  3-Sep-2011 00:00 sdv.c     
       47  _  755 (1)      0      0          16466  3-Sep-2011 00:01 sdv       

ext4magic : EXIT_SUCCESS
rob-linux:/test # ext4magic test.image -f sdv.c -x
Filesystem in use: test.image                     


Dump internal Inode 46
Status : Inode is Allocated

Inode: 46   Type: regular    Mode:  0400   Flags: 0x80000 [-------------e-]
Generation: 3499247080    Version: 0x00000000:00000001                     
User:     0   Group:     0   Size: 15118                                   
File ACL: 0    Directory ACL: 0                                            
Links: 1   Blockcount: 32                                                  
Fragment:  Address: 0    Number: 0    Size: 0                              
 ctime: 1315000859:0850780916 -- Sat Sep  3 00:00:59 2011
 atime: 1315000874:2191808776 -- Sat Sep  3 00:01:14 2011
 mtime: 1315000859:0850780916 -- Sat Sep  3 00:00:59 2011
crtime: 1315000859:0850780916 -- Sat Sep  3 00:00:59 2011
Size of extra inode fields: 28
Level Entries                   Logical                  Physical Length Flags
 0/ 0   1/  1           0 -           3       56824 -       56827      4
ext4magic : EXIT_SUCCESS

Das ist jetzt die Inode deiner c-Datei, die Datenblöcke dieser Datei sind 56824 bis 56827.
Wir überschreiben diese Datei jetzt mit Zufallszahlen, damit wird diese Datei deiner Meinung nach vollkommen zerstört.

Code:

rob-linux:/test # dd if=/dev/urandom of=/mnt/sdv.c bs=1 count=15118
15118+0 records in
15118+0 records out
15118 bytes (15 kB) copied, 0.350943 s, 43.1 kB/s

jetzt schauen wir uns noch einmal die Inode für diese Datei an.

Code:

rob-linux:/test # ext4magic test.image -f /
Filesystem in use: test.image


Dump internal Inode 2
Status : Inode is Allocated

Inode: 2   Type: directory    Mode:  0755   Flags: 0x0
Generation: 0    Version: 0x00000000:00000004
User:     0   Group:     0   Size: 4096
File ACL: 0    Directory ACL: 0
Links: 3   Blockcount: 8
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 1315000989:1150784900 -- Sat Sep  3 00:03:09 2011
 atime: 1315000876:0711806032 -- Sat Sep  3 00:01:16 2011
 mtime: 1315000989:1150784900 -- Sat Sep  3 00:03:09 2011
crtime: 1315000717:0000000000 -- Fri Sep  2 23:58:37 2011
Size of extra inode fields: 28
        2  d  755 (2)      0      0           4096  3-Sep-2011 00:03 .
        2  d  755 (2)      0      0           4096  3-Sep-2011 00:03 ..
       11  d  700 (2)      0      0          16384  2-Sep-2011 23:58 lost+found
<      12> d  755 (2)      0      0              0  3-Sep-2011 00:03 testdir
       46  _  400 (1)      0      0          15118  3-Sep-2011 00:00 sdv.c
       47  _  755 (1)      0      0          16466  3-Sep-2011 00:01 sdv

ext4magic : EXIT_SUCCESS
rob-linux:/test # ext4magic test.image -f sdv.c -x
Filesystem in use: test.image

Dump internal Inode 46
Status : Inode is Allocated

Inode: 46   Type: regular    Mode:  0400   Flags: 0x80000 [-------------e-]
Generation: 3499247080    Version: 0x00000000:00000001
User:     0   Group:     0   Size: 15118
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 32
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 1315004210:2459782456 -- Sat Sep  3 00:56:50 2011
 atime: 1315000874:2191808776 -- Sat Sep  3 00:01:14 2011
 mtime: 1315004210:2459782456 -- Sat Sep  3 00:56:50 2011
crtime: 1315000859:0850780916 -- Sat Sep  3 00:00:59 2011
Size of extra inode fields: 28
Level Entries                   Logical                  Physical Length Flags
 0/ 0   1/  1           0 -           3       33280 -       33283      4
ext4magic : EXIT_SUCCESS
rob-linux:/test #

Die Inodenummer ist geblieben, die Größe auch, die Zeitstempel haben sich geändert aber auch die verwendeten Datenblöcke.
Die Orginaldatei hat in diesem ext4 Filesystem die Dateblöcke 56824 bis 56827 in Verwendung. Nach dem überschreiben dieser Datei mit dd hat die Datei aber die Datenblöcke 33280 - 33283 die orginal Blöcke sind also überhaupt nicht verändert worden, und dort stehen nach wie vor die alten Daten der Datei drin. Überschrieben wurde also nur irgendwelcher freier Speicher und nicht die Dateidaten wie erhofft, die stehen immer noch dort wo sie ursprünglich auch gestanden haben. Nur gehören sie nicht mehr dieser Inodenummer.

Code:

rob-linux:/test # hexdump -C /mnt/sdv.c | head
00000000  ef f1 9c 0b ef cb 1e 06  25 0b 62 63 05 c5 2c 63  |........%.bc..,c|
00000010  e7 48 40 3b 70 b1 c8 ce  1e 0a 4b 4a 9d fd f5 b3  |.H@;p.....KJ....|
00000020  cf 93 d5 d0 0f aa 68 0b  7f b4 45 8a 81 e4 5e e9  |......h...E...^.|
00000030  2a e0 a8 c6 70 d6 c3 1d  56 74 74 2b ad 31 7f d4  |*...p...Vtt+.1..|
00000040  2b 44 bb 85 7d d7 a0 4f  e8 5c 30 68 2b f3 a6 ac  |+D..}..O.\0h+...|
00000050  1d e0 96 d1 5b 1f e4 d4  3c 9d dd dc b6 07 7e a6  |....[...<.....~.|
00000060  12 43 d3 4f 9c 1c 71 9d  02 94 b4 ec 44 46 d2 4a  |.C.O..q.....DF.J|
00000070  c6 37 44 ec 0e c9 1a 87  7b b1 b7 e7 0b 5b 84 88  |.7D.....{....[..|
00000080  68 23 02 a2 72 1c 8a 85  9a ad cd 4f 86 79 89 26  |h#..r......O.y.&|
00000090  41 2d 65 39 fd 92 2b 91  3f 0e b1 c1 2e 9d f3 6b  |A-e9..+.?......k|

Die Datei im Filesystem ist scheinbar zerstört worden, doch die Datenblöcke wo die ursprüngliche Daten der Datei gestanden haben, haben immer noch den orginal Inhalt. Dieser ist also wirklich nicht überschrieben worden.

Code:

rob-linux:/test # ext4magic test.image -B 56824 | head -20
Filesystem in use: test.image

Dump Filesystemblock      56824   Status : Block is Unallocated
    0000:  2f 2a 0a 20 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d    /*. ============
    0010:  3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d    ================
    0020:  3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d    ================
    0030:  3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d    ================
    0040:  3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d 3d    ================
    0050:  0a 20 4e 61 6d 65 20 20 20 20 20 20 20 20 20 20    . Name
    0060:  20 3a 20 53 44 56 2d 53 69 63 68 65 72 65 44 61     : SDV-SichereDa
    0070:  74 65 6e 76 65 72 6e 69 63 68 74 75 6e 67 2e 63    tenvernichtung.c
    0080:  0a 20 41 75 74 6f 72 20 20 20 20 20 20 20 20 20    . Autor
    0090:  20 3a 20 52 6f 6c 61 6e 64 20 4b 2e 0a 20 56 65     : Roland K.. Ve
    00a0:  72 73 69 6f 6e 20 20 20 20 20 20 20 20 3a 20 56    rsion        : V
    00b0:  65 72 73 69 6f 6e 20 31 2e 30 0a 20 43 6f 70 79    ersion 1.0. Copy
    00c0:  72 69 67 68 74 20 20 20 20 20 20 3a 20 43 6f 70    right      : Cop
    00d0:  79 72 69 67 68 74 28 43 29 32 30 31 31 20 62 65    yright(C)2011 be
    00e0:  69 20 52 6f 6c 61 6e 64 20 4b 2e 0a 20 4c 69 7a    i Roland K.. Liz
    00f0:  65 6e 7a 20 20 20 20 20 20 20 20 20 3a 20 4c 47    enz         : LG
    0100:  50 4c 0a 20 42 65 73 63 68 72 65 69 62 75 6e 67    PL. Beschreibung

Daraus folgt, sehr viele Änderungen an Dateien hinterlassen im Filesystem unbemerkt Kopien ihres ursprünglichen Inhalts zurück. Wer der Meinung ist, eine Datei ist so geheim, das sie sicher gelöscht werden muss, übersieht oftmals , dass er von dieser Datei eventuell noch mehrere für ihn nicht sichtbare Kopien im Filesystem hat. Niemand wird sich die Mühe machen mit aufwendigen Methoden die letzte Version einer Datei wiederherzustellen, wenn er die Kopien aller Vorgängerversionen der selben Datei hinterher geschmissen bekommt.

In diesem Beispiel hier braucht man sich nur die History der Inode 46 aus dem Journal anzusehen, und dann die richtige Inodekopie aus dem Jounal zu recovern und schon hat man die totsicher mit Zufallszahlen überschriebene Datei wieder.
Schauen wir uns mal die History dieser Inode an. Zu erkennen am Anfang war sie leer, dann zu erkennen die Inode mit den Datenblöcke ab 56824 und dann die Inode die die Datenblöcke ab 33280 nutzt.

Code:

rob-linux:/test # ext4magic test.image -I 46 -Jx          
Filesystem in use: test.image                             

Using  internal Journal at Inode 8

Journal Super Block:
 Signature: 0xc03b3998 
 Blocktype : V2 superblock 
 Journal block size: 4096  
 Number of journal blocks: 8192 
 Journal block where the journal actually starts: 1
 Sequence number of first transaction: 14          
 Journal block of first transaction: 1             
 Error number: 0                                   
 Compatible Features: 0                            
 Incompatible features: 1                          
 Read only compatible features: 0                  
 Journal UUID: 0a90d32c-5eda-451d-9146-963c53dcace9 
 Number of file systems using journal: 1            
 Location of superblock copy: 0                     
 Max journal blocks per transaction: 0              
 Max file system blocks per transaction: 0          
 IDs of all file systems using the journal:         
01. : 00000000-0000-0000-0000-000000000000          
                                                    


Dump Inode 46 from journal transaction 6
Inode: 46   Type: regular    Mode:  0400   Flags: 0x80000 [-------------e-]
Generation: 3499247080    Version: 0x00000000:00000001                     
User:     0   Group:     0   Size: 0                                       
File ACL: 0    Directory ACL: 0                                            
Links: 1   Blockcount: 0                                                   
Fragment:  Address: 0    Number: 0    Size: 0                              
 ctime: 1315000859:0850780916 -- Sat Sep  3 00:00:59 2011                  
 atime: 1315000859:0850780916 -- Sat Sep  3 00:00:59 2011                  
 mtime: 1315000859:0850780916 -- Sat Sep  3 00:00:59 2011                  
crtime: 1315000859:0850780916 -- Sat Sep  3 00:00:59 2011                  
Size of extra inode fields: 28                                             
Level Entries                   Logical                  Physical Length Flags

Dump Inode 46 from journal transaction 8
Inode: 46   Type: regular    Mode:  0400   Flags: 0x80000 [-------------e-]
Generation: 3499247080    Version: 0x00000000:00000001                     
User:     0   Group:     0   Size: 15118                                   
File ACL: 0    Directory ACL: 0                                            
Links: 1   Blockcount: 32                                                  
Fragment:  Address: 0    Number: 0    Size: 0                              
 ctime: 1315000859:0850780916 -- Sat Sep  3 00:00:59 2011                  
 atime: 1315000874:2191808776 -- Sat Sep  3 00:01:14 2011                  
 mtime: 1315000859:0850780916 -- Sat Sep  3 00:00:59 2011                  
crtime: 1315000859:0850780916 -- Sat Sep  3 00:00:59 2011                  
Size of extra inode fields: 28                                             
Level Entries                   Logical                  Physical Length Flags
 0/ 0   1/  1           0 -           3       56824 -       56827      4      

Dump Inode 46 from journal transaction 14
Inode: 46   Type: regular    Mode:  0400   Flags: 0x80000 [-------------e-]
Generation: 3499247080    Version: 0x00000000:00000001                     
User:     0   Group:     0   Size: 15118                                   
File ACL: 0    Directory ACL: 0                                            
Links: 1   Blockcount: 32                                                  
Fragment:  Address: 0    Number: 0    Size: 0                              
 ctime: 1315004210:2459782456 -- Sat Sep  3 00:56:50 2011                  
 atime: 1315000874:2191808776 -- Sat Sep  3 00:01:14 2011                  
 mtime: 1315004210:2459782456 -- Sat Sep  3 00:56:50 2011                  
crtime: 1315000859:0850780916 -- Sat Sep  3 00:00:59 2011                  
Size of extra inode fields: 28                                             
Level Entries                   Logical                  Physical Length Flags
 0/ 0   1/  1           0 -           3       33280 -       33283      4      

Dump Inode 46 from journal transaction 0
Inode: 46   Type: regular    Mode:  0400   Flags: 0x80000 [-------------e-]
Generation: 3499247080    Version: 0x00000000:00000001                     
User:     0   Group:     0   Size: 15118                                   
File ACL: 0    Directory ACL: 0                                            
Links: 1   Blockcount: 32                                                  
Fragment:  Address: 0    Number: 0    Size: 0                              
 ctime: 1315004210:2459782456 -- Sat Sep  3 00:56:50 2011
 atime: 1315000874:2191808776 -- Sat Sep  3 00:01:14 2011
 mtime: 1315004210:2459782456 -- Sat Sep  3 00:56:50 2011
crtime: 1315000859:0850780916 -- Sat Sep  3 00:00:59 2011
Size of extra inode fields: 28
Level Entries                   Logical                  Physical Length Flags
 0/ 0   1/  1           0 -           3       33280 -       33283      4
ext4magic : EXIT_SUCCESS

Nun gehen wir einfach her und recovern die Inodekopie die auf die orginal Datenblöcke verweißt.

Code:

rob-linux:/test # ext4magic test.image -r -I 46 -t 8 -d test.image.test/
"test.image.test/"  accept for recoverdir
Filesystem in use: test.image

Using  internal Journal at Inode 8

Dump Inode 46 from journal transaction 8
Inode: 46   Type: regular    Mode:  0400   Flags: 0x80000
Generation: 3499247080    Version: 0x00000000:00000001
User:     0   Group:     0   Size: 15118
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 32
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 1315000859:0850780916 -- Sat Sep  3 00:00:59 2011
 atime: 1315000874:2191808776 -- Sat Sep  3 00:01:14 2011
 mtime: 1315000859:0850780916 -- Sat Sep  3 00:00:59 2011
crtime: 1315000859:0850780916 -- Sat Sep  3 00:00:59 2011
Size of extra inode fields: 28
--------        test.image.test//<46>
ext4magic : EXIT_SUCCESS

Hat funktioniert und nun schaun wir mal rein in die Datei die wir soeben recovert haben. Und siehe da

Code:

rob-linux:/test # head "test.image.test//<46>"
/*
 ============================================================================
 Name           : SDV-SichereDatenvernichtung.c
 Autor          : Roland K.
 Version        : Version 1.0
 Copyright      : Copyright(C)2011 bei Roland K.
 Lizenz         : LGPL
 Beschreibung   : Anwendung zur sicheren und unwiederherstellbaren Vernichtung von Dateien.

 Letzte �nderung: 28.08.2011

Und das Problem bleibt das Gleiche ob man nur eine Datei auf der Konsole mit irgendwelchen Befehle überschreibt, oder dafür extra ein Programm in irgend einer Programmiersprache schreibt. Wenn sicher löschen, dann bei Dateien ganz gezielt die Blöcke überschreiben die von der Datei genutzt werden und nicht die Datei selbst. Was aber in den meisten Fällen sowieso nicht ausreicht, da wie beschrieben es jede Menge Kopien von Vorgängerversionen im Filesystem geben könnte. Also bleibt nur das ganze Filesystem zu überschreiben alles andere ist mehr oder weniger unsicher und maximal geeignet meine Oma davon abzuhalten zu lesen was sie nichts angeht..

Aber das ist noch nicht mal der einzige schwerwiegende Fehler in deinem Programm. Da ist noch einer, selbst wenn du mit dieser Methode die richtigen Datenblöcke ansprechen würdest, sie würden gar nicht wirklich überschrieben. Es würden zwar die Kopien der Datenblöcke im Cache des Rechners überschrieben, aber da die geänderte Datei nach dieser Änderung dann sofort gelöscht wird, würde diese Änderung in 99% aller Fälle gar nicht erst auf die Platte geschrieben. Änderungen im Cache werden im Normalfall nur alle paar Sekunden bis Minuten automatisch auf Platte geschrieben. Auf Platte würde dann nur das Löschen vermerkt werden, ohne die geänderten Datenblöcke vorher noch mal auf Platte zu schreiben. So dumm ist der Rechner ja nun auch nicht, das er erst sinnlos Daten auf die Platte schreibt, von denen er zu diesem Zeitpunkt schon weiß, das sie gar nicht mehr existieren. Was das Programm derzeit macht, ist normales löschen, dafür hättest du dir die Mühe nicht machen brauchen.

Jetzt mal ganz ehrlich, ausprobiert hast du das mit Sicherheit mit nicht einem Programm welches gelöschte Dateien wieder herstellen kann.
Mit Sicherheit, das einzig vernichtente was ich derzeit hier sehe, ist wohl mein Kritik.
Aber nicht entmutigen lassen, scheint ein Anfänger Werk zu sein, und glaube mir, ich kann nachvollziehen wie viel Zeit du dort rein gesteckt hast. Ein paar gute Ansätze sind drin. Und ich habe dir jetzt aufgezeigt wo deine dicken Denkfehler liegt. Also lass dir was einfallen, ich schau gelegentlich mal wieder bei deinem Projekt vorbei. Dann kümmern wir uns dann noch um ein paar Kleinigkeiten und Schönheitsfehler. Nur mit Programmieren und debugen selbst kann man das Programmieren überhaupt erst mal erlernen, Bücher sind dafür nicht geeignet.

robi

xcatpc · 3 Sep. 2011

robi schrieb:
Gute Idee, aber funktioniert leider überhaupt nicht. sprich ich kann deine ach so sicher geglaubt gelöschten Dateien problemlos wiederherstellen.

robi

Danke!
Muss irgendetwas schief gelaufen sein, da ich mit der vorherigen Version alle Daten unwiederherstellbar gelöscht habe (zerstört)
Werde mich mal bei Zeit ransetzten und das Problem beheben.

Anonymous · 3 Sep. 2011

xcatpc schrieb:
Muss irgendetwas schief gelaufen sein, da ich mit der vorherigen Version alle Daten unwiederherstellbar gelöscht habe (zerstört)
Werde mich mal bei Zeit ransetzten und das Problem beheben.

Wie hast du denn das Wiederherstellen getestet?

robi

/dev/null · 3 Sep. 2011

BTW:
Im Bereich der IT-Sicherheit haben wir eine uralte Regel, welche besagt, dass eine Datei viel leichter erzeugt, als ohne Spuren zu hinterlassen gelöscht werden kann.
Früher wurde in Dateimanagern als sichere Löschoption zum Bsp. der "Shredder" (shred) angeboten. Um kein falsches Sicherheitsgefühl aufkommen zu lassen ist das weggefallen.

Tipp:
Schau dir mal an, was (kommerzielle) Forensiktools zu leisten in der Lage sind. Dieses wird ja in der dazugehörenden Werbung ab und an veröffentlicht.

MfG Peter

abgdf · 3 Sep. 2011

Hmm, ich verwende da immer wipe:

http://wipe.sourceforge.net

Löscht das ebenfalls so unsicher?

Gruß

Anonymous · 3 Sep. 2011

abgdf schrieb:
Hmm, ich verwende da immer wipe:
http://wipe.sourceforge.net
Löscht das ebenfalls so unsicher?

Ne Ne,, wipe macht das schon richtig. Was mir aber da letztes mal bei Tests bei ext3/ext4 aufgefallen ist, es macht die Verzeichnisse langsam, da es mehrfach beim löschen riesige Zufallsdateinamen dort reinschreibt und damit die Verzeichnissdateien aufbläht und diese gelöschten Dateinamen stehen dann erst mal eine ganze Zeit unnötigerweise zwischen den anderen Verzeichnisdaten herum bis das Filesystem das so nach und nach von selbst bereinigt hat. Und wenn man dann mit einem solchem Verzeichnis weiterarbeitet, dann könnte es eventuell passieren das es uU ein paar 100stel Sekundenbruchstücke länger dauert bis die gesuchten Dateinamen gefunden werden. Wenn man so was in Großen Verzeichnissen oder massiv im Filesystem macht, die Verzeichnisse dabei aber nicht komplett mit löscht und mit solchen Verzeichnissen dann weiterarbeiten will, sollte man hinterher wohl mal "fsck -D " drüber laufen lassen. Müsste man sich mal genauer anschauen, habe ich aber jetzt weder Lust noch wirklich Zeit dazu.
Aber die gelöschten Daten sind nach wipe richtig weg, bleiben eben nur eventuell alte schon lange ungültige Dateiduplikate der zerstörten Dateien oder Fragmente davon im Filesystem übrig, wenn man nur einzelne Dateien löscht. Einzlene solcher Fragmente können sich ewig halten, auch wenn das Filesystem gut in Benutzung ist.

robi

willi wühlkelle · 12 Juni 2014

Moin.mit dem Thema sicheres löschen beschäftige ich mich auch seit 3 Wochen.
Shred hat auf ext3/4 das Problem das es nach vielfachem überschreiben die Datei umbenent und wo anders hin verschiebt,ist also wiederherstellbar+journalkopie.
Das erste was ich bei einem solchen Dateisystem machen würde ,wäre das journaling abschalten.Hab die Befehle für die Konsole da,aber bei mir funktioniert es nicht.

Deshalb benutze ich ext2. Das System hat kein Journal.(var log message sagt dies) Wenn mann dann mit wipe arbeitet,sollten die gelöschten Dateien nicht wiederzufinden sein.
Viel Spass beim weiteren ausprobieren
willi

muck19 · 12 Juni 2014

willi wühlkelle schrieb:
Moin.mit dem Thema sicheres löschen beschäftige ich mich auch seit 3 Wochen.

Dann bist du spongebob468 aus dem opensuse-Forum -

Viel Spass beim weiteren ausprobieren

Du weisst, dass du hier auf drei Jahre alte Beiträge antwortest?
Und warum sollte das jemand ausprobieren? Es gibt kaum Leute, die eine ernsthafte Datenvernichtunsparanoia haben.

Gruss
Michael

tomm.fa · 12 Juni 2014

Ich mach hier dann, bevor noch mehr dieser sinnvollen Ideen hier auftauchen, mal zu. Möchte jemand doch noch was Vernünftiges beitragen, PN an einen der Mods oder Admins/Adminsen.

SDV - Sichere Datenvernichtung

xcatpc

Newbie

Anonymous

Gast

framp

Moderator

Anonymous

Gast

xcatpc

Newbie

Anonymous

Gast

/dev/null

Moderator

abgdf

Guru

Anonymous

Gast

willi wühlkelle

Newbie

muck19

Hacker

tomm.fa

Administrator