Cody Boone Ferguson
de8ee5f41a
This is a large update that modifies every .entry.json file and fixes
many others. The changes of every .entry.json file are as follows:
- change 'entry source' to 'entry source code' [0]
- change 'original source' to 'original source code' [0]
- change 'directory path from top directory' to 'directory path from top
level directory'
[0] This is for consistency purposes. Other options were pondered but as
the index.html files refer to 'Alternate code' this was the simplest way
to go about it and it also feels more natural. A question was whether to
have 'entry code' and 'original entry code' or to have the word 'source'
added to it but I decided upon including the word 'source'. Another
question has occurred to me is whether or not 'original source code'
should instead be 'original entry source code' but that can be decided
upon later as that occurred to me after much of the files were already
rebuilt. The consistency that this commit has made is for the README.md
sections and in particular 'Alternate code'. One might wonder if that
should be changed to 'Alternate source code' as now the manifest
includes 'source' in the 'entry code' and 'original code' but the
manifest itself is what was actually updated and having 'source' feels
more natural for submitted files. After all not all entries have
alternate code. These questions can be decided on when looking at the
index.html files that have been rebuilt.
Changed 'alt code' to 'alternate code' where this was not already done
(in the manifest). It is questionable whether this should be done in
markdown files or not (in the README.md files section it already is done
but not necessarily in other places).
Many files had incorrect descriptions that have been checked.
Renamed 2020/endoh2/spoiler/spoiler.{md,html} to index.{md,html} so one
can go to just 2020/endoh2/spoiler and see the web page. Although the
manifest of 2 020/endoh2/index.html will link to it and that's probably
how most people will notice it it seems useful especially as the web
page links to the different files in spoiler/ or at least refers to
them, giving a description (kind of like the manifest in
2020/endoh2/index.html).
Due to the above changes all the entries had their index.html files
regenerated too.
There were likely other changes and fixes as well.
What has NOT been done is a check over all items, typos or otherwise,
though some typos have been fixed. Nonetheless this commit goes a long
way to resolving issue #1933.
Updated thanks file both with a missing <div> id and added a manifest
improvements section as the manifest is quite important.
To build:
make
Bugs and (Mis)features:
The current status of this entry is:
STATUS: INABIAF - please **DO NOT** fix
For more detailed information see 2004/sds in bugs.html.
To use:
./sds
Try:
./try.sh
Judges' remarks:
Why not use the program to hide another program in the program? It must have seemed reasonable at the time.
The ability to hide a message in plain text is quite charming, really. We must admit to a bit of uncertainty about where you'd find such messages, or how useful they'd be. Or, of course, whether all those horribly badly formatted emails spammers send might contain secret messages. Annoyingly, it's a little too obvious that SOMETHING has been done to a message for us to hide one in the remarks. :)
Author's remarks:
Steganography is the term for the family of techniques used for hiding information within other information. Today, it has many real world uses, particularly for digital watermarking.
This program uses a steganographic technique to hide information in any text file. The specific technique used is aimed at writers of obfuscated programs for the IOCCC, as the hidden information is encoded in the whitespace in the source file. As we know, there are up to an additional 2048 characters of whitespace available to entrants to the IOCCC, so it turns out that this is an ideal place to hide things.
The program as provided is the steganographic decoder. Rather than provide a separate encoding program, you should not be surprised to learn that I opted to steganographically hide the encoder inside the decoder.
Try it out. Compile the program, then type
./sds < sds.c
You should see the encoder program displayed. Now save it, like:
./sds < sds.c > encoder.c
Then compile encoder.c. You now have the complete system ready.
The encoder expects to get a filename as an argument. This filename is the name of the file containing the information to be hidden. It expects the file in which to hide the information to be on the standard input, and will output the results on the standard output.
You can use it like this (assuming you have a file called remarks):
echo 'Hello, World!' > message
./encoder message < remarks > remarks_msg
Then to decode:
./sds < remarks_msg
Hello, World!
C programs are mostly unaffected by adding steganographic content, but it is possible in certain circumstances for whitespace to be changed inside strings where it should be left alone. Plain text files are good candidates for hiding information in, but the added spacing may render the text somewhat difficult to read.
Obfuscation
This program is obfuscated in a number of ways:
- The code is all but impossible to read due to the spacing.
- The algorithm is well hidden in the code due to copious red-herrings.
- The long expressions cause indentation tools to give poor results.
- And good old fashioned ternary operators are the icing on the cake.
Compiling the program
The program (and the encoder program) should compile on any reasonable compiler. In particular, they are known to compile under GNU C.