This is NOT a file format that corrupts itself. This is a file reader that corrupts files. There's a big difference. Nothing about the format itself causes or requires corruption. A better tagline would be "decayfmt is a social contract enforced by pinky promise".
Basically what you want is a custom PCIe device that can P2P DMA the DRM-encrypted frame data to GPU DRM-protected memory directly, more corrupted each time.
Can still be replayed, but would likely require special hardware to do so.
Might be visually cooler and a gesture at decayed compute history if the decay pixels land as black and white (1 and 0) instead of color.
RBG noise damage does happen digitally for image damage, while hue protected noise damage is more organic -- a more filmish look. Most people prefer hue protected noise (saturation and lightness variance fine). It's likely this would look older and more decayed given our biased association with film grain.
For this, monochrome noise with a target grey level (e.g. 20% grey) would be visually nice, but the 1s and 0s would be even more old timey computer museum decay.
Tie::Hash::Cannabinol is a completely useless demonstration of how to use Tie::StdHash to
pervert the behaviour of Perl hashes. Once a hash has been tied to Tie::Hash::Cannabinol,
there is a 25% chance that it will forget anything that you tell it immediately and a
further 25% chance that it won't be able to retrieve any information you ask it for. Any
information that it does return will be pulled at random from its keys.
Oh, and the return value from exists isn't to be trusted either :)
From what I remember, MS Paint do something similar when you would save the image as a jpeg. It would apply the algorithm each save and the image would degrade a bit each time. It was super fun.
A virus I wrote in the '90s did just that - every time you opened a file, it damaged a small random part of it. My plan was also to randomly change the digits of numbers when printed on paper. I wrote this because a friend of mine managed to steal my source code during my naive XOR encryption. The "encrypted" files had a bunch of zeroes, and he saw my password. My virus worked. First, it damaged his working copy; then he tried to copy the backup, but in doing so, he damaged it, too, even though he claimed his backup diskette was write-protected. The virus didn't spread because I knew how evil it could be - just as evil as MS-DOS, which would run a hidden .COM file without thinking twice. So many fast typists like me were often mistyping "DIR" as "DUR", so I just put my virus in a hidden DUR.COM, copied it into the empty allocated space of COMMAND.COM (less than 200 bytes), and printed out "Bad command or file name". So, the theft was avenged!
P.S. I didn't specify, I didn't have my own computer, only used computers at school and my friend's personal computers, leaving "encrypted" files in case I forgot to bring my diskette. So, after he stole my code and some personal files, her never left me alone on his computer, but he never thought I would infect his computer so easily right in front of his eyes without him realizing it!
A better analogy would be if every time you played the video file, the mechanism hallucinated a little, bringing in your current feelings as input to change the emotional undertones (and possibly characters and events) depicted in the video.
Seems like there is no mechanism to allow non-corrupting reads from authorized processes? Begs the question then of what the point of this is. Pure novelty, or truly something that could be used in practice?
A company I was at had a disk array that would do something like this. It wasn't a documented feature mind you. During writes, it would randomly zero out data within a file. So at least it didn't get progressively worse, but it was a bear to isolate. These were large media files so a quick look at the head/middle/tail could easily miss the problem areas.
Comments
This is NOT a file format that corrupts itself. This is a file reader that corrupts files. There's a big difference. Nothing about the format itself causes or requires corruption. A better tagline would be "decayfmt is a social contract enforced by pinky promise".
Dammit! This renders it completely unusable.
True, but only a little bit each time you read it.
Basically what you want is a custom PCIe device that can P2P DMA the DRM-encrypted frame data to GPU DRM-protected memory directly, more corrupted each time.
Can still be replayed, but would likely require special hardware to do so.
Just package it as "decayfs", a FUSE that corrupts stored data each time files of these formats are read.
I came here for this comment.
"A file format that corrupts itself a little every time you open it" simply isn't possible.
It's almost like the author is ragebaiting with this AI generated non-sense.
this is genius territory
decayfmt guy here, people are pressed by a repo that starts its readme with tung tung tung sahur
A good reminder that satire really is an art.
Author of decayfmt here, it is indeed a pinky promise.
Noticing project name is decayfmt not damagefmt.
Might be visually cooler and a gesture at decayed compute history if the decay pixels land as black and white (1 and 0) instead of color.
RBG noise damage does happen digitally for image damage, while hue protected noise damage is more organic -- a more filmish look. Most people prefer hue protected noise (saturation and lightness variance fine). It's likely this would look older and more decayed given our biased association with film grain.
For this, monochrome noise with a target grey level (e.g. 20% grey) would be visually nice, but the 1s and 0s would be even more old timey computer museum decay.
Reminds me of Tie::Hash::Cannabinol:
[1] https://metacpan.org/pod/Tie::Hash::CannabinolFrom what I remember, MS Paint do something similar when you would save the image as a jpeg. It would apply the algorithm each save and the image would degrade a bit each time. It was super fun.
That happens with all editing programs for lossy formats, but it's on write, not on read.
What's the other side of the contract? Why would a reader oblige to corrupt?
Probably satire. Like: "social contract: you will allow fools to choose your government".
A virus I wrote in the '90s did just that - every time you opened a file, it damaged a small random part of it. My plan was also to randomly change the digits of numbers when printed on paper. I wrote this because a friend of mine managed to steal my source code during my naive XOR encryption. The "encrypted" files had a bunch of zeroes, and he saw my password. My virus worked. First, it damaged his working copy; then he tried to copy the backup, but in doing so, he damaged it, too, even though he claimed his backup diskette was write-protected. The virus didn't spread because I knew how evil it could be - just as evil as MS-DOS, which would run a hidden .COM file without thinking twice. So many fast typists like me were often mistyping "DIR" as "DUR", so I just put my virus in a hidden DUR.COM, copied it into the empty allocated space of COMMAND.COM (less than 200 bytes), and printed out "Bad command or file name". So, the theft was avenged!
P.S. I didn't specify, I didn't have my own computer, only used computers at school and my friend's personal computers, leaving "encrypted" files in case I forgot to bring my diskette. So, after he stole my code and some personal files, her never left me alone on his computer, but he never thought I would infect his computer so easily right in front of his eyes without him realizing it!
Kind of like how human memory works, if I understand correctly.
A better analogy would be if every time you played the video file, the mechanism hallucinated a little, bringing in your current feelings as input to change the emotional undertones (and possibly characters and events) depicted in the video.
Seems like there is no mechanism to allow non-corrupting reads from authorized processes? Begs the question then of what the point of this is. Pure novelty, or truly something that could be used in practice?
decayfmt creator here, its pure novelty.
I initially thought this would be part of a fuzzer.
This sounds like Excel when you open a CSV file.
You might look into (Norbert) Weiner functions.
Should have patented it and licensed it to Snap
I thought something like this should be part of the file system to make it even more laborious to by pass
A company I was at had a disk array that would do something like this. It wasn't a documented feature mind you. During writes, it would randomly zero out data within a file. So at least it didn't get progressively worse, but it was a bear to isolate. These were large media files so a quick look at the head/middle/tail could easily miss the problem areas.
The slop is strong on this one
decayfmt guy here, I was not going to make this without AI eitherway.
Would you please stop inventing more ways to enshittify the world?