mirror/ioccc
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

force use of pandoc version >= 3.1.12.2

Browse Source 
The `bin/pandoc-wrapper.sh` tool will verify that the ssytem
has a recent enough version of `pandoc(1)`.

We explain why we insist on `pandoc(1)`. version >= 3.1.12.2
in comments where the $PANDOC_MIN_VERSION is set.

Added `--wrap=preserve` as a default argument to `pandoc(1)`.
While this change will impact every HTML file generated,
we believe this will improve the ability of someone to look
at the generated HTML and correlate with the original markdown.

Changed `bin/pandoc-wrapper.sh` VERSION from "1.4.2 2024-03-17"
to "1.4.3 2024-03-18".

Performed `make www` to achieve all of the above and to generate
HTML using the new  `--wrap=preserve` `pandoc(1)` mode.
This commit is contained in:
Landon Curt Noll committed 2024-03-18 01:26:39 -07:00
1 parent 9eb7a54e9f
commit b0b212acb1
402 files changed
+37061 -55132
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

2020/ferguson2/obfuscation.html
+135 -161
View File
@@ -122,24 +122,21 @@
<h1 id="obfuscation">Obfuscation</h1>
<ul>
<li><p>Strings identifying what it is are encrypted by the Enigma itself
(with its default settings). The strings are: <code>Position</code>,
<code>Setting</code>, <code>Ring</code>, <code>Plugboard pair</code>
<code>Reflector</code>. Together these would be a dead giveaway to
anyone familiar with the Enigma machine and some of them by themselves
would be a dead giveaway too. I can’t even explain how I did this
(although I’m sure at one point I could have) but I do think it’s pretty
cool to have the text encrypted by the program and still be capable of
printing it correctly all without giving anything away.</p></li>
<li><p>Digraphs. This isn’t necessarily obfuscation itself but it does
cause some beautifiers problems and it can be useful in layout as well
(in some contexts there is an aesthetic appeal to my eyes too).</p></li>
<li><p>Compound literal of ints of size 13 that have a variety of
different data (including what was originally two arrays plus some
additional ints).</p></li>
<li><p>Negative pointer offsets. This include calculated offsets into
the huge Y&lt;:19:&gt;&lt;:27:&gt; but it’s not the only example. Here
the compound literal of 13 ints:</p>
<li><p>Strings identifying what it is are encrypted by the Enigma itself (with its
default settings). The strings are: <code>Position</code>, <code>Setting</code>, <code>Ring</code>, <code>Plugboard pair</code>
<code>Reflector</code>. Together these would be a dead giveaway to anyone familiar with the
Enigma machine and some of them by themselves would be a dead giveaway too. I
can’t even explain how I did this (although I’m sure at one point I could have)
but I do think it’s pretty cool to have the text encrypted by the program and
still be capable of printing it correctly all without giving anything away.</p></li>
<li><p>Digraphs. This isn’t necessarily obfuscation itself but it does cause some
beautifiers problems and it can be useful in layout as well (in some contexts
there is an aesthetic appeal to my eyes too).</p></li>
<li><p>Compound literal of ints of size 13 that have a variety of different data
(including what was originally two arrays plus some additional ints).</p></li>
<li><p>Negative pointer offsets. This include calculated offsets into the huge
Y&lt;:19:&gt;&lt;:27:&gt; but it’s not the only example. Here the compound literal of 13
ints:</p>
<pre><code>int *z=(int[13]) { 0 } , *e, *g;</code></pre>
<p>Then in main:</p>
<pre><code>e = z + 10;
@@ -147,12 +144,11 @@ g = e + 1;
for (j=-3; j &lt; 0; ++j)
e&lt;:j:&gt; = j+3;</code></pre>
<p>Which I think is more confusing: when one is iterating an array you
don’t expect to start out with index &lt; 0 but to then compare that
that index &lt; 0 and increment until 0 along with setting the value of
the array to j + 3 is more confusing still. There are at least two other
ways that are much easier to read that could accomplish the same thing.
It continues on:</p>
<p>Which I think is more confusing: when one is iterating an array you don’t
expect to start out with index &lt; 0 but to then compare that that index &lt; 0
and increment until 0 along with setting the value of the array to j + 3 is
more confusing still. There are at least two other ways that are much easier
to read that could accomplish the same thing. It continues on:</p>
<pre><code>/* ... */
e&lt;:i-3:&gt; = (j &lt; 1 ? 1 : (j &gt; 5 ? 5 : j))-1;</code></pre></li>
<li><p>Observe these two functions:</p>
@@ -174,31 +170,29 @@ void Q(void)
w(R[*g],*(e+e&lt;:1:&gt;-6)=q(Y&lt;:8:&gt;,*Y&lt;:7:&gt;),*g);
}
}</code></pre>
<p>First of all: why do I set <code>e[2]</code> to 0 and increment it
for each pass in the loop, but then the condition for the loop is
<code>s[*P]</code>?</p>
<p>Second notice the many references to e[1] (as e[1] and <em>g). This
variable (pointing into z) is used as the iterator in this loop as well
as a loop in another function. Now why do I pass </em>g to the function
w()? To mislead. Originally it was more misleading in that I didn’t
touch the parameter ‘v’ in the function and did a *g = v; at the end of
the function. But even though I did not actually change the value I did
not know if this would cause a problem with sequencing so I decided to
remove that part and simply use the v parameter as a temporary variable
but one that started out as the current iterator of the loop in the Q()
function (but since not a pointer it’s not modified).</p>
<p>Originally I went further than that but due to order of evaluation
being unspecified I changed it to what it is now. Anyway:</p>
<p>You can also see that I use the value of e[1]-3 as the index of S[e]
(so S[e[e[1]-3]]) (I think I said that right; I honestly don’t know now
because there is such major array and offset abuse. The entire prog.c is
riddled with offset abuses.).</p></li>
<li><p>If you observe that above the compound literal <code>z</code> is
of size 13 but I point <code>e</code> to be <code>z + 10</code>. Why?
Twofold: (1) I decided to make use of one of them as a temporary
variable instead of a regular int in the function (so make it global);
and (2) I didn’t want to risk changing all the offsets: thus I just made
that address <code>e[1]</code>. Thus I also have:</p>
<p>First of all: why do I set <code>e[2]</code> to 0 and increment it for each pass in the
loop, but then the condition for the loop is <code>s[*P]</code>?</p>
<p>Second notice the many references to e[1] (as e[1] and <em>g). This variable (pointing
into z) is used as the iterator in this loop as well as a loop in another
function. Now why do I pass </em>g to the function w()? To mislead. Originally
it was more misleading in that I didn’t touch the parameter ‘v’ in the
function and did a *g = v; at the end of the function. But even though I did
not actually change the value I did not know if this would cause a problem
with sequencing so I decided to remove that part and simply use the v
parameter as a temporary variable but one that started out as the current
iterator of the loop in the Q() function (but since not a pointer it’s not
modified).</p>
<p>Originally I went further than that but due to order of evaluation being
unspecified I changed it to what it is now. Anyway:</p>
<p>You can also see that I use the value of e[1]-3 as the index of S[e] (so
S[e[e[1]-3]]) (I think I said that right; I honestly don’t know now because
there is such major array and offset abuse. The entire prog.c is riddled
with offset abuses.).</p></li>
<li><p>If you observe that above the compound literal <code>z</code> is of size 13 but I point
<code>e</code> to be <code>z + 10</code>. Why? Twofold: (1) I decided to make use of one of them as a
temporary variable instead of a regular int in the function (so make it global);
and (2) I didn’t want to risk changing all the offsets: thus I just made that
address <code>e[1]</code>. Thus I also have:</p>
<pre><code>for (*g = 0 ; *g &lt; 10; ++*g)
{
r&lt;:-2:&gt; = Y&lt;:14:&gt;&lt;:*(e+1):&gt;; r&lt;:-3:&gt; = Y&lt;:15:&gt;&lt;:1&lt;:e:&gt;:&gt;;
@@ -207,131 +201,112 @@ if (r&lt;:-3:&gt; &amp;&amp; r&lt;:-2:&gt; == r&lt;:-1:&gt;)
if (r&lt;:-2:&gt; &amp;&amp; r&lt;:-3:&gt; == r&lt;:-1:&gt;)
return r&lt;:-2:&gt;;
}</code></pre>
<p>This <code>e[1]</code> of course is the same as <code>*g</code> as
above and as you can see has multiple dimensions (that is the reference
to Y does) too (and this is also strewn about the code). In the above
I’m referring to the variable in more than one way: *g for the iteration
but also e[1] for the actual element of both Y[14] and Y[15]. I also
happen to use S (via r which points to S + 10) which I use as the two
chars to compare (this is the plugboard function).</p></li>
<li><p>The above function Z() takes a <code>char x</code> but you won’t
notice it being used at all. Why? In fact I call it like so:</p>
<p>This <code>e[1]</code> of course is the same as <code>*g</code> as above and as you can see has
multiple dimensions (that is the reference to Y does) too (and this is also
strewn about the code). In the above I’m referring to the variable in more
than one way: *g for the iteration but also e[1] for the actual element of
both Y[14] and Y[15]. I also happen to use S (via r which points to S + 10)
which I use as the two chars to compare (this is the plugboard function).</p></li>
<li><p>The above function Z() takes a <code>char x</code> but you won’t notice it being used
at all. Why? In fact I call it like so:</p>
<pre><code>k = Z(r&lt;:-1:&gt;=k);</code></pre>
<p>The char is just used as a way to be able to call the function and
assign to the proper variable at the same time: in the function Z I
don’t care about x because it’s the same value as r[-1] (which I do care
about). Why is it attached to S? Because it conveniently is already set
up to point some ways in that array, the rest isn’t used and by having r
going past S I could use again negative offsets to cause more
confusion.</p></li>
<li><p>Although this is clearly already shown in the above there are
other ways I refer to the same variable in more than one way (or in some
cases maybe more correct to say ‘same location’). In the Z() function
for example:</p>
<p>The char is just used as a way to be able to call the function and assign to
the proper variable at the same time: in the function Z I don’t care about x
because it’s the same value as r[-1] (which I do care about). Why is it
attached to S? Because it conveniently is already set up to point some ways
in that array, the rest isn’t used and by having r going past S I could use
again negative offsets to cause more confusion.</p></li>
<li><p>Although this is clearly already shown in the above there are other ways I
refer to the same variable in more than one way (or in some cases maybe more
correct to say ‘same location’). In the Z() function for example:</p>
<pre><code>r&lt;:-2:&gt; = Y&lt;:14:&gt;&lt;:*(e+1):&gt;; r&lt;:-3:&gt; = Y&lt;:15:&gt;&lt;:1&lt;:e:&gt;:&gt;;</code></pre>
<p>I refer to e[1] as both: *(e+1) and 1[e].</p></li>
<li><p>Replacing a number of <code>if ..</code>s with
<code>... &amp;&amp; (...)</code>s (in one case at least it’s nested
further:
<code>f &amp;&amp; (f = 0 &amp;&amp; (a = W(A,a)));</code>).</p></li>
<li><p>Three different char arrays in one: the rotors settings, the
positions and the notches for each rotor. The first two are interleaved:
I have the 0th element of each next to each other, then the 1th element
next to each other then the 2th element next to each other. Then it’s
the notch settings. The first two arrays here require some index
calculations like <code>i+i%3</code> and <code>i+i+1</code> depending on
which ‘array’ is needed. At other points I refer to those elements by
direct index (sort of).</p></li>
<li><p>Another set of char arrays in one: the five rotors as well as the
two reflectors in one <code>char [][27]</code>. This makes for some fun
code like:</p>
<li><p>Replacing a number of <code>if ..</code>s with <code>... &amp;&amp; (...)</code>s (in one case at least
it’s nested further: <code>f &amp;&amp; (f = 0 &amp;&amp; (a = W(A,a)));</code>).</p></li>
<li><p>Three different char arrays in one: the rotors settings, the positions and
the notches for each rotor. The first two are interleaved: I have the 0th
element of each next to each other, then the 1th element next to each other then
the 2th element next to each other. Then it’s the notch settings. The first two
arrays here require some index calculations like <code>i+i%3</code> and <code>i+i+1</code> depending
on which ‘array’ is needed. At other points I refer to those elements by direct
index (sort of).</p></li>
<li><p>Another set of char arrays in one: the five rotors as well as the two
reflectors in one <code>char [][27]</code>. This makes for some fun code like:</p>
<pre><code>(Y&lt;:e&lt;:-10:&gt;+5:&gt;&lt;:k-&#39;A&#39;:&gt;) &amp;&amp; (k = Y&lt;:e&lt;:-10:&gt;+5:&gt;&lt;:k-&#39;A&#39;:&gt;);</code></pre>
<p>(Of course this also removes an if statement by joining with a
&amp;&amp;).</p></li>
<li><p>In fact I decided that the above two arrays in arrays needed to
be merged with the rest of the char arrays so that’s what I have done.
They have different purposes and they’re referred to differently. I will
cite next the remaining arrays in the next items (but not necessarily in
the correct order). Notice that the array I’m talking about is the
massive <code>Y&lt;:19:&gt;&lt;:27:&gt;</code>.</p></li>
<p>(Of course this also removes an if statement by joining with a &amp;&amp;).</p></li>
<li><p>In fact I decided that the above two arrays in arrays needed to be merged
with the rest of the char arrays so that’s what I have done. They have
different purposes and they’re referred to differently. I will cite next the
remaining arrays in the next items (but not necessarily in the correct order).
Notice that the array I’m talking about is the massive <code>Y&lt;:19:&gt;&lt;:27:&gt;</code>.</p></li>
<li><p>The alphabet (this is one string).</p></li>
<li><p>The plugboard (this is two arrays).</p></li>
<li><p>The Enigma ciphered text for prompting for input (five
strings).</p></li>
<li><p>The relevant notches (this is not the same as the five notch
letters!) (this is three chars but each in a different element of the
<code>char Y[19][27]</code> - for why see below).</p></li>
<li><p>I’m not even sure if there are any others due to the way I have
done this; to save iocccsize bytes I have used the first element of
three of the strings when I only did need the first element (since doing
e.g. <code>f[3][2]</code> takes more bytes than <code>*f[3]</code> or
whatever). All in all though there are 18 different strings (in some
cases only the first char is relevant) in <code>char Y[19][27]</code>
with a multitude of different uses. Some of these are as I noted
scrambled. Some default to empty string which might hide that it’s even
there.</p></li>
<li><p>Although minor I have made use of the result of the end of a for
loop in the beginning in the next loop in main(): <code>j</code> will
end up being 0 and I need it at 9 so I do <code>j += 9</code> in the
initialisation of the for loop instead of simply setting it to
9.</p></li>
<li><p>The judges don’t like obfuscation through the C preprocessor.
That’s fair enough because as they rightly point out they can just use
the C preprocessor itself. But although I have quite a few cpp
directives I am not using them for obfuscation but rather to save bytes.
For examples:</p>
<li><p>The Enigma ciphered text for prompting for input (five strings).</p></li>
<li><p>The relevant notches (this is not the same as the five notch letters!) (this
is three chars but each in a different element of the <code>char Y[19][27]</code> - for why
see below).</p></li>
<li><p>I’m not even sure if there are any others due to the way I have done this;
to save iocccsize bytes I have used the first element of three of the strings
when I only did need the first element (since doing e.g. <code>f[3][2]</code> takes more
bytes than <code>*f[3]</code> or whatever). All in all though there are 18 different
strings (in some cases only the first char is relevant) in <code>char Y[19][27]</code> with
a multitude of different uses. Some of these are as I noted scrambled. Some
default to empty string which might hide that it’s even there.</p></li>
<li><p>Although minor I have made use of the result of the end of a for loop in the
beginning in the next loop in main(): <code>j</code> will end up being 0 and I need it at 9
so I do <code>j += 9</code> in the initialisation of the for loop instead of simply setting
it to 9.</p></li>
<li><p>The judges don’t like obfuscation through the C preprocessor. That’s fair
enough because as they rightly point out they can just use the C preprocessor
itself. But although I have quite a few cpp directives I am not using them for
obfuscation but rather to save bytes. For examples:</p>
<pre><code>%:define J(x) do(*x)=getchar(); while((*x)==&#39;\n&#39;)</code></pre>
<p>Is used quite a number of times and although it could be a function
that takes a pointer to an int it was more convenient this way (I
believe it used more bytes but I no longer know that). There are many
others and they all save bytes (or at least most of them do if not all).
There is one in particular I want to bring up though because I think
it’s a curious one and it ties in to another point above:</p>
<p>Is used quite a number of times and although it could be a function that
takes a pointer to an int it was more convenient this way (I believe it used
more bytes but I no longer know that). There are many others and they all
save bytes (or at least most of them do if not all). There is one in
particular I want to bring up though because I think it’s a curious one and
it ties in to another point above:</p>
<pre><code>%:define A(y) *(&amp;Y&lt;:7:&gt;&lt;:1:&gt;+(y))</code></pre>
<p>What is special about this one: Above I noted how I sort of refer
directly to the notch settings (I think it was the notch settings
anyway). Now I could have done say</p>
<p>What is special about this one: Above I noted how I sort of refer directly
to the notch settings (I think it was the notch settings anyway). Now I
could have done say</p>
<pre><code>char a = Y[7][1], b = Y[7][3], c = Y[7][5];</code></pre>
<p>But I felt that doing instead the pointer arithmetic was worth doing.
However it used significantly more bytes even as a macro: 17 if I recall
right. That’s with the macro. If I were to include it three times by
itself it’d be many more. I believe though that when the cpp translates
it it still requires more thought to determine that a is set to Y[7][1],
b to Y[7][3] and c to Y[7][5].</p></li>
right. That’s with the macro. If I were to include it three times by itself
it’d be many more. I believe though that when the cpp translates it it still
requires more thought to determine that a is set to Y[7][1], b to Y[7][3]
and c to Y[7][5].</p></li>
</ul>
<h1 id="obfuscation-wrt-recode.c">Obfuscation wrt recode.c</h1>
<ul>
<li><p>To cause confusion I have used the same names of variables and
functions (well recode.c has more functions and variables) but with
different meanings. For example in recode.c <code>R</code> is a
<code>char R[3]</code> but in prog.c it’s <code>char *R[3]</code>.
Another example is where in prog.c <code>Y</code> is
<code>char Y[19][27]</code> in recode.c it’s <code>char *Y[3]</code>.
Some are use swaps but not necessarily all. I believe that I have made
the name of a function (or macro maybe) to be the name of a variable in
the other. Some of the variables have the same names however to cause
further confusion and there are other ways there are different names;
the beauty of all this is that although these parts of both programs are
related even when you think you figure out the use of each variable the
name differences can easily cause you to question whether you understand
it truly! Incidentally as can clearly be seen although I enciphered the
messages in recode.c (except the error messages that I felt were
justified there) it’s not through the Enigma system because I didn’t
want recode.c to give many hints as to how prog.c works. I don’t believe
deciphering recode.c will explain how my entry works because recode.c
doesn’t use the Enigma algorithm and even the strings are done very
differently (and separated) so that one cannot easily replace the
<code>char</code> variables in recode.c, move them to prog.c, compile
and expect it to work right.</p></li>
<li><p>To cause confusion I have used the same names of variables and functions
(well recode.c has more functions and variables) but with different meanings.
For example in recode.c <code>R</code> is a <code>char R[3]</code> but in prog.c it’s <code>char *R[3]</code>.
Another example is where in prog.c <code>Y</code> is <code>char Y[19][27]</code> in recode.c it’s <code>char *Y[3]</code>. Some are use swaps but not necessarily all. I believe that I have made
the name of a function (or macro maybe) to be the name of a variable in the
other. Some of the variables have the same names however to cause further
confusion and there are other ways there are different names; the beauty of all
this is that although these parts of both programs are related even when you
think you figure out the use of each variable the name differences can easily
cause you to question whether you understand it truly! Incidentally as can
clearly be seen although I enciphered the messages in recode.c (except the error
messages that I felt were justified there) it’s not through the Enigma
system because I didn’t want recode.c to give many hints as to how prog.c works.
I don’t believe deciphering recode.c will explain how my entry works because
recode.c doesn’t use the Enigma algorithm and even the strings are done very
differently (and separated) so that one cannot easily replace the <code>char</code>
variables in recode.c, move them to prog.c, compile and expect it to work right.</p></li>
<li><p>Also what is this about ?</p>
<pre><code> /\
/ This is *not* what you think:
void D(char*x){ /* ... */ }</code></pre>
<p>Is that valid and if so how does it function? Yes it’s valid but I’ll
leave the other part of the question up to the reader to answer. Hint:
you already know how it works (yes, really you do)! Another hint: This
is and is not a misleading comment (conversely this makes this hint both
misleading - and also not).</p></li>
<p>Is that valid and if so how does it function? Yes it’s valid but I’ll leave
the other part of the question up to the reader to answer. Hint: you already
know how it works (yes, really you do)! Another hint: This is and is not a
misleading comment (conversely this makes this hint both misleading - and
also not).</p></li>
</ul>
<table>
<colgroup>
@@ -339,13 +314,12 @@ misleading - and also not).</p></li>
</colgroup>
<tbody>
<tr class="odd">
<td>(c) Copyright 1984-2020, [Leo Broukhis, Simon Cooper, Landon Curt
Noll][judges] - All rights reserved This work is licensed under a
[Creative Commons Attribution-ShareAlike 3.0 Unported License][cc].</td>
<td>(c) Copyright 1984-2020, [Leo Broukhis, Simon Cooper, Landon Curt Noll][judges] - All rights reserved
This work is licensed under a [Creative Commons Attribution-ShareAlike 3.0 Unported License][cc].</td>
</tr>
<tr class="even">
<td>[judges]: https://www.ioccc.org/judges.html [cc]:
http://creativecommons.org/licenses/by-sa/3.0/</td>
<td>[judges]: https://www.ioccc.org/judges.html
[cc]: http://creativecommons.org/licenses/by-sa/3.0/</td>
</tr>
</tbody>
</table>