[SOLVED] Overwriting free space or overwriting single files restored by photorec

fcrok · 09-15-2012, 06:18 AM

I'm trying to destroy some already deleted file on my hard drive. I can recover those files easily with photorec, so my first attempt was to create a file filled with zero bits until the partition was full. However, after deleting this file, photorec discovered every single file again. Uses ext4 (the fs type of the partition in question) run-length compression? In case this is so, the solution would be to create a file filled with random bits, but this takes way too long (I copied around 8MB per second) considering I only want to overwrite some MBs.

So my last try was to extract the positions of the files from the photorec logfile and apply dd only to some ranges where the files were located, this time using random bits:

If this was the file entry within photorec's report.xml

Code:

<fileobject>
  <filename>f0272760.txt</filename>
  <filesize>114</filesize>
  <byte_runs>
    <byte_run offset="0" img_offset="52139873280" len="114"/>
  </byte_runs>
</fileobject>

my dd command looked like this

Code:

dd if=/dev/urandom of=/dev/sda bs=1 count=114 seek=52139873280 conv=notrunc

This broke up my whole system.

Any ideas how I can destroy those files w/o creating a large random file? Maybe my dd command only needs some adjustments?

Hope you have some advice for me

SecretCode · 09-15-2012, 06:46 AM

Quote:

Originally Posted by fcrok

I'm trying to destroy some already deleted file on my hard drive. I can recover those files easily with photorec, so my first attempt was to create a file filled with zero bits until the partition was full. However, after deleting this file, photorec discovered every single file again.

My first thought is that something is wrong with this - it shouldn't be possible. When you say photorec discovered the files, could it actually recover the contents? Or was it just recovering the inodes with zeroed contents?

I assume you're deleting the files with rm, not with a file manager that uses a trashbin.

I assume the hard drive is a single partition.

fcrok · 09-15-2012, 06:58 AM

I can recover the entire file (It is possible to view JPEGs and read text files). The files have been deleted using rm or removed from the trash.

My hard drive has three partitions, one for the root fs, one for the swap and one for the home folders, while I only recovered files from the home partition.

SecretCode · 09-15-2012, 07:43 AM

Are all the partitions ext4? Do you have any special features like RAID or lvm in place? Are there compressed or encrypting file systems involved?

And ... is it a regular spinning hard disk, not SSD?

Note the output of df /home after deleting all these files;
then create your space-filling files of zeroes, and check df /home again ... it must say 0 available.

Unless you have weird mount options, creating a file with zeroes using dd should actually overwrite that much space. (Techniques like fallocate will NOT write anything to the disk.)

It wouldn't hurt to post the exact commands and output here. Since something is weird.

ntubski · 09-15-2012, 07:48 AM

Quote:

Originally Posted by fcrok

My hard drive has three partitions, one for the root fs, one for the swap and one for the home folders, while I only recovered files from the home partition.

If you have partitions, your dd command should have used /dev/sdan (where n is the number matching your home partition, run mount to see which).

The shred command is designed specifically to do this kind of thing, but I think it can't help if you already removed the file.

fcrok · 09-15-2012, 08:18 AM

df before creating file:

Code:

% df -h
Filesystem              Size  Used Avail Use% Mounted on
rootfs                   46G  5.5G   39G  13% /
dev                     1.7G     0  1.7G   0% /dev
run                     1.7G  372K  1.7G   1% /run
/dev/sda1                46G  5.5G   39G  13% /
shm                     1.7G  696K  1.7G   1% /dev/shm
tmpfs                   1.7G   24K  1.7G   1% /tmp
/dev/sda3               246G   17G  217G   8% /home

df after creating file is something like this:

Code:

% df -h
Filesystem              Size  Used Avail Use% Mounted on
rootfs                   46G  5.5G   39G  13% /
dev                     1.7G     0  1.7G   0% /dev
run                     1.7G  372K  1.7G   1% /run
/dev/sda1                46G  5.5G   39G  13% /
shm                     1.7G  696K  1.7G   1% /dev/shm
tmpfs                   1.7G   24K  1.7G   1% /tmp
/dev/sda3               246G  233G  0      8% /home

Code:

% fdisk -l /dev/sda

Disk /dev/sda: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000e52fd

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63    97659134    48829536   83  Linux
/dev/sda2        97659135   101562929     1951897+  82  Linux swap / Solaris
/dev/sda3       101562930   625142447   261789759   83  Linux

Code:

% mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=1773364k,nr_inodes=215719,mode=755)
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
/dev/sda1 on / type ext4 (rw,relatime,data=ordered)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
binfmt on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
/dev/sda3 on /home type ext4 (rw,relatime,data=ordered)

As you see sda1 and sda3 are formatted with ext4 fs, sda2 is used as swap. I do not use anything like LVM or RAID and have no compressed or encrypted partitions as far as I know (But I am really sure that there is nothing like this).

I created the file using the following command:

Code:

% pwd
/home/fcrok
% dd if=/dev/zero of=largefile

I have no SSD but a spinning HD

@ntubski: Are you sure the photorec data refers to the selected partition rather than to the entire HD?

\edit: Information about LVM, RAID and fs types added

SecretCode · 09-15-2012, 08:44 AM

Quote:

Originally Posted by fcrok

df before creating file:

Code:

% df -h
Filesystem              Size  Used Avail Use% Mounted on
/dev/sda3               246G   17G  217G   8% /home

df after creating file is something like this:

Code:

% df -h
Filesystem              Size  Used Avail Use% Mounted on
/dev/sda3               246G  233G  0      8% /home

That's odd: your Use% hasn't changed. And Used+Avail does not add up to Size (whereas it does in the first case, otherwise I would say it is because of the 5% reserved by default by ext4).

btw this is one time where the -h option to df doesn't help!

Run

Code:

hexdump -C largefile

to make sure it's all zeroes
and

Code:

ls -l largefile
du largefile

to make sure it really uses that much space (as opposed to just having it allocated)

SecretCode · 09-15-2012, 08:50 AM

Quote:

Originally Posted by SecretCode

because of the 5% reserved by default by ext4

Actually this could be something to do with it ... what is

Code:

sudo tune2fs -l /dev/sda3 | grep "Reserved block count"

Your largefile may not be allowed to fill the entire space because of the system's reserved block count

fcrok · 09-15-2012, 09:03 AM

tune2fs give the following:

Code:

% sudo tune2fs -l /dev/sda3 | grep "Reserved block count"
Reserved block count:     3272371

Please note that the difference in the second df snippet was just guessed because I deleted the file, otherwise I wasn't able to start XFCE. I will run hexdump and du as soon as I've recreated the file.

Oh, I almost forgot: Big thank for your help

SecretCode · 09-15-2012, 09:16 AM

Quote:

Originally Posted by fcrok

tune2fs give the following:

Code:

% sudo tune2fs -l /dev/sda3 | grep "Reserved block count"
Reserved block count:     3272371

Please note that the difference in the second df snippet was just guessed because I deleted the file, otherwise I wasn't able to start XFCE. I will run hexdump and du as soon as I've recreated the file.

Not very sporting to post inaccurate output

Trying setting reserved blocks to zero, temporarily. Read up on tune2fs (because I'm not sure of the exact syntax and possible gotchas) ... something like

Code:

sudo tune2fs -m 0 /dev/sda3

Quote:

Originally Posted by fcrok

Oh, I almost forgot: Big thank for your help

There's a button for that

ntubski · 09-15-2012, 10:19 AM

Quote:

Originally Posted by fcrok

@ntubski: Are you sure the photorec data refers to the selected partition rather than to the entire HD?

Good point, I only guessed that based on your system breaking after the dd command. Looking at your fdisk numbers the photorec offset would end up in the home partition even counting from the beginning of the HD, so I can't explain how your system broke anyway...

SecretCode · 09-15-2012, 10:41 AM

If another file was allocated there after the photorec run and before the dd ... any dot-file for any app or the desktop environment ... it could very easily cause instability.

Using dd like that is always going to be dangerous. And it shouldn't be necessary for this requirement.

fcrok · 09-15-2012, 10:52 AM

Maybe there is a tool which checks whether an inode refers to a given part of the partition or not? This could make my dd command safe.

fcrok · 09-15-2012, 11:20 AM

Okay I made a new file, 217GB of size and this is the output of du largefile and ls -l largefile:

Code:

% du largefile
226920920	largefile
% ls -l largefile 
-rw-r--r-- 1 fcrok users 232366993408 Sep 15 18:11 largefile

hexdump needs some time to read so I will add this later, but currently the output is

Code:

0000000 0000 0000 0000 0000 0000 0000 0000 0000
*

I will now set reserved block count to zero, fill up the left space and run photorec again.

OlRoy · 09-15-2012, 11:22 AM

I never used PhotoRec, but what exactly did you choose here?

Quote:

Carve the partition or unallocated space only

from the whole partition (useful if the filesystem is corrupted) or
from the unallocated space only

Did you delete the files, restore them to /home, and then eventually run PhotoRec again and select "from the whole partition"? If so you should have chosen "from the unallocated space only."