Posthumanity and 'nologin'

 nologin
=========

For some time now, I'm fighting bloatware.

Since I realized, a simple hello world compiles with glibc to 1MB,
statically linked.

When you write your own syscall wrapper, it's not that difficult
to bring that down to about 1kB.

When tweaking that further, by leaving out uneccessary elf headers,
strip symbols, etc., this gets down to about 180 Bytes, 
having a standard elf executable.

So I started more than ten years ago my own micro libc project.

For some years it's usable.

Since I again did stumble about some bloat - 'nologin',
the executable, which just writes "This account is currently not available.",
having 15kB, linked shared - I wrote again one of those tools.

It's below, linux amd64, encoded in base64.
If interested, copy that, pipe it to 'base64 -d > nologin', 
chmod +x.

-----------------------------
f0VMRgIBAQAAAAAAAAAAAAIAPgABAAAAeYAECAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAEAAOAAB
AAAAAAAAAAEAAAAFAAAAAAAAAAAAAAAAgAQIAAAAAACABAgAAAAA3QAAAAAAAADdAAAAAAAAAAAQ
AAAAAAAAwzHtX0iJ5kiJ+EiNVP4I6A8AAABIicdIx8A8AAAADwUx5MO/AQAAAL6zgAQIuikAAACJ
+A8F6dz///9UaGlzIGFjY291bnQgaXMgY3VycmVudGx5IG5vdCBhdmFpbGFibGUuCgA=
-----------------------------

This is compiled with gcc.
It's somehow quite interesting, how much space the elf header needs.
Clearly to see, all those AA's (Byte 0).
Albite I even did strip the stack header, eventually resulting in an executable
stack. Depending on the loader.

I was also somehow buffled, when I did see the linux kernel elf loader
the first time. It is - some interesting piece of code.
Eventually one of the most executed codes of all times.

located in /usr/src/linux/fs/binfmt_elf.c
or within the github kernel repository.

About the nologin binary, I did have some fun with the disassembly.
There still is some bloat left,
the jmp to the syscall to exit.
The call to main. 

So, I'm going to prove, stackless programming removes this bloat.
^^


Appendix: 
For the convenience, nologin, as presented by the hexeditor

-----------------------------
000000000: 7f454c46 02010100 00000000 00000000  .ELF............
000000010: 02003e00 01000000 79800408 00000000  ..>.....y.......
000000020: 40000000 00000000 00000000 00000000  @...............
000000030: 00000000 40003800 01000000 00000000  [email protected].........
000000040: 01000000 05000000 00000000 00000000  ................
000000050: 00800408 00000000 00800408 00000000  ................
000000060: dd000000 00000000 dd000000 00000000  ................
000000070: 00100000 00000000 c331ed5f 4889e648  .........1._H..H
000000080: 89f8488d 54fe08e8 0f000000 4889c748  ..H.T.......H..H
000000090: c7c03c00 00000f05 31e4c3bf 01000000  ..<.....1.......
0000000a0: beb38004 08ba2900 000089f8 0f05e9dc  ......).........
0000000b0: ffffff54 68697320 6163636f 756e7420  ...This account
0000000c0: 69732063 75727265 6e746c79 206e6f74  is currently not
0000000d0: 20617661 696c6162 6c652e0a 00         available...
-----------------------------

So, here is the result of today's experiment.
A stackless 'nologin'.

I's still generic C, compiled with gcc.

00000079  58                pop rax
0000007A  488D54FE08        lea rdx,[rsi+rdi*8+0x8]
0000007F  BF01000000        mov edi,0x1
00000084  BE99800408        mov esi,0x8048099
00000089  BA29000000        mov edx,0x29
0000008E  89F8              mov eax,edi
00000090  0F05              syscall
00000092  B83C000000        mov eax,0x3c
00000097  0F05              syscall

pop rax I leave there, having argc in main 
might be regarded as 'generic', and main stays stackless. 
Leaving the trouble with argv[].
Albite now it seems to me, I need to define the "stack" first.

Eventually it would be more consequent to submit argv as well via registers
to main. By staying with the abi, but changing the main() semantic,
this means having 5 arguments at max.

This ought to be enough for everyone.

------------------------------
f0VMRgIBAQAAAAAAAAAAAAIAPgABAAAAeYAECAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAEAAOAAB
AAAAAAAAAAEAAAAFAAAAAAAAAAAAAAAAgAQIAAAAAACABAgAAAAAwwAAAAAAAADDAAAAAAAAAAAQ
AAAAAAAAw1hIjVT+CL8BAAAAvpmABAi6KQAAAIn4DwW4PAAAAA8FVGhpcyBhY2NvdW50IGlzIGN1
cnJlbnRseSBub3QgYXZhaWxhYmxlLgoA
------------------------------
(195 Bytes)