Smallest Possible ELF Executable?

taviso writes "I recently stumbled across this paper (google cache), where the author investigates the smallest possible ELF executable on linux, some interesting stuff, and well worth a read. The author concludes, 'every single byte in this executable file can be accounted for and justified. How many executables have you created lately that you can say that about?'

Comments

Optimized Executables

[aking137]

I think there are quite a few. It's seen as a challenge, and does have practical uses. Have a look at Toms Rootboot disk - it includes a web server, a telnet server, a telnet client, an nfs client, wget, gzip, bzip2, vi, a whole load of network drivers, and a tonne of other stuff, all compressed down onto one floppy disk. Only I've never quite been able to find the source code for any of it despite spending a small amount of time looking - possibly someone would be able to put me right on that one.

There are also lots of interesting articles on linuxassembly.org.

Andrew

Re:Optimized Executables

[Sparr0]

You are incorrect. The filesystem is stored on the disk in a compressed form, it is decompressed to a RAM drive. Every byte DOES count.

Re:Optimized Executables

[Fastolfe]

Your information is dated. There are smarter filesystems nowadays that can allocate data from more than one file into a single "cluster". ReiserFS is one such filesystem for Linux, but there are surely others.

Bigger is Sometimes Better

[ksw2]

I used to kill myself trying to strip a few lines of code from my programs... in my mind, I was trying to emulate the PDP hackers of the 60s (my heros) by finding the one "Right Thing" for each program.

Soon I realized that smaller programs are not the end-all goal of programming. If a slightly bigger program is easier to understand for the next person who modifies/maintains it, then that is the new "Right Thing" for that application... and I realized the efficient progamming of the PDP days was a biproduct of necessity more than anything else. It's seldom needed with today's blazing hardware capabilities.

This isn't to say that many of today's programs are over-bloated, but just to reinforce the trade-off between small and easy to understand.

Re:Excellent troll!

[DeeKayWon]

Funny. My /bin/ls (Debian unstable) is nearly 60k, yet is dynamically linked, and is even stripped.

% ls -l /bin/ls
-rwxr-xr-x 1 root root 59592 Oct 8 20:17 /bin/ls*

% ldd /bin/ls
librt.so.1 => /lib/librt.so.1 (0x40022000)
libc.so.6 => /lib/libc.so.6 (0x40034000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40147000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

% file /bin/ls
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped

Re:Turbo Pascal

[cvore]

A dos .com file does not have a lower limit. .COM files are without headers, so having a realy tiny .com file is not very hard ;) It sais more about the crap turbo pascal puts in the .com file.. a .com file that returns correctly can just have one byte in it: 0xc3 (RET)

asmutils does a good portion of this

[cgleba]

http://linuxassembly.org/asmutils.html

Check it out, download it and assemble it.
They create the smalles set of binaries for the basic linux tools that I have found and they employ a good portion of the stuff mentioned in this paper.

They make busybox look bloated by comparison.

Another neat trick is to use the ld options "-Wl, gc-sections" when linking a static binary -- it tries to weed out all the unused portions of the libraries it links against.

The last trick I usually use is to link against uClibc or dietlibc rather then glibc. Makes a noticeable difference. RedHat has been working on a program called "newlib" which is supposed to do the same thing as uClibc or dietlibc but better (for embedded stuff).

Re:It doesn't save any disk space

[p3d0]

Consider:

1. If you compress these things onto a floppy, every byte counts.
2. Some filesystems like ReiserFS use tail packing to put multiple files (or file tails) into a single block.

OT: Re:What about the Visual Studio .NET compiler?

[WhaDaYaKnow]

Yeah, look at this example for the printf implementation:

extern "C" int __cdecl printf(const char * format, ...)
{
char szBuff[1024];
int retValue;
DWORD cbWritten;
va_list argptr;

va_start( argptr, format );
retValue = wvsprintf( szBuff, format, argptr );
va_end( argptr );

WriteFile( GetStdHandle(STD_OUTPUT_HANDLE), szBuff, retValue,
&cbWritten, 0 );

return retValue;
}

Gosh, I wonder how come M$ has so many problems with secoority. 1024 bytes on the stack, without overrun checking. Wonderful stuff indeed.

You may say, yeah but how often will you printf more than 1024 bytes? Exactly,- practically never. Which is why this sort of crap is not showing up in testing and DOES show up when people are trying to crack it.