PPK debuts the tiny programming challenge
kernelistic writes "Looks like the great folks at properkernel.com are running a developer challenge. They're looking for smallest executables that match the posted criteria. The rules look fairly straightforward. Anyone up for some fun?"
Looks like they want a binary similar to the one described in A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux , except it has to print text and not just return 42.
If only I had some spare time to play along at home...
Hang on a sec .. they say they'll accept Linux syscalls being used, but to call them you need to use the 'fastcall' approach, that is, put your arguments in the registers and run an interrupt (int 0x80 in Linux.)
But rule 3 states that you have to use a stack-based approach, no fastcall allowed! Wtf?
Just for comparison's sake, the quick'n'dirty approach:
main()
{
char *msg = "The deep gray mouse runs after the holy yellow cheese.\n";
write(1, msg, 56);
}
produces, stripped, a 3200 byte binary -- too big to qualify by 700 bytes.
-- Alastair
- 3. Uses a stack-based approach (ie. No fastcall binaries!).
has changed to:- 3. Uses a stack-based approach (ie. Preferably no fastcall binaries).
And: - ... as long as the output is a valid ELF image.
has changed to:- as long as the output is a valid x86 ELF image.
Also they added:- Hate bloatware? This is your chance to show it!
for some reason. Probably a slur against Microsoft, knowing what this lot is like.The catch? I did it in 5,038 bytes, including a nifty color icon.
Beat that.
TANSTAAFI: There Ain't No Such Thing As A Free iPod.
At least they've chosen a challenge with practical implications.
Why is this challenge interesting?
Because it's fun to see who can make the smallest excecutable.
Submit a kernel patch that prints the stuff about the mouse on a certain syscall.
ASM
mov eax 0xbaadca11
syscall
ret
8 bytes. I win.
Because it keeps people who would otherwise be writing tiny exploit code to take advantage of buffer overflows otherwise occupied.
May we never see th
Because it's a challenge, of course. Why are you reading the developers section?
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
justin@joker:~/tmp[1]$ cat small.s
./small
:P
; Justin White
; http://properkernel.com/tiny/ entry
%define STDOUT 0
%define SYS_exit 1
%define SYS_write 4
section data
msg db "The deep gray mouse runs after the holy yellow cheese.", 0x0A
msg_size equ $-msg
section text
global _start
_start:
; write
push dword msg_size
push dword msg
push dword STDOUT
mov eax, SYS_write
push eax
int 0x80
; exit
push dword 0
mov eax, SYS_exit
push eax
int 0x80
; end _start
;EOF
justin@joker:~/tmp[0]$ nasm -f elf small.s
justin@joker:~/tmp[0]$ ld -x -s -o small -nostdlib --stats small.o
/usr/libexec/elf/ld: total time in link: 0.006606
/usr/libexec/elf/ld: data size 184328
justin@joker:~/tmp[0]$ ll small
-rwxrwxr-x 1 justin justin 516 Nov 25 03:22 small*
justin@joker:~/tmp[0]$
The deep gray mouse runs after the holy yellow cheese.
justin@joker:~/tmp[0]$
that's using FreeBSD kernel calls.
that's the smallest it'll be without doing ELF header tweaking like in that tiny binary tutorial.
actually, can save like 8 bytes by using just AL and not all of EAX to hold the syscall numbers.
now, if they said, do it without using the kernel, that would have been a challenge
--Justin
Smallest Possible ELF Executable?
The answer was 45 bytes, but probably don't fulfill the criterias set in this challenge.
Beware: In C++, your friends can see your privates!
That sounds about right. You may have the
optimal solution there, if you disallow schemes
which algorithmically compress the output string.
Now that you've done your homework and
applied all the basic published techniques to
shrink the straighforward write of static data down
to it's minimum size, you can start to *think*
*creatively* and work on dynamically allocating the
buffer and generating its contents from code in
fewer than 56 bytes.
-I like my women like I like my tea: green-