Cody Boone Ferguson
1ac055fa85
In most cases the word was changed to 'obfuscation' as it was about
obfuscation, not deobfuscation. In some cases like 1995/leo since the
file was (in 1995/leo) about a secret switch it was changed to
'secret.md' (and 'secret.html') but there were others like that as well.
One entry had the words 'spoiling the size rule' but this had been
changed to 'deobfuscating the size rule' which was obviously wrong.
In the latter YYYY/README.md files the judges had written after some
entries (brief summaries) '...
...We'll stop spouting spoilers now. Have fun exploring all the
entries!
but that was changed to:
...We'll stop spouting deobfuscation information now. Have fun
exploring all the entries!
which wasn't really about deobfuscation but just a brief summary of what
the entries did.
And in the most problematic case (at least for me :-), 2018/ferguson) I
had put a joke in:
... but it's the only Easter egg I won't spoil
but it was changed to 'won't deobfuscate' which not only is not what it
is but it spoilt the joke.
In some cases the word was changed back to 'SPOILER' (or similar) but in
most cases not. I believe it should be better now. There are some
caveats, however, as below.
Although make find_missing_links is okay I do not remember if this will
catch links that refer to '%%REPO_URL%%' or other pandoc tokens. This
means I might have to go back to some earlier years to verify links are
okay. That should not take that much time I hope.
It might also be that some wording can still be improved some but it is
hoped this will be discovered when checking links and looking over the
manifest (which obviously changed).
158 lines
4.7 KiB
Markdown
158 lines
4.7 KiB
Markdown
## To build:
|
|
|
|
``` <!---sh-->
|
|
make
|
|
```
|
|
|
|
|
|
## To use:
|
|
|
|
``` <!---sh-->
|
|
./prog [PIN] < input.txt > output.c
|
|
```
|
|
|
|
|
|
## Try:
|
|
|
|
``` <!---sh-->
|
|
./try.sh
|
|
```
|
|
|
|
|
|
The author provided the file [cppp.cc](%%REPO_URL%%/2020/yang/cppp.cc) which can preprocess the
|
|
generated output to make them more acceptable to typical compilers. To build:
|
|
|
|
``` <!---sh-->
|
|
make cppp
|
|
```
|
|
|
|
See the author's remarks for more details.
|
|
|
|
|
|
## Judges' remarks:
|
|
|
|
You might think of this entry as code obfuscater with a code.
|
|
If you use the wrong code, you're gonna have a bad time.
|
|
What is compiling this entry about?
|
|
[Having a good .. time](https://southpark.fandom.com/wiki/Asspen/Script)!
|
|
|
|
This winning entry also comes with a [JavaScript time-lapse
|
|
obfuscation](obfuscation.html) that shows how this entry was written.
|
|
|
|
|
|
## Author's remarks:
|
|
|
|
### Synopsis
|
|
|
|
``` <!---sh-->
|
|
echo "Hello world" | ./prog 12345 > encoded.c
|
|
|
|
gcc -DPIN=12345 encoded.c -o ./decoded && ./decoded
|
|
```
|
|
|
|
### Details
|
|
|
|
Mile is a C code generator. Run without arguments for the help message below:
|
|
|
|
```
|
|
usage: [PIN] < input.txt > output.c
|
|
|
|
where [PIN] is an integer in the range of 1..65535
|
|
```
|
|
|
|
When run with an encoding PIN (first command line argument), Mile will
|
|
read bytes from `stdin` and generate C code on `stdout`. Example:
|
|
|
|
``` <!---sh-->
|
|
echo "Hello, world!" | ./prog 56789 > encoded.c
|
|
```
|
|
|
|
This generated code will reproduce the same input bytes on `stdout` when
|
|
executed, if it was compiled with the same encoding PIN.
|
|
|
|
``` <!---sh-->
|
|
gcc -DPIN=56789 encoded.c -o decoded
|
|
```
|
|
|
|
The generated code reconstructs all data at compile time by seeding a
|
|
random number generator with the given PIN to reproduce the input bytes,
|
|
and simply does one `fwrite(3)` call at run time to print those bytes. Not
|
|
specifying a PIN is a compile time error. Specify the wrong PIN and
|
|
output code will still compile, but will likely produce garbage instead of
|
|
the input bytes. If the original input was empty then any PIN works, but
|
|
you might get a compile time warning complaining about empty arrays.
|
|
|
|
Because all data is reconstructed at compile time, expect the compile time
|
|
to be excruciatingly long if you try to encode too much data. Code
|
|
generated by encoding a haiku will probably compile in seconds, a limerick
|
|
may require tens of seconds, a sonnet will take minutes. Give Mile an
|
|
epic poem and you can probably write a faster preprocessor before GCC is
|
|
done (Clang probably already failed long before then).
|
|
|
|
I see that there is a lack of preprocessor abuse in recent years, probably
|
|
because programming in preprocessor is too tedious. Mile is meant to help
|
|
with that by producing C code filled with at least 98% preprocessor lines
|
|
for any input. Now you too can enjoy long compile times with minimal
|
|
effort.
|
|
|
|
|
|
### Features
|
|
|
|
+ Output is randomized using system clock, so if you wait a second between
|
|
runs, you should get a different generated code even for the same
|
|
encoding PIN.
|
|
|
|
+ Customized bytecode encoding of preprocessor boilerplates, mostly for
|
|
compression but should also make reverse engineering more fun.
|
|
|
|
+ CRC32 of the source code is embedded in the source code itself.
|
|
|
|
+ Code layout shaped to resemble "Mile" from "Didn't I Say to Make My
|
|
Abilities Average in the Next Life?!". Mile is known to be able to talk
|
|
to nanomachines directly, which is exactly what programming in
|
|
preprocessor feels like.
|
|
|
|
|
|
### Compatibility
|
|
|
|
Mile has been verified to work in these environments (also, compiles
|
|
without warnings on all of these):
|
|
|
|
+ gcc 9.2.0 on Cygwin
|
|
+ gcc 8.3.0 on Linux
|
|
+ gcc 7.4.0 on Cygwin
|
|
+ gcc 6.1.0 on JSLinux
|
|
+ gcc 5.4.0 on Linux
|
|
+ clang 8.0.1 on Linux
|
|
+ clang 8.0.1 on Cygwin
|
|
+ tcc 0.9.27 on Linux
|
|
+ tcc 0.9.25 on JSLinux
|
|
|
|
Output of Mile is a bit more taxing, and only works with a subset of the
|
|
above:
|
|
|
|
+ gcc: works just fine when using 8.3.0 and below, but may trigger warning
|
|
for large files. gcc 9.2.0 and above may crash with large files.
|
|
+ clang: works fine for small files, fails on large files due to
|
|
[preprocessor bug](https://bugs.llvm.org/show_bug.cgi?id=44480).
|
|
+ tcc: works just fine on Linux. Fails silently on JSLinux.
|
|
|
|
For people eager to encode large files, an extra utility has been packaged
|
|
with this entry to preprocess the generated output to make them more
|
|
acceptable to typical compilers. View the [cppp.cc](%%REPO_URL%%/2020/yang/cppp.cc) source and
|
|
then compile it with a c++ compiler of your choice.
|
|
|
|
<!--
|
|
|
|
Copyright © 1984-2024 by Landon Curt Noll. All Rights Reserved.
|
|
|
|
You are free to share and adapt this file under the terms of this license:
|
|
|
|
Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)
|
|
|
|
For more information, see:
|
|
|
|
https://creativecommons.org/licenses/by-sa/4.0/
|
|
|
|
-->
|