While looking through results on @Huntio, I came across an exposed HTTP directory hosting four Linux ELF binaries: dlrc5.x86, dlrc5.arm64, dlrc5.arm7, and dlrc5.mips. I pulled the samples into Ghidra and started with the networking and ADB functions. All four binaries are statically linked and not stripped, so quite a few internal function names are still available. They also share 19 static indicators. I compared the adb_send function across all four architectures and found the same packet construction, CRC calculation, and sending logic. The samples appear to come from the same codebase. The malware probes local network addresses on TCP/5555 (ADB) and TCP/23 (Telnet). I found an ADB propagation routine, but couldn't identify a Telnet infection routine. Instead of using the regular adb client, the malware implements its own ADB communication. It constructs CNXN, OPEN, and WRTE messages and attempts to open a remote shell. The shell command uses uname -m to identify the target architecture, then attempts to download the appropriate ELF to /data/local/tmp/dlrc5 and execute it. The downloader references 185.216.68[.]87 and 85.121.4[.]25 as its download hosts. One thing stood out in adb_send: the checksum calculation. The samples use CRC32 with the 0xEDB88320 polynomial to calculate the ADB payload checksum. However, the legacy ADB protocol uses a simple byte sum, and the malware advertises protocol version 0x01000000. For the host:: payload, CRC32 produces 0x87D0043D, while the expected additive checksum is 0x00000232. I checked all four architectures and found the same implementation. This mismatch could cause communication failures with ADB implementations that validate the legacy checksum. I haven't tested it against a real device, so I can't confirm its practical impact yet. I also looked into the C2 communication. The x86-64 sample connects to 185.216.68[.]87:39600 over TCP and sends JSON check-ins containing the marker buju-v1-9f3k. The bot reports LAN scanning results and sends periodic heartbeat messages. In main, incoming C2 data is appended to /tmp/.dlrc.cmd along with a timestamp. I found no evidence of these messages being executed in the code I examined. There are also persistence attempts through /etc/rc.local and /etc/init.d/dlrc5d, watchdog interaction, OOM protection changes, and a routine that terminates processes matching other malware names, including Moobot, Gafgyt, and Tsunami. I couldn't tie the code to Mirai, Gafgyt, or another known malware family with enough confidence. For now, I'm referring to these samples as the DLRC5/BUJU cluster. This is a provisional research label, not a claim of a new malware family.