The nine additional instructions highlighted in the diagram add the abilities to activate the backdoor by a TCP packet containing the magic number 0x39393939 at a specific offset. This set of instructions might mean that the developers of BPFDoor wanted to have an additional way of activating the backdoor after its inner workings were detailed in a previously published article. An equivalent filter is as follows:
udp[8:2]=0x7255 or (icmp[8:2]=0x7255 and icmp[icmptype] == icmp-echo) or tcp[((tcp&0xf0)>>2):2]=0x5293 or tcp[((tcp&0xf0)>>2)+26:4]=0x39393939
As the filter suggests, this new magic number should start at byte 26 in the TCP data. This means the first 26 bytes can be anything, which might be an attempt to make detection harder. It is also interesting to note that the previous magic numbers still work in this variant, which ensures compatibility with older versions of BPFDoor.
Doubtful feature: MAC address check
One BPFDoor sample uploaded to a public repository contained a BPF program containing 205 instructions, and we’ve called this sample Variant C. This is almost six times bigger than the previous BPF programs used by BPFDoor.
In this BFP program, the first 4-bit nibble of the packet’s 48-bit (6 bytes) destination MAC addresses is checked. The backdoor seems to be activated only if this nibble is 0x4. In other words, if the destination MAC address starts with 0x4. This is achieved using the following BPF code:
l0: ldb  # load the first byte of the packet to A register.
l1: and A, #0xf0 # A = A & 0xf0 (bitwise AND).
l2: jeq #0x40, l3, l33 # if the result is equals to 0x40, jump to location 3 (l3) and continue execution.
The result will be 0x40 if the byte’s highest nibble is 0x4. The program then uses the lowest nibble as an offset to locate the magic number. In our tests, the most feasible value for the lowest nibble is 0x3, which sets the program to look at the sixth byte from the data field.
However, we don’t know whether this usage of the lowest nibble is intentional or not. One possibility is that the threat actors tried to come up with a BPF code to check for IPv4 and IPv6 packets, but ended up checking the destination MAC address by mistake. Another possibility is that the attackers tried to target machines whose network cards start with 0x4. As the first three bytes of MAC addresses serve as the Organizationally Unique Identifier (OUI), this would make the variant target victims with a particular NIC (network interface card) manufactured by a wide range of companies.
The possible magic numbers did not change compared to the 2022 samples, though. UDP and ICMP both accept 0x7255, while TCP accepts either 0x5293 or 0x39393939. There’s also a code path for destination MAC addresses starting with 0x6 (or tentative to check for IPv6), but seems to be unreachable when checked. The following disassembly highlights the code path for a valid packet:
Read More HERE