Tags: bpf re
Rating:
# Pwndoor - Rev (150 + 0), 5 solves
> We found this implant on some of our servers, help us figure it out!
In this task, we were given a small binary and host on which it was running. Note that we did not have a port,
we had to figure it out ourselves.
The binary is rather small. It first creates a raw socket, attaches a BPF filter to it, and then waits for any
packet matching the filter to arrive. Then it sends the flag to the sender ip, on TCP port 4444.
The only difficult thing there is to analyze the BPF filter. The tooling surrounding it is in pretty bad condition -
we were not able to find a disassembler that would work correctly. In the end, we used the same approach as in
http://www.gnoobz.com/hitb-ctf-2016-binary-300.html, that is using `/proc/sys/net/core/bpf_jit_enable`, which would translate the BPF to
x64 code and dump it in `dmesg` output.
Reverse engineering that wasn't too different from any other RE challenge. There were a couple of arithmetic
checks on a couple of bytes of the packet. From these, we could conclude:
- it has EtherType = 0x800, that is, it's IPv4,
- it has protocol type = 17, i.e. UDP,
- UDP port = 3333,
- packet data must contain a certain text.
From the packet data structure, we guessed it is a DNS packet (it had a couple of constants identical to DNS).
The finally accepted packet was then generated by: `dig @34.245.139.8 -p 3333 'M4d!bKn3~l' TXT`, which after
sending, caused the server to call us back on TCP port 4444.
