Linux Virus Troubleshooting Saga

Downloaded a virus for Linux lately and unpacked it. Tried to run it as root, didn't work. Googled for 2 hours, found out that instead of /usr/local/bin the virus unpacked to /usr/bin for which the user malware doesn't have any write permissions, therefore the virus couldn't create a process from it. Found patched .configure and .make files on some Chinese forum, recompiled and rerun it. The virus said it needs the library cmawl-lib-2.0. Turns out cmawl-lib-2.0 is shipped with CentOS but not with Ubuntu. Googled for hours again and found an instruction to build a .deb package from source. The virus finally started, wrote some logs, made a core dump and crashed. After 1 hour of going through the logs I discovered the virus assumed it was running on ext4 and called into its disk encryption API. Under btrfs this API is deprecated. The kernel noticed and made this partition read-only. Opened the sources, grepped the Bitcoin wallet and sent $5 out of pity.

A fake technical support story describes someone painstakingly helping a Linux virus install itself, resolve dependencies, compile from source, and recover from a crash. The punchline is that after all this effort, the virus still fails because of filesystem incompatibility, so the narrator feels sorry for it and sends it Bitcoin. This is used as a reaction to absurdly difficult troubleshooting or excessive sympathy for a broken piece of software. EN: A fake technical support story describes someone painstakingly helping a Linux virus install itself, resolve dependencies, compile from source, and recover from a crash. The punchline is that after all this effort, the virus still fails because of filesystem incompatibility, so the narrator feels sorry for it and sends it Bitcoin. This is used as a reaction to absurdly difficult troubleshooting or excessive sympathy for a broken piece of software.

• @eternalclassic / 42340 2023-11-25