busybox fork, micro self-extracting payload, micro qemu

[Roberto A. Foglietta]

Hi all,

I have used TinyCore in the past also in company/consultant works (for USB bootable) like these project:

- https://github.com/robang74/tinycore-editor/tree/main/busybox/patches

These patches applied to the 1.34 allows to do complex scripting advanced debug because I coded bash like trap and signal handling.

About busybox itself, I created a fork which is 135+ commits haed and the branch presented is my cherrypicking integration:

- https://github.com/robang74/busybox (branch uchaosys)

Which I use in this 2MB linux kernel + rootfs tiny system (boots in 0.1s with 32MB of RAM and with 64MB does qemu-in-qemu) with a reduced footprint 3MB (roms included) qemu q35, kvm-accel, tce but only virtio-hw compiled in:

- https://github.com/robang74/uchaosys

So, how did I managed to shrink a 33MB dynamic linked binary into a 3MB static linked portable app? Cutting everything is obsolete, out of scope and not useful in the most general case (e.g. we love virtio HW emulation because tends to be passtrough as much as possible and do not bother us with insane proprietary bloatware drivers/firmwares because we already have on the bare-metal installation).

- https://github.com/robang74/uchaosys/tree/v074/qemu

However, cutting stuff brought to 7.5MB the next step as been accomplished creating a 512-byes (a single `dd` block) payload in Assembler which is able to read after itself take the gzip attached, send to zcat (or equivalent) and run the extracted ELF (or script) on the fly in RAM only

- https://github.com/robang74/uzpexec

This tool is also very powerful / useful when it comes to run stuff from wget which arrived gzipped (or any other supported compression format that can be decompressed on STDOUT, like xzcat).

I am aware that TinyCore package system (like every distro) relies on compressed packages and smart compression tools skips to compress files that already has been compressed. Therefore there is no an immediate advantage using uzpack (conversion to compressed executable) in general.

Instead, when it comes to use single file binary like qemu or PractRand RNG_test, it becomes quite interesting because break down the barrier/separation between installation & run, and allows the idea that everything that can access by wget, can be put in run on the fly and only RAM (scary but also dawn useful).

I hope this helps, R-

[nick65go]

... accomplished creating a 512-byes (a single `dd` block) payload in Assembler which is able to read after itself take the gzip attached, send to zcat (or equivalent) and run the extracted ELF (or script) on the fly in RAM only

This tool is also very powerful / useful when it comes to run stuff from wget which arrived gzipped (or any other supported compression format that can be decompressed on STDOUT, like xzcat).

Nice achievement! your 512B header in Assembler, which can use zcat or xzcat from busybox.
I think is similar with its big brother UPX, which decompress in place and knows bzip2, lzma/xz, zlib, zstd.
https://github.com/upx/upx/tree/devel/src/compress

[Roberto A. Foglietta]

... accomplished creating a 512-byes (a single `dd` block) payload in Assembler which is able to read after itself take the gzip attached, send to zcat (or equivalent) and run the extracted ELF (or script) on the fly in RAM only

This tool is also very powerful / useful when it comes to run stuff from wget which arrived gzipped (or any other supported compression format that can be decompressed on STDOUT, like xzcat).

Nice achievement! your 512B header in Assembler, which can use zcat or xzcat from busybox.
I think is similar with its big brother UPX, which decompress in place and knows bzip2, lzma/xz, zlib, zstd.
https://github.com/upx/upx/tree/devel/src/compress

Thanks. If you think they are the same, try to do a comparison.

Spoiler, they aren't the same: by design, by audience, by roles.

However, you have a point here because people see UPX in uzpexec, and it makes sense becaause also uzpexec do something similar.

[Roberto A. Foglietta]

I think is similar with its big brother UPX

 I confirm that they are two completely different things:

- https://github.com/robang74/uzpexec/blob/devel/README.md#upx-what

By the way, on the devel branch I manage to reduce the size to 489 bytes (file size is always 512B, a single `dd` block) which it means that compared with the released version I still have 23 bytes free to do other operations (or store more static data in BSS fields). Seems a little, but in Assembler is something useful having 23B of grace margin.

[nick65go]

yes, it is a powerful "tool", dangerous (I would say) in the wrong hands
<rant> Assembler language was my first attraction as a young wanna-be-hacker for windows apps. Black magic art finishing with just changing a 0x75 in a 0x74 (jump in a not-jump) after IDA (interactive de-assembler) shows the flow-logic. Few years ago, KolibriOS got traction, but unfortunately Russian developers ... are not trusted by Europe today). </rant>

[Roberto A. Foglietta]

yes, it is a powerful "tool", dangerous (I would say) in the wrong hands
<rant> Assembler language was my first attraction as a young wanna-be-hacker for windows apps. Black magic art finishing with just changing a 0x75 in a 0x74 (jump in a not-jump) after IDA (interactive de-assembler) shows the flow-logic. Few years ago, KolibriOS got traction, but unfortunately Russian developers ... are not trusted by Europe today). </rant>

Release v0.87 contains a standalone uzpack ELF32 binary to convert others apps.

- https://github.com/robang74/uzpexec/releases/

Security is a matter of perception, currently more a bureocratics market rather than a serious research and development field, at least in commercial terms because universities can be on a different trail but usually follows the market trends.

About the risk of a powerful tool, the correct framining is: memfs_create() exists in Linux since 2014, integrated in glibc in 2018, and everything else is well known stuff usually under the unofficial umbrella of 'teenyelf' technologies.

Combining these two points the emergent is a brutal reality: someone who doesn't belong to the credited system institutions decided to surface from the darkweb (even if I never been there) technincs that are usually used to forge virus and malware into a github "better to know", easy to use, project. This destabilises a lot of people who were used to live on prehistoric narratives.

Everything that I created in the last years which can be seen as innovative (uchaosys, uzpexec) rely on well-known facts that in their first practical implementation go back between 10 and 20 years. In information technology such a timeframe is comparable with the UNIX epoch: the beginning of the system time, letterarly.

Finally, someone would wonder about the ASM header about AI's role. It is very simple: I learn from them how to develop in Assembler, in a week.

Best regards, R-