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-

[nick65go]

...This destabilises a lot of people who were used to live on prehistoric narratives.

I am like a "prehistoric"/dinosaurs but not yet destabilized. Once again: congratulations for your achievements and especially for SHARING them. Some nudges like those should not be lost in the big noise.
And if you felt that my comments were against you then please accept my sincerely apologies.

[Roberto A. Foglietta]

...This destabilises a lot of people who were used to live on prehistoric narratives.

And if you felt that my comments were against you then please accept my sincerely apologies.

My humor tends to be sarcastic, not necessarly it means that I see antagonists everywhere.

- https://github.com/robang74/uzpexec#quick-arm64-view

I think that it is owrth to tell you that python support and 512-byte ARM64 are already available. Useless to say that because the great sucessful adoption of python and about the dominance of ARM64 on edge/mobile devices, the uzpexed v0.95 and the current HEAD on master branch is the most impactful release, so far (citing Homer Simpson)

About "sharing", pythong is valuable because universally adopted not because deposited and secured in a bank vault. This explains pretty well because I adopted the MIT+1 licensing terms: MIT the source and MIT the binary, because disassembling the binary the source are 1:1 retrieved back, label name apart. So, I leveraged the uzpexec extreme nature to extend the MIT licensing terms to the binary and spread the original github link/author.

Adoption is the key, sharing is the mean. ;-)

[nick65go]

I may have one idea for your stub.
In my opinion the main use of your program is that decompress in RAM (an ELF64, a sh-script etc). But for big RAM should not matter: someone could mount a TempFS -- hm, needs root rights -- on a folder and decompress there (aka in RAM, not touch the HDD) with the same useful busbox-applets (zcat, guzip etc). Ex: 10MB UPZ will expand in RAM as (lets say) 20 MB. so you need 30 MB free RAM before run the original gzipp-ed program.
When the RAM is low, then one possible/future option/advantage could be decompress + replace in place, overriding the already used chunk of what was executed. (technique from viruses). For sh / python script works OK. for ELF they need to be modular designed from scratch (not applicable to TC compiled tcz as now).

PS: Any program could be build in small pieces, each chunk compressed with different algorithms, etc. If ever your stub grows too big you can apply this to itself as ASM can load chunks of it code in any memory place even previously used code pointers, but NX (not execute) flag in CPU (not present in 486 cpus?) could be a problem sometimes.

[Roberto A. Foglietta]

I may have one idea for your stub.
In my opinion the main use of your program is that decompress in RAM (an ELF64, a sh-script etc). But for big RAM should not matter: someone could mount a TempFS -- hm, needs root rights -- on a folder and decompress there (aka in RAM, not touch the HDD) with the same useful busbox-applets (zcat, guzip etc). Ex: 10MB UPZ will expand in RAM as (lets say) 20 MB. so you need 30 MB free RAM before run the original gzipp-ed program.
When the RAM is low, then one possible/future option/advantage could be decompress + replace in place, overriding the already used chunk of what was executed. (technique from viruses). For sh / python script works OK. for ELF they need to be modular designed from scratch (not applicable to TC compiled tcz as now).

PS: Any program could be build in small pieces, each chunk compressed with different algorithms, etc. If ever your stub grows too big you can apply this to itself as ASM can load chunks of it code in any memory place even previously used code pointers, but NX (not execute) flag in CPU (not present in 486 cpus?) could be a problem sometimes.

You are quite confused but it is ok. It is not supposed you do business with uzpexec.

[nick65go]

You are quite confused but it is ok. It is not supposed you do business with uzpexec.

For me is like instead of 7zip-archive I will have a 7z-self-extracting. The stub offer some comfort in automation. I just evaluate the "return" (in speed, lower resources, etc) if I "invest" (time, skills, etc) to use it.
Maybe I am a little confused because I try to see its practical value for me, with my "narrow" vision and focus on efficiency, instead of the larger audience goal. For me 7z-self-extracting add "bloat" stub of 200KB but can compress LZMA-solid type (re-gain size here more than 200KB for a big "package"). Or just use xz form busy-box.
Please carry-on, I am just a guy on internet after all, curious about innovation not often seen/shared. That is the motive I use TC forum 

[Roberto A. Foglietta]

You are quite confused but it is ok. It is not supposed you do business with uzpexec.

For me is like instead of 7zip-archive I will have a 7z-self-extracting.

- No official 7-Zip self-extracting (.exe SFX) application exists for Linux

You suggested a comparison with UPX, and the comparison did not stand. This one either. You are not "curious" (as you suggested), you are confused (as I suggested). The difference between these two states of mind, is functional. Curiosity is about investingating the unknown and uncomfortable but ASM isn't in your chords, so -- you avoid the coding part -- while confusion is trying to settle down a mess in their own mind trying to map a new concept into old concepts.

Therefore, I want to help you addressing your own question. Ask yourself, why now and not 20 years ago (or 2014 when memfd_create() was instroduced into the kernel, or iin 2018 when it was included into glibc). The second question that matters, why 1-dd block limit when 2Kb or 4Kb would have been a great choice anyway (from your point of view in which an inflated binary in RAM is about 30MB, the size of a dynamically linked qemu-system for example).

Two questions that would not challenge your techncal skils and have a more practical value, once properly answered.

[nick65go]

- No official 7-Zip self-extracting (.exe SFX) application exists for Linux

I repet myself here, again. I really appreciate your efforts and programing skills. I just ask + learn, no offense intended, OK?

FYI: from 7-zip extras for Linux, https://superuser.com/questions/804736/7-zip-extras-for-linux
"Solved it, I can simply 'cat' and produce a PE executable from Linux itself. Here goes:

Code: [Select]

# cat 7zS.sfx config.txt FILE.7z > FILE.exeWhere 7zS.sfx is the SFX file from the 'extras' 7-zip bundle, 'config.txt' is the configuration file as per documentation instructions and 'FILE.7z' is a 7-zip file produced using the native Linux p7z."

from my laptop here:

Code: [Select]

❯ ls /lib/7zip/
.rwxr-xr-x 711k root 27 Jun 00:32 󰡯 7z
.rwxr-xr-x 2,8M root 27 Jun 00:32  7z.so
.rwxr-xr-x 1,7M root 27 Jun 00:32 󰡯 7za
.rwxr-xr-x 408k root 27 Jun 00:32  7zCon.sfx     <--here!
.rwxr-xr-x 1,2M root 27 Jun 00:32 󰡯 7zr

[Roberto A. Foglietta]

from my laptop here:

Code: [Select]

❯ ls /lib/7zip/
.rwxr-xr-x 711k root 27 Jun 00:32 󰡯 7z
.rwxr-xr-x 2,8M root 27 Jun 00:32  7z.so
.rwxr-xr-x 1,7M root 27 Jun 00:32 󰡯 7za
.rwxr-xr-x 408k root 27 Jun 00:32  7zCon.sfx     <--here!
.rwxr-xr-x 1,2M root 27 Jun 00:32 󰡯 7zr

As you can see it requires installing in path about 8Mb of stuff. Alike all the others old-idea mapping, also this implementation requires the root priviledges at a certain point. I agree that immediate execution of a gzip (or another compressed format) by pipe isn't the strongest point for uzpexec but a nice feature to have. In fact, wget $url -O- | zcat | /bin/sh **usually** works. Notice that **usually** works for the shell **scripts** but not for the binaries (and among shell scripting probably also the newer implementatation of gzcmd.sh which uses tmpfs for extracting and executing a binary)

However, it is extremely hard for a windows-tailored mind and more in general for a linux end user understand the value of uzpexec. It is not just a matter of its extreme low footprint, it is a matter of scale. And about scale, it is not **only** about size but also about various aspects like not root priviledge, compact delivery, immediate deplyment, piping, disk-less, etc. None of the solutions that you listed can be deployed into a dynamic scaling virtual-only system. Therefore, they never partecipate into what it would be able to sustain an app market for a supervisor OS. Inflating is another nice to have feature, not a must to have. It would be stupid not having it, in fact it has been implemented by `/bin/zcat` because it is an ancillary dimension. Again, modularity is a must-to-have design. Under this PoV, uzpexec offers the fundamental features those were currently **not** available. In the README.md, there are some example of use and as you can see they are pretty interesting for end-users as well.

Last but not least, trustability is **not** an issue for uzpexec becase the MIT+1 licensing terms and becuase the syscall are a contract with the Linux Kernel, if they are broken, then it is the kernel being broken not the uzpexec. Obviously, assuming that being open-source and 300 LoC allows being audited and bug fixed in a few days by every serious player that need to provide it (and in fact, it has the provider field as complementary in MIT+1). When someone cares to put a "provider" field into a 512-stub, and that stub is designed to be manipulated by a `sed` command to be adapted different scripting language, you have been granted since its design that the "market" of that tool isn't the end-users.

---

### 1. The Context: Official 7-Zip on Linux

Historically, 7-Zip was exclusively a Windows application. Linux users relied on a **third-party port** called **`p7zip`**.

However, since version **21.01**, Igor Pavlov (the creator of 7-Zip) introduced **official, upstream support for Linux**. As of this release, `p7zip` is considered deprecated and obsolete. The file structure you see in your `/lib/7zip/` directory (including `7z`, `7z.so`, `7za`, `7zr`, and `7zCon.sfx`) is compiled directly from the official upstream 7-Zip source code.

### 2. What is `7zCon.sfx`?

The `.sfx` file stands for **S**elf-**F**ormatting **Ex**ecutable (or Self-Extracting) stub.

* **Official Source:** The file `7zCon.sfx` is the official console-based self-extracting stub provided by 7-Zip. Your Linux distribution compiled it straight from the official source bundle (`SFXCon` in the source code).
* **Cross-Platform behavior:** * The SuperUser post you quoted is discussing creating a **Windows executable (`.exe`)** on Linux. To do this, they concatenated a Windows SFX stub (like `7zS.sfx` or `7z.sfx` from the Windows "extras" bundle) with a Linux-generated `.7z` file.
* The `7zCon.sfx` file on your laptop is the **native Linux console stub**. If you use `cat` to combine `7zCon.sfx` and a `.7z` file on your laptop, it will produce a **native Linux self-extracting executable** (which you would then run via `./FILE`).

[nick65go]

I was irritated by your style so I'll answer you briefly / dry:

1. I didn't ask you any questions, (read my messages!). I just made strong / bold statements. I documented them where applicable.

2. I haven't (yet!) given you any negative epithets. Unlike you who made a pseudo-psychology of my mind (confused, mess, windows-tailored, -- too many to quote here). I would advise you to review your language as you would like to be treated.

2. upx (5.2) or 7z (26.02) are subject to scrutiny by 1000+ developers, even if their self-exe have 200-400 KB stubs.
Even if your program has some merits (it is more compact 512 Bytes), it does not negate the intelligence put into others. I have no interest in promoting any of them, neither yours, I just use them. In year 2026, a few KB means almost nothing for desktops or laptops, maybe it matters in embedded systems.

3. I'm not interested in your comments about 7z.sfx. Is not my baby and it works for me. Period! Nor about how some people wrongly say that I can't install programs without being an admin / root user.

3. In an interview you have a maximum of 20-40 seconds to impress a (curious) manager regardless of the candidate technical skills. It doesn't mean that the manager isn't curious, or is superficial, but he prioritizes profit / efficiency from HIS point of view. He doesn't go into technical details if it's not worth the effort. As if you don't need Picasso to paint a wall white.

4. I personally don't need any more explanations from you, but you can give them to audience.

5. The fact that for me the annual return is 0.0001% does not mean that your program is worthless. It's just that some of us are more picky and spoiled. Q.E.D.