-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
Description
Hey,
I was playing a bit with the pcap bin plugin and noticed something interesting.
We parse packet layers nicely (Ethernet/IP/TCP/etc.), but if there’s an actual ELF being transferred over the network, r2 won’t tell you that there’s a binary sitting inside the capture.
I tried a simple test:
- send an ELF over TCP (netcat)
- capture with
tcpdump - open the pcap in r2
- run
is
There is a valid ELF header inside the TCP payload, but currently nothing points to it.
I hacked a tiny prototype that just scans the raw PCAP buffer for \x7fELF and injects a symbol at that offset:
embedded_elf_candidate
Something like:
febri@ubuntu:~/project/pcap-files$ r2 elf_transfer.pcap -- Save your projects with 'Ps ' and restore then with 'Po ' [0x00000000]> is nth paddr vaddr bind type size lib name demangled ――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― 0 0x00000000 0x00000000 NONE NONE 0 tcpdump capture file - version 2.4 (Ethernet, capture length 262144) 0 0x00000170 0x00000170 NONE NONE 0 embedded_elf_candidate [0x00000000]>
And it works fine for a minimal PoC.
I know this is not stream-aware (no TCP reassembly, etc.), just a simple global scan. But PCAP is basically a container, and in malware/CTF scenarios it’s pretty common to see binaries delivered over the wire.
So I’m wondering:
Would it make sense for the pcap plugin to optionally detect embedded binaries (at least ELF) and expose them as symbols?
Could be behind a config flag if needed.
If this direction makes sense, I can clean up the patch and refine it further (maybe later move toward stream-based detection instead of raw scan).
Just wanted to check first before going deeper.