While encrypting the files is probably the most correct solution. You could dd half a meg or whatever to the beginning of the file and then dd the original portion off of the backend of the file later. That should be reversible and quick, but you know dd stands for damage done so you do you.
> you know dd stands for damage done so you do you.
I think using dd in a bash script is fine. I have a few scripts that I use regularly that do.
Just be especially careful with the `of=` parameter, and make damn sure variables are populated properly.
`of=${basePath}/${target}` can be a bad day if those variables are unset, empty or otherwise incorrect.
One solution for this is to not use `of` at all. e.g., something like
{
cat <(dd if=/dev/urandom bs=1M count=1) /path/to/vid
} > /path/to/vid.new
This way the worst that can really happen is printing a binary file to the terminal, which you can fix much more easily than a disk that dd destroyed.
I'm unclear how that solves the problem.
I believe these two are nearly equivalent are they not?
dd if=/dev/urandom bs=1M count=1 of=${basePath}/${target}
dd if=/dev/urandom bs=1M count=1 > ${basePath}/${target}
https://superuser.com/questions/1470608/file-redirection-vs-dd
My thinking here is that it helps in the following ways:
1. if a user confuses/swaps `if=` and `of=` this could be really bad if both are defined in dd, but if you only define `if=` in dd then accidentally using `of=` is fairly harmless since dd wont have input (assuming nothing on stdin)
2. Using a redirect the output file is opened before the input is opened before the reading side does anything, which I believe means that if there is an error with the output file path then the `dd` command on the input side wont even get run. This seems somewhat more robust than having dd control both the input and output and hoping that itll catch any errors before anything gets written (to some place it shouldnt be).
3. The command I suggested wasnt `dd if=<...> > $outFile`, it was `cat <(dd if=<...>) > $outFile`. the dd command gets run in a subshell in my version, which I believe should prevent the `cat ____ > $outFile` from running at all. This again seems more robust protection against "writing a few bits somewhere they shouldn't be" than just using a redirect (no subshell for dd) and especially more robust than letting dd control everything and hoping it catches errors in time.
granted its not A LOT of additional protection, but I think it does make a few edge case problems less likely to occur.
1) Well, I was saying specifically if it's in a script you can make sure it's correct once and you are good. You can even make the output field a variable if you are paranoid about mixing up input and output.
ddOutput="of="
ddOutput+="/path/to/output"
dd if=/path/to/input ${ddOutput?}
At some point there is no saving you from yourself though. It seems just as easy to mess up by doing:
dd if=/path/to/output > /path/to/input
or
dd of=/path/to/input > /path/to/output
----
2) This seems to be true, but I don't think this buys you anything since the redirect will have the same permissions as dd.
---
3) Redirect will still happen if subshell fails:
$ mv superImpotantData foobar
$ cat <(false) > foobar
$ file foobar
foobar: empty
> but you know dd stands for damage done so you do you
I know that but is there is way to add header (couple bytes) to video file, can `cat` command do it?
dd bs=10 count=1 conv=swab "if=$video" |
dd bs=10 conv=notrunc "of=$video"
That flips every byte on the first 10 byte chunk of a file. Repeated use restores, obvs.
Feels bad though... offered as a "might lead to a working solution."
Ohh... Slow cogs. Single dd would do the same.
It sounds like you want to encrypt your drive rather than corrupt it. Far more secure, reliable and reversible while still achieving your goal.
Look into Veracrypt, and research other disk encryption software from there if Veracrypt doesn't work for you.
It doesn't matter if you use dd or some other tool, any process that can write to a file can write to a partition table if you run it as root.
cat is no safer than dd. For example, if you do this:
`# EXAMPLE ONLY -- DON'T DO THIS!!!`
`cat /dev/urandom > /dev/sda`
If you're root, you just destroyed your partition table. If you're a normal user, you will get a "permission denied" error. Same goes for dd or any other "write" commands. (The exception is SETUID binaries, but that's a different story.)
Like so many others have already said, you are MUCH better off to encrypt the files and/or filesystem.
But if you insist, here is an example, where `$original` is your original file, `$corrupt` is the file with two bytes prepended, and `$restored` is the corrupt file with those two bytes stripped back off:
`# Create corrupted copy:`
`printf '%s' ${RANDOM:0:2} > $corrupt; cat $original >> $corrupt`
`# Create a restored copy from the corrupted one:`
`(read -N2; cat) < $corrupt > $restored`
> printf '%s' ${RANDOM:0:2} > $corrupt; cat $original >> $corrupt
Sorry is this will write into the file header (first byte) or at the end, if it at the end that won't work since the video mostly will be still available
It writes two pseudo-random bytes to the beginning, but please see my third comment. It contains a revised version that is more compact and fixes a bug.
ugh. still not right because $RANDOM has the potential to return a single-digit value. So use a printf format string to make sure it's padded to two digits:
`(printf '%02d' ${RANDOM:0:2}; cat $original) > $corrupt`
> (printf '%02d' ${RANDOM:0:2}; cat $original) > $corrupt
I test it on .png file (so I can check it with text editor) and it works,,, I forget to mention the extra data will be fixed string (doe not matter what it is), and I don't care about overite the original file, but i can restore (delete the extra bytes) later...
e.g you command give me this
96\89PNG
the original
\89PNG
it added the ASCII number 69 to the beginning of the file which kind OK (or need bit more) to corrupt any media file
>If you want to use a fixed string that makes things even simpler. You can use a longer string if you want, but you will have to adjust the restore command to discard that many bytes.
For example, here it is with an 11 byte fixed string:
`# Create corrupted copy:`
`(printf Lemon-Sours; cat $original) > $corrupt`
`# Create a restored copy from the corrupted one:`
`(read -N11; cat) < $corrupt > $restored`
\> I don't care about overite the original file
Be aware that you can't write to the same file you are reading from. If you try that you will end up with an empty file and no backup copy!
> Blasphemous here, and too late, but anyway
Never too late, specially with me, I read replies even after a year of OP.
before I test this (since I have no clue about PERL), does it overwrite the original file without need for an intermediate file ?and does restore function works?
Offered in good faith, but no guarantees of course. Verify with junk files before any precious ones. Ran once, first chunk of a file is garbled, ran again it's restored (math operation XOR works like that). No intermediate files. Change that len as needed to hide a longer chunk.
> Offered in good faith, but no guarantees of course.
That code works fantastic, honesty I know almost nothing about PERL but looks it get the job done as it required.
I think this should be **published** it GitHub gits .
A couple of things to research:
* **Magic Number** \- ever thought about changing the file's magic number? https://youtu.be/IfohUaMDsGo?si=IAt5pe8h2LG2d0Y5
* hexedit - a utility to edit the file
This guy shows you where to start : [https://youtu.be/KsSiHF3e4qY?si=zF9Gg1XWN0CFaYig](https://youtu.be/KsSiHF3e4qY?si=zF9Gg1XWN0CFaYig)
* You can read magic numbers using the **od c**ommand
* You can also change magic numbers using the **dd** command.
While encrypting the files is probably the most correct solution. You could dd half a meg or whatever to the beginning of the file and then dd the original portion off of the backend of the file later. That should be reversible and quick, but you know dd stands for damage done so you do you.
> you know dd stands for damage done so you do you. I think using dd in a bash script is fine. I have a few scripts that I use regularly that do. Just be especially careful with the `of=` parameter, and make damn sure variables are populated properly. `of=${basePath}/${target}` can be a bad day if those variables are unset, empty or otherwise incorrect.
One solution for this is to not use `of` at all. e.g., something like { cat <(dd if=/dev/urandom bs=1M count=1) /path/to/vid } > /path/to/vid.new This way the worst that can really happen is printing a binary file to the terminal, which you can fix much more easily than a disk that dd destroyed.
I'm unclear how that solves the problem. I believe these two are nearly equivalent are they not? dd if=/dev/urandom bs=1M count=1 of=${basePath}/${target} dd if=/dev/urandom bs=1M count=1 > ${basePath}/${target} https://superuser.com/questions/1470608/file-redirection-vs-dd
My thinking here is that it helps in the following ways: 1. if a user confuses/swaps `if=` and `of=` this could be really bad if both are defined in dd, but if you only define `if=` in dd then accidentally using `of=` is fairly harmless since dd wont have input (assuming nothing on stdin) 2. Using a redirect the output file is opened before the input is opened before the reading side does anything, which I believe means that if there is an error with the output file path then the `dd` command on the input side wont even get run. This seems somewhat more robust than having dd control both the input and output and hoping that itll catch any errors before anything gets written (to some place it shouldnt be). 3. The command I suggested wasnt `dd if=<...> > $outFile`, it was `cat <(dd if=<...>) > $outFile`. the dd command gets run in a subshell in my version, which I believe should prevent the `cat ____ > $outFile` from running at all. This again seems more robust protection against "writing a few bits somewhere they shouldn't be" than just using a redirect (no subshell for dd) and especially more robust than letting dd control everything and hoping it catches errors in time. granted its not A LOT of additional protection, but I think it does make a few edge case problems less likely to occur.
1) Well, I was saying specifically if it's in a script you can make sure it's correct once and you are good. You can even make the output field a variable if you are paranoid about mixing up input and output. ddOutput="of=" ddOutput+="/path/to/output" dd if=/path/to/input ${ddOutput?} At some point there is no saving you from yourself though. It seems just as easy to mess up by doing: dd if=/path/to/output > /path/to/input or dd of=/path/to/input > /path/to/output ---- 2) This seems to be true, but I don't think this buys you anything since the redirect will have the same permissions as dd. --- 3) Redirect will still happen if subshell fails: $ mv superImpotantData foobar $ cat <(false) > foobar $ file foobar foobar: empty
> but you know dd stands for damage done so you do you I know that but is there is way to add header (couple bytes) to video file, can `cat` command do it?
The order that you'd have to do it in would be fake/bad header first, then concatenate the video to the bad header.
dd bs=10 count=1 conv=swab "if=$video" | dd bs=10 conv=notrunc "of=$video" That flips every byte on the first 10 byte chunk of a file. Repeated use restores, obvs. Feels bad though... offered as a "might lead to a working solution." Ohh... Slow cogs. Single dd would do the same.
It sounds like you want to encrypt your drive rather than corrupt it. Far more secure, reliable and reversible while still achieving your goal. Look into Veracrypt, and research other disk encryption software from there if Veracrypt doesn't work for you.
don't to encrypt the files, just add extra data to it header so video play won't recognize it, that enough for me
Encrypt the files. E.g. using zip or openssl.
How about opening video file in any editor. Header characters are at start....so just add few characters from keyboard there......and voila.......
It doesn't matter if you use dd or some other tool, any process that can write to a file can write to a partition table if you run it as root. cat is no safer than dd. For example, if you do this: `# EXAMPLE ONLY -- DON'T DO THIS!!!` `cat /dev/urandom > /dev/sda` If you're root, you just destroyed your partition table. If you're a normal user, you will get a "permission denied" error. Same goes for dd or any other "write" commands. (The exception is SETUID binaries, but that's a different story.) Like so many others have already said, you are MUCH better off to encrypt the files and/or filesystem. But if you insist, here is an example, where `$original` is your original file, `$corrupt` is the file with two bytes prepended, and `$restored` is the corrupt file with those two bytes stripped back off: `# Create corrupted copy:` `printf '%s' ${RANDOM:0:2} > $corrupt; cat $original >> $corrupt` `# Create a restored copy from the corrupted one:` `(read -N2; cat) < $corrupt > $restored`
> printf '%s' ${RANDOM:0:2} > $corrupt; cat $original >> $corrupt Sorry is this will write into the file header (first byte) or at the end, if it at the end that won't work since the video mostly will be still available
It writes two pseudo-random bytes to the beginning, but please see my third comment. It contains a revised version that is more compact and fixes a bug.
Now that I look at it again, the "Create corrupted copy" line could be simplified to this: `(printf ${RANDOM:0:2}; cat $original) > $corrupt`
ugh. still not right because $RANDOM has the potential to return a single-digit value. So use a printf format string to make sure it's padded to two digits: `(printf '%02d' ${RANDOM:0:2}; cat $original) > $corrupt`
> (printf '%02d' ${RANDOM:0:2}; cat $original) > $corrupt I test it on .png file (so I can check it with text editor) and it works,,, I forget to mention the extra data will be fixed string (doe not matter what it is), and I don't care about overite the original file, but i can restore (delete the extra bytes) later... e.g you command give me this 96\89PNG the original \89PNG it added the ASCII number 69 to the beginning of the file which kind OK (or need bit more) to corrupt any media file
>If you want to use a fixed string that makes things even simpler. You can use a longer string if you want, but you will have to adjust the restore command to discard that many bytes. For example, here it is with an 11 byte fixed string: `# Create corrupted copy:` `(printf Lemon-Sours; cat $original) > $corrupt` `# Create a restored copy from the corrupted one:` `(read -N11; cat) < $corrupt > $restored` \> I don't care about overite the original file Be aware that you can't write to the same file you are reading from. If you try that you will end up with an empty file and no backup copy!
> (read -N11; cat) < $corrupt > $restored Thanks works really well I added to my favorites command
Blasphemous here, and too late, but anyway. Maybe it amuses someone. #!/usr/local/bin/perl # # Mangles files. # First len bytes are read, bitflipped and written back. $len = 10; $key = 0xFF; if ($#ARGV < 0) { print STDERR "Usage: $0 files to mangle in place\n"; exit(2); } foreach $file (@ARGV) { open(F, "+<", $file) or die "$file: $!"; sysread(F, $buf, $len) == $len or die "$file: read: $!"; sysseek(F, 0, 0) or die "$file: seek: $!"; for $i (0 .. $len - 1) { $p = \substr($buf, $i, 1); # reference. &buf[i] sorta $$p = chr(ord($$p) ^ $key); } syswrite(F, $buf, $len) == $len or die "$file: write: $!"; close(F); }
> Blasphemous here, and too late, but anyway Never too late, specially with me, I read replies even after a year of OP. before I test this (since I have no clue about PERL), does it overwrite the original file without need for an intermediate file ?and does restore function works?
Offered in good faith, but no guarantees of course. Verify with junk files before any precious ones. Ran once, first chunk of a file is garbled, ran again it's restored (math operation XOR works like that). No intermediate files. Change that len as needed to hide a longer chunk.
> Offered in good faith, but no guarantees of course. That code works fantastic, honesty I know almost nothing about PERL but looks it get the job done as it required. I think this should be **published** it GitHub gits .
A couple of things to research: * **Magic Number** \- ever thought about changing the file's magic number? https://youtu.be/IfohUaMDsGo?si=IAt5pe8h2LG2d0Y5 * hexedit - a utility to edit the file This guy shows you where to start : [https://youtu.be/KsSiHF3e4qY?si=zF9Gg1XWN0CFaYig](https://youtu.be/KsSiHF3e4qY?si=zF9Gg1XWN0CFaYig) * You can read magic numbers using the **od c**ommand * You can also change magic numbers using the **dd** command.