From c0e66ab859147da1220ffe94897fe57e433f1cb7 Mon Sep 17 00:00:00 2001 From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com> Date: Sun, 15 Oct 2023 12:12:38 -0700 Subject: [PATCH] Format fix 2014/birken/README.md This involved adding an email address of one of the authors which is also in the respective author/ JSON file. --- 2014/birken/README.md | 123 ++++++++++++++++++++++++------ author/Alexander_Prishchepov.json | 2 +- 2 files changed, 100 insertions(+), 25 deletions(-) diff --git a/2014/birken/README.md b/2014/birken/README.md index 68c105baa..6ef761393 100644 --- a/2014/birken/README.md +++ b/2014/birken/README.md @@ -1,11 +1,12 @@ # Best use of port 1701 - Michael Birken - - - - Alexander Prishchepov - +Michael Birken
+
+
+
+Alexander Prishchepov
+
+
## To build: @@ -24,11 +25,28 @@ make ## Try: ```sh -./prog +./prog < README.md +``` +or maybe: + +```sh +echo "IOCCC 2014!" | ./prog +``` + +Next, try in another terminal, as the above one is running: + +```sh ./prog http://127.0.0.1:1701 ``` +What happens if you specify instead of a regular file something like +`/dev/null` ? + + +But there's more! Try opening in a browser the same address and then see what +happens. This is explained by the authors when explaining their inspiration. + ## Judges' remarks: Port 1701? Well this is not the l2f registered TCP/1701 protocol. @@ -42,11 +60,16 @@ binary content communicated between client and server. So how does this program do it? A trek though the cloak of obfuscation awaits the reader of the source! -## Author's remarks: +## Authors' remarks: ### Abstract -When launched in web server mode, this application appears to deliver nothing more than a static HTML page. But, in actuality, it provides covert file transfer over the Internet. This is demonstrated by starting the application as a client-side downloader. The hidden transmitted data cannot be reconstructed or even detected from the binary content of the traffic between the client and the server. +When launched in web server mode, this application appears to deliver nothing +more than a static HTML page. But, in actuality, it provides covert file +transfer over the Internet. This is demonstrated by starting the application as +a client-side downloader. The hidden transmitted data cannot be reconstructed +or even detected from the binary content of the traffic between the client and +the server. ## To run web server @@ -66,15 +89,18 @@ Try using the program's source code as the secret file: ./prog http://host[:port] ``` -The optional port defaults to 1701. If the web server instance is started on the same box, try: +The optional port defaults to 1701. If the web server instance is started on +the same box, try: ```sh ./prog http://127.0.0.1:1701 ``` -It will incrementally display the contents of the hidden file at a rate of approximately 1 baud. +It will incrementally display the contents of the hidden file at a rate of +approximately 1 baud. -The client-side downloader will automatically terminate if the web server is bounced. +The client-side downloader will automatically terminate if the web server is +bounced. ### HTML content @@ -82,46 +108,95 @@ Plug the URL into a browser to view a static HTML page containing ASCII artwork. ### Exploration -Studying the network traffic will reveal that the HTML content is static and immutable, the HTTP request and response fields do not contain anything remarkable, HTTP status and error codes are not exploited, no unusual or deprecated features of HTTP are used, and while the cookie is based on a timestamp, its value also remains unchanged throughout the session. As mentioned in the abstract, the data is not transmitted within the binary content communicated between the client and the server. A full explanation of the protocol appears below, but feel free to explore before reading further. +Studying the network traffic will reveal that the HTML content is static and +immutable, the HTTP request and response fields do not contain anything +remarkable, HTTP status and error codes are not exploited, no unusual or +deprecated features of HTTP are used, and while the cookie is based on a +timestamp, its value also remains unchanged throughout the session. As +mentioned in the abstract, the data is not transmitted within the binary content +communicated between the client and the server. A full explanation of the +protocol appears below, but feel free to explore before reading further. ### Inspiration -The inspiration for this program comes from _Star Trek VI: The Undiscovered Country_, specifically the final confrontation between the _Enterprise_ and the enhanced prototype Klingon Bird of Prey. The definitive feature of the prototype was its ability to fire while cloaked. But, perhaps even more impressive was its able to keep an open communication channel with the _Enterprise_ throughout the battle, enabling the antagonist Chang to taunt Captain Kirk with Shakespearian quotes while he slowly pelted his ship with torpedoes. Normally, cloaked vessels must maintain silent running to avoid detection. +The inspiration for this program comes from _Star Trek VI: The Undiscovered +Country_, specifically the final confrontation between the _Enterprise_ and the +enhanced prototype Klingon Bird of Prey. The definitive feature of the +prototype was its ability to fire while cloaked. But, perhaps even more +impressive was its ability to keep an open communication channel with the +_Enterprise_ throughout the battle, enabling the antagonist Chang to taunt +Captain Kirk with Shakespearian quotes while he slowly pelted his ship with +torpedoes. Normally, cloaked vessels must maintain silent running to avoid +detection. -The battle is commemorated in the form of ASCII artwork depicting the ships faced head-to-head in the page delivered by the web server. Plus, the program source code is formatted in the shape of a Klingon Bird of Prey. The code itself includes a number of Star Trek references: the registry number of the _Enterprise_ (NCC-1701) is defined as a constant; variable names spell out Cpt. James T. Kirk and Odo (the Deep Space 9 character was played by René Auberjonois who also appeared as Colonel West in _Star Trek VI_); the STARDATE constant makes timing configurable; and, the constant k stands for Khan (in the final engagement in _Star Trek II: The Wrath of Khan_, the damaged _Enterprise_ managed to disable the USS _Reliant_’s shield generator by accessing its prefix code: 16309). +The battle is commemorated in the form of ASCII artwork depicting the ships +faced head-to-head in the page delivered by the web server. Plus, the program +source code is formatted in the shape of a Klingon Bird of Prey. The code +itself includes a number of Star Trek references: the registry number of the +_Enterprise_ (NCC-1701) is defined as a constant; variable names spell out Cpt. +James T. Kirk and Odo (the Deep Space 9 character was played by René Auberjonois +who also appeared as Colonel West in _Star Trek VI_); the `STARDATE` constant +makes timing configurable; and, the constant `k` stands for Khan (in the final +engagement in _Star Trek II: The Wrath of Khan_, the damaged _Enterprise_ +managed to disable the USS _Reliant_’s shield generator by accessing its prefix +code: 16309). ### Secondary size limit -As obligated by a program that employs 23rd century cloaking technology, when the source is fed as input to IOCCC size tool version 2014-09-23-v19, and the -i command line option is used, the value printed is 0. +As obligated by a program that employs 23rd century cloaking technology, when +the source is fed as input to IOCCC size tool version 2014-09-23-v19, and the +`-i` command line option is used, the value printed is 0. ### Transmission protocol revealed -The client-side downloader relies on the response time of the web server rather than the binary content of the response. The server transmits 1 nibble at a time by counting to the nibble value via a sequence of rapid responses terminated by a long response. For instance, the value 5 would be transmitted by making a series of requests that result in 5 near instantaneous responses followed by a half-second delayed response. The long delay is skipped in the case of 15, the maximal nibble value. With the aid of an ASCII table, it is actually possible to read the nibbles by repeatedly pressing the refresh button within a browser and observing the page refresh delay. +The client-side downloader relies on the response time of the web server rather +than the binary content of the response. The server transmits 1 nibble at a +time by counting to the nibble value via a sequence of rapid responses +terminated by a long response. For instance, the value 5 would be transmitted +by making a series of requests that result in 5 near instantaneous responses +followed by a half-second delayed response. The long delay is skipped in the +case of 15, the maximal nibble value. With the aid of an ASCII table, it is +actually possible to read the nibbles by repeatedly pressing the refresh button +within a browser and observing the page refresh delay. -Nibble Count Coding (file transfer protocol NCC-1701) is faster than transmitting each individual bit as a short or long delay because it sends each byte with 2 long delays whereas communicating individual bits requires 8 long delays in the worst case scenario. In fact, Nibble Count Coding is faster than applying Huffman Coding since that is designed to produce compact codes under the assumption that the bit value does not affect transmission time. +Nibble Count Coding (file transfer protocol NCC-1701) is faster than +transmitting each individual bit as a short or long delay because it sends each +byte with 2 long delays whereas communicating individual bits requires 8 long +delays in the worst case scenario. In fact, Nibble Count Coding is faster than +applying Huffman Coding since that is designed to produce compact codes under +the assumption that the bit value does not affect transmission time. -The server relies on the cookie to identify each client uniquely, enabling it to transfer the sequence independently to each client. +The server relies on the cookie to identify each client uniquely, enabling it to +transfer the sequence independently to each client. ### Configuration -As with all network communication, accurate transmission of data relies on the nature of hardware revealed through statistics and timeouts set accordingly. The long delay is arbitrarily set to 0.5 seconds. This is microsecond tunable via the STARDATE constant defined at the top of the source code. Increase the value in the event of transmission errors. Decrease the value to download faster and less reliably. +As with all network communication, accurate transmission of data relies on the +nature of hardware revealed through statistics and timeouts set accordingly. +The long delay is arbitrarily set to `0.5` seconds. This is microsecond tunable +via the `STARDATE` constant defined at the top of the source code. Increase the +value in the event of transmission errors. Decrease the value to download +faster and less reliably. The NCC constant is the web server port number. ### Obfuscations * The ASCII artwork is compressed using run-length encoding. -* One long string stores a series of strings concatenated together and referenced via pointers. +* One long string stores a series of strings concatenated together and +referenced via pointers. * The long string is shift encrypted. * Short and meaningless identifiers are used throughout. * Reversed array indexing was applied immoderately. * Minus is used in place of not-equals. -* O and l were selected for their resemblance to 0 and 1 respectively. -* Standard constants and ASCII characters were replaced with their respective numerical values. +* `O` and `l` were selected for their resemblance to `0` and `1` respectively. +* Standard constants and ASCII characters were replaced with their respective +numerical values. ### Compiler warnings -For space considerations, the following include statements were dropped resulting in compiler warnings: +For space considerations, the following include statements were dropped +resulting in compiler warnings: ```c #include diff --git a/author/Alexander_Prishchepov.json b/author/Alexander_Prishchepov.json index d07f387d9..a75f2fc47 100644 --- a/author/Alexander_Prishchepov.json +++ b/author/Alexander_Prishchepov.json @@ -6,7 +6,7 @@ "sort_word" : "prishchepov", "location_code" : "US", "location_name" : "United States of America", - "email" : "student.00x@gmail.com", + "email" : "alepov-github@yahoo.com", "url" : "https://github.com/sans17/", "alt_url" : null, "deprecated_twitter_handle" : null,