My goal is to have files of original size that can't be opened (or recovered) in their respective software such as MS Office Word. My purpose is to simulate presence of files while I don't want to share any of the files contents. Ideally file contents should be fully overwritten with random bytes while file size should stay the same as original.

I know that sometimes this can be done with hex editor or even notepad where one could change just few bytes and the file renders unusable. But it may not always work for some formats like images and audio that still could be opened but with artifacts.

For the most inquisitive of users still demanding me to answer the question "Why do you need this?" - I need this because I don't want to share my developments with some people that force me to share the files. Sometimes you just need. You can think of many other use cases - to simulate payload for file copy or backup operations, or to test the software you develop can handle junk gracefully.

I've tested a number of secure shred utilities that are able overwrite files with random data but after that those files get deleted. I haven't seen an option to turn off the deletion step. If such an option existed that would be a solution.

  • 4
    @Ramhound: that's ridiculous. The software to do this might not have been already written, but it's almost trivial to write (though a little more than a one-liner in most programming languages). Of course there is a way to query the size of a file and write exactly that many zero (or random) bytes to it! – Celada Jun 15 '13 at 12:52
  • Technically an interesting question, but why would you want to? It sounds vindictive: "If someone copies my files I want his software/system to crash"? Not worth the trouble IMO – Jan Doggen Jun 17 '13 at 10:21
  • 2
    Why do these "destroyed" files have to be the same size as the original? They are unusable. Why would it matter which size they are? – Der Hochstapler Jun 19 '13 at 12:10
  • @OliverSalzburg I need to keep original size in order the files list to look verisimilar in Explorer details view. – Mike Jun 19 '13 at 16:44

I've wrote a quick approach utilizing the Random Data File Creator.

Mike noted that RDFC doesn't correctly fill the file with random data. I've emailed the author and reported this issue. For the time being, I've implemented a drop-in replacement for rdfc.exe. If you want to compile and use it, please see How do you compile a project from source?

This Windows command line script will do what you want:

IF "%1"=="" GOTO missingParam
GOTO :begin

ECHO Missing target. Use %~nx0 [DRIVE:\]DIRECTORY
GOTO :eof

SET RDFC=%CD%\rdfc.exe
CALL :treeProcess
GOTO :eof

FOR %%f IN (*.*) DO (
  ECHO | SET /P=Shredding %%f... 
  %RDFC% %%f %%~zf B overwrite > NUL
  ECHO %%~zf random bytes written.
FOR /D %%d IN (*) DO (
    CD %%d
    CALL :treeProcess
    CD ..

It requires that rdfc.exe is placed in the same directory as the script. The script will require 1 parameter, the target directory. Every single file in the target directory will be replaced with a file of exactly the same size, but filled with random data.

enter image description here

  • I love how you do recursion in the script – Mike Jun 19 '13 at 16:47
  • 1
    @Mike: I never really checked the output, I just figured it provides what it advertises :P There were other suggestions at stackoverflow.com/questions/533636/… though. This was just the most elegant as it seems. And, yes, I obviously create all my answers from other SO answers ;D – Der Hochstapler Jun 19 '13 at 18:11
  • 1
    @Mike: "I need this because I don't want to share my developments with some people that force me to share the files." - Frankly, I don't see how they will fail to suspect anything if none of the files you share with them will open, unless they are brain-dead. And if they are indeed fooled so easily, does it really matter what sort of (random) data is present in the files? How will totally (pseudo-)random contents affect anything as compared to a repeated sequence of "2 random bytes followed by 2 zero bytes"? – Karan Jun 20 '13 at 0:55
  • 1
    @Mike And you're sure that they won't just ask you to bring another copy? – Der Hochstapler Jun 20 '13 at 9:55
  • 1
    @Mike if an optical disk/USB flash drive fails then they wouldn't be able to read anything, let alone see the files. Even if just a few sectors were corrupted, the majority of files would still be readable (or at minimum, a good portion of their contents). And if you're dealing with files on a network/corporate drive, it's likely they also take periodic backups, rendering this technique even less effective. – Breakthrough Jun 20 '13 at 12:47


Doesn't require an external tool. As a bonus it preserves the LastWrite time. Other times are not altered.

# Get file as item to access content and file dates
$file = Get-Item "C:\Users\Nixda\Desktop\input.txt" 

# Save write time to temp variable for later use
$oldWriteTime = $file.LastWriteTime 

# Create an empty array of the same size as your file size in bytes
$content = New-Object Byte[] $file.length 

# Fill the array using a System.Random object. Here is the magic
(New-Object Random).NextBytes($content)

# Write the array to the same file with System.IO.File

# Set back old write time
$file.LastWriteTime = $oldWriteTime


enter image description here


enter image description here



bcrypt will work just fine. Build it in cygwin and bring the cygwin dll along on a usb pendrive.

Edit: Or rather trivially obfuscate it by xoring them with a key of your choosing. That would at least preserve filesizes. Theres no need to alter more than 8 bytes, at most a kb, from the start of the files if you have a lot of documents and just want it done quickly. There has been some ransomware that did this a while ago. Im obviously no cryptographer, but it's pretty boring stuff sifting through files deriving the key used to obfuscate them. Or use dd ( from unxutils.sf.net for windows ) thusly: $ dd conv=swab if=infile of=outfile in a loop across your docs. Warning: Using dd like that will make you look silly. The same command will reverse the process.

  • That seems too complicated for such a simple operation, and encrypting the file would slightly alter its size. – user256743 Dec 26 '14 at 4:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.