Files
ioccc/1984/mullender
Landon Curt Noll 2ba12ecc3c restore *.orig.c to each entry
Under each yyyy/dir there is a file of the form '*.orig.c'
containing the original source code, or as close as we can
get to the original source code.
2023-07-06 21:49:38 -07:00
..
2023-05-13 11:45:33 +10:00
2020-12-30 16:57:03 -08:00

Grand Prize

Sjoerd Mullender
https://github.com/sjoerdmullender

Robbert van Renesse

To build:

make all

To run:

./mullender

NOTE: If your machine is not a VAX-11 or PDP-11, this program will not execute correctly. In later years, machine dependent code was discouraged.

Alternate code:

Cody Boone Ferguson added the alternative code which lets you run this on other systems. He notes though that this was only a slight fix and enhancement to the change in the faq. Thank you Cody for your assistance!

To build:

make alt

To run:

./mullender.alt [microseconds]

The default microseconds is 10000. This feature is so you can experiment with different speeds in between writes. It can be useful if your CPU is too slow or too fast.

BTW: is there such a thing as too fast a CPU ? :-) Actually yes for certain code which is probably not as uncommon as you think :-).

Note that it is an int and it uses atoi() which does NOT check for overflow! In fact it's argc itself.

Try:

./mullender.alt

./mullender.alt 5000

./mullender.alt 500

./mullender.alt 20000

./mullender.alt 100000

What happens if you hit enter after it writes a line of output?

Judges' remarks:

Without question, this C program is the one of the most obfuscated C program that has ever been received! Like all great contest entries, they result in a change of rules for the following year. To prevent a flood of similar programs, we requested that programs be non machine specific.

This program was selected for the 1987 t-shirt collection.

The C startup routine (via crt0.o) transfers control to a location named main. In this case, main just happens to be in the data area. The array of shorts, which has been further obfuscated by use of different data types, just happens to form a meaningful set of PDP-11 and Vax instructions. The first word is a PDP-11 branch instruction that branches to the rest of the PDP code. On the Vax main is called with the calls instruction which uses the first word of the subroutine as a mask of registers to be saved. So on the Vax the first word can be anything. The real Vax code starts with the second word. This small program makes direct calls to the write() Unix system call to produce a message on the screen. Can you guess what is printed? We knew you couldn't! :-)

BTW: this remains my (Landon Curt Noll's) all time favorite entries!

Cody found the remarks from Sjoerd Mullender and added the program that was used by the authors to generate the array that he referred to. Because a.out.h is not available in all systems (like macOS) and more importantly because he wanted it to be as close to as the original as possible he used a copy of https://raw.githubusercontent.com/dspinellis/unix-history-repo/Research-Release/usr/include/a.out.h in the fabulous Unix History Repo.

This tool can be built by running:

make gentab

Cody notes that it does not appear to work in modern systems (unbalanced braces) or something else is wrong but given that this was done a long time ago on a now archaic system maybe that is why. He also noted that if the shorts are not changed to just int it prints out a lot of negative numbers but since mullender.c has a negative number he kept it as is.

Thank you Cody!

Author's remarks:

These remarks, found at https://lainsystems.com/posts/exploring-mullender-dot-c/, were provided by Sjoerd Mullender years later. We thank the author of the article for the quote! For a more detailed analysis, taken from the Obfuscated C and Other Mysteries, see below. We hope that this is okay with the author of the book. Considering that the analysis is entirely the authors' comments we don't think this will be a problem. Unfortunately the excerpt was PDF and it did not copy paste well. Cody Boone Ferguson had to go back and forth to type so it's possible he made a typo though he also fixed some typos found in the extract. As for the other comments:

I have never known a lot about the VAX assembly, so we used the C compiler to create the VAX code. We didn't write it ourselves from scratch as we did with the PDP code. This is the reason why the VAX code is more complex, including the extra data after the PDP code.

Robbert and I were students at the VU (Free University in Amsterdam) at the time (mathematics with CS as our major since there was no CS curriculum when we started). We had an assignment to create a pair of programs for the computer networks course. The programs were supposed to send data reliably from one program to the other over an unreliable channel. This channel was simulated with a pair of pipes.

We decided for fun to create an obfuscated set of programs, only for the PDP, to do this, but circumventing the channel. (I.e. cheating, hence the needed obfuscation.) Our programs worked and we handed them in.

Of course, the teacher had a good laugh and then rejected our submission. (We knew him well, so we could get away with this.)

Then the IOCCC came along. I don’t remember how we heard about it, but at the time there was a world-wide messaging network Usenet where we read a bunch of newsgroups. I’m sure it was announced there and we saw it.

Since we had just recently created these obfuscated programs we decided we could use the same technique for an obfuscated C program. We upped the ante a bit by making it “portable”.

To add to the obfuscation, we used different formats for the integers in the array, some in decimal, some in octal, some in hexadecimal, and when the value would fit, some as an ASCII character.

The rest is history.

Since this was the first contest, we hadn't seen any old entries, nor had any of the other contestants. Of course we knew about #define and tricks you could do with that, but we didn't need that for this program. In fact, we made it as “standard” as possible. At the time there was this program called cb for C beautifier which would re-indent your program to make the layout look better. Our program is idempotent under cb.

More detailed analysis

When this program is compiled, the compiler places the array somewhere in memory, just like it places any compiled code somewhere in memory. Usually, the C startup code (crt0.o) calls a routine named main. The loader fills in the address in the startup code, but, at least on the old systems where this program ran, it doesn't know that the main in this program isn't code but data!

When the program is run, the C startup code transfers control to the location main. The contents of the array just happen to be machine instructions for both a PDP-11 and a VAX.

On the VAX, the routine main is called with the calls instruction. This instruction uses the first (2-byte) word of the called routine as a mask of registers that are to be saved on the stack. In other words, on the VAX the first word can be anything. On the PDP, the first word is a branch instruction that branches over the VAX code. The PDP and VAX codes are thus completely separate.

The PDP and VAX codes implement the same algorithm:

    for (;;) {
	write(1, "  :-)\b\b\b\b", 9);
	delay();
    }

The result is that the symbols :-) move over the screen. delay is implemented differently on the PDP, where we used a nonexistent system call (sys 55), and on the VAX where we used a delay loop.

My co-author, Robbert, and I had earlier written a similar program for an assignment on the PDP-11. Along came the first Obfuscated C Code Contest, and we decided that we should write a program like this, but make it run on two different architectures.

We didn't think long about what the program should do, so it does something very simple.

We started with writing the PDP code in assembler. We both knew PDP-11 assembler, so that was no problem. The assembler code we came up with is as follows:

pdp:
    mov pc,r4
    tst -(r4)
    sub $9, r4
    mov r4,0f
    mov $1, r0
    sys 4; 0:0; 9
    mov $1000, r2
1:
    sys 55
    sob r2,1b
    br pdp

This is not the code we originally wrote, but it is the code that we ultimately used in the program. The string to be printed is shared by the VAX and the PDP code and is located between the two sections.

First, the program deals with figuring out the address of the string. Then the program counter is saved in a scratch register. Since the program counter points at the second instruction, we subtract 2 from the scratch register in the second instruction. Then we subtract the length of the string and store the result in the location with label 0. This has to do with the calling sequence of system calls on the PDP. Following the sys instruction is the system call number (4 for write), the address of the buffer (pointed to by label 0), and the length of the buffer (9). The file descriptor is in register r0. The rest of the code implements a delay loop. In each iteration, a non-existing system call (55) slows things down.

We assembled this program and extracted the machine code from the resulting object file. We used this code in the VAX part. Since neither of us was fluent in VAX assembly, we wrote the VAX code in C and massaged the compiler output. The VAX assembly program that we came up with is as follows:

vax: .word 0400 + (pdp - vax) / 2 - 1
1:
    pushl $9
    pushal str
    pushl $1
    calls $3, write
    cvtwl $32767, r2

2:
    decl r2
    jneq 2b
    jbr 1b

write: .word 0
    chmk $4
    ret

str: .ascii " :-)\b\b\b\b"

pdp: .word 4548, 3044, 58820, 9, 4407, 6, 5568, 1, 35076, 0, 9, 5570, 512, 35117, 32386, 496

The first word (after the label vax) is the PDP branch instruction. PDP branch instructions are octal 400+ the distance divided by 2. The string that both the PDP and VAX programs use is after the str label, and the PDP code is after the pap label.

On the VAX, the program pushes 9 (the length of the string), the address of the string and 1 (the file descriptor) on the stack and calls write. Since we didn't know the exact calling sequence for system calls, we just copied the source for the write system call stub into our program. After write finishes, the program executes a delay loop, after which it jumps back to the start of the program.

We assembled this program, and extracted the machine code from the object file. After this we only had to convert the machine code to ASCII and write a little bit of C to glue everything together. We wanted to use different formats for each constant in the resulting array, and we wanted to choose the format randomly. So we wrote a program to choose an appropriate format at random. The program we wrote for that follows. This program actually also extracted the machine code from the object file.

#include <stdio.h>
#include <a.out.h>

main(argc, argv) char **argv;
{
    register FILE *fp;
    register short pos = 0, c, n;
    register char *fmt;
    if (argc != 2) {
	fprintf (stderr, "Usage: %s file\n", argv[0]);
	exit (1);
    }

    if ((fp = fopen(argv[1], "r")) == NULL) {
	fprintf(stderr, "%s: can't open %s\n", argv[0], argv[1]);
	exit(2);
    }

    fseek (fp, (long) sizeof (struct exec), 0);
    printf("/* portable between VAX and PDP11 */\n\n");
    printf ("short main[] = {\n");
    for (;;) {
	if (pos == 0)
	    printf("\t");

	c=getc(fp) & 0377;
	if (feof(fp)) break;
	n = getc(fp) << 8|c;

	switch (rand() % 5) {
	    case 0:
	    case 1:
		fmt = "%d"; break;
	    case 2:
		fmt = "%u"; break;
	    case 3:
		fmt = "0%o"; break;
	    case 4:
		fmt = "0x%x"; break;
	}

	if (32 <= n && n < 127 && (rand() % 4)) fmt = "'%c'";
	printf(n < 8 ? "%d" : fmt, n);
	printf(",");
	if (pos++ == 8) {
	    printf("\n");
	    pos = 0;
	}
	else printf(" ");

	printf("};\n");
    }
}

As can be seen, there is a slight preference for decimal, and also a character format is sometimes used, but only if the data is a printable ASCII character.

When we ran this program, we were almost completely satisfied with the result. The only problem we had was that the program had chosen an octal representation for the first word. Since everybody knows what a PDP-11 branch instruction looks like (everyone knows that the traditional magic word for an executable, 0407, is a PDP-11 branch), we changed that to decimal. After checking the size of the resulting program we saw that it was one byte too long. The limit was 512 bytes, and our program was 513 bytes. So we changed the word and in the comment to &&.

This file is Copyright (c) 2023 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/