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

Small virus catcher (for DOS)

[Fuzzums]

in assembly: RET

All this one byte program does is terminate execution. If it's infected by a virus you'll see soon enough if the size has increased.

ofcourse with todays macroviruses this doesn't work anymore :(

Re:Turbo Pascal

[compwizrd]

Some of the old-time Demo groups (and warez groups) would put very nice VGA demos in 4k as well.

Not bad...

[Captain Pedantic]

But I'd like to see them get a Breakout clone in 1K

No need to be smaller than 512 really...

[Anonymous Coward]

Harddrive sizes being what they are now, the smallest sector size I see is 512 bytes. If the file stored in that sector is smaller than 512, it still takes up 512 bytes. Very intersting article however.

4K Demos

[Wraithlyn]

Some of the 4K demos I've seen written for ASM competitions completely blow my mind... check out this one, it's basically a flythrough of the first level of Descent, with texture mapping, source lighting, animated lava and recharger field, a MIDI soundtrack, etc... all in 4095 bytes!!!

Here is Sanction's home page, it contains a couple more very impressive 4K demos.

What about the Visual Studio .NET compiler?

[Jugalator]

Stand-alone console EXE (Release Build):

#include "stdafx.h"

int _tmain(int argc, _TCHAR* argv[])
{
return 42;
}

Size: 20,992 bytes

To be compared with the non-optimized gcc version at 3,998 bytes. :-)

I wonder how small you can make a Windows EXE..

Re:What about the Visual Studio .NET compiler?

[Jugalator]

Hm... I stripped the code from stdio.h, replaced _TCHAR* with char* so the stdafx.h doesn't really do much at all. Then turned on size optimizations and turned off boundary checks etc in the compiler. Still exactly 20992 bytes. Huh?? Browsed the exe and there's full text messages like "ooh something corrupted the state of this program and it cannot safely continue". Which is actually a great addition by Microsoft, but can't you remove such things? :-)

But I guess the .NET compiler has its lower limits where bloat get called feature, just surprising that it seems to compile at the minimum size by default... Or perhaps it use some kind of silly padding so even if there's less code, the physical size isn't reduced.

Kids don't try this at home :-)

[Antity]

The first few examples are quite noteworthy, but when the author starts to put code inside the ELF header, it gets really ugly..

Saying that these bytes are "only padding anyway for future extensions" doesn't feel that good. :-)

This remembers me of early attempts on AmigaOS to shorten and fasten executables where people could be sure that all available Amigas would only use the lower 24 bits of 32 bit address registers since the machines could only address 24 bits physically. So they put application data into the upper 8 bits of registers. Worked fine.

Then came newer machines which really used the full set of 32 address lines and all those dirty programs crashed without obvious reason..

The author says "if we leave compatibility behind.." but what he's doing is not only leaving inter-OS compatibility behind - what he creates isn't even an ELF executable anymore. It's just something that happens to work with this special Linux version.

So since this isn't even an ELF executable any more, there's no reason not just to write "exit 42" in bash (which would be an amazing 8 bytes in size *g*).

Don't misunderstand me, I really like those hacks. But I myself will never, ever again code something that is prone to break in the future just because I didn't follow standards.

One could say that this is what programming is about. :-) No offence meant.