pcap: detect embedded ELF inside captures?

[febnug]

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.

[trufae]

To search for binaries inside binaries you can use /m to search for known magic headers. i would set search.align=4 at least. if you want to search for the elf magic just /x ELF\x7f or /b for any bin format.

I dont think that should be specific to pcap (despite the tcp stream reconstruction thing may be interesting to work in a similar way the rfs plugins work. So you can select one stream and read all the data linearly.

To parse a binary directly from an offset you can use the oba $$ command. which opens a binary at offset. not all bin plugins support working from sparse memory. But it seems like a good feature to have indeed. The pcap plugin can be improved a lot i think also considering with all the new ctypes support for parsing network packets with ctypes and such.

[febnug]

Yeah that makes sense.

True, /m + oba already covers the binary-in-binary case. The stream reconstruction idea is more interesting though. I’ll play with that direction instead.

[trufae]

Awesome! One idea would be to use the iosystem commands to change the io data at runtime. You can also implement a virtual filesystem for pcap thos way if you use the fs.io plugin.

[trufae]

Any updates on this? Because imho we can close the ticket because it sounds more like a feature request or question than a real issue

[febnug]

Hello, I see your point this is closer to a feature request

A few weeks ago I built a small prototype around this idea using the pcap:// IO plugin

febri@ubuntu:~/project/pcap-files$ r2 -e bin.relocs.apply=true -q -c "s 0; b 0x3ea0; wt dumped_elf" "pcap://elf_transfer.pcap?flow=0&dir=server"
INFO: Dumped 16032 bytes from 0x00000000 into dumped_elf

It allows reconstructing an ELF directly from a TCP stream inside a PCAP and then analyzing it with r2. This produces a valid ELF that can be loaded and analyzed normally:

febri@ubuntu:~/project/pcap-files$ file dumped_elf 
dumped_elf: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, stripped
febri@ubuntu:~/project/pcap-files$ r2 -e bin.relocs.apply=true dumped_elf 
 -- All your base are belong to r2
[0x00001060]> pd 14 @ main
            ;-- main:
            0x00001149      f30f1efa       endbr64
            0x0000114d      55             push rbp
            0x0000114e      4889e5         mov rbp, rsp
            0x00001151      488d05ac0e..   lea rax, [0x00002004]       ; "ELF over TCP!"
            0x00001158      4889c7         mov rdi, rax
            0x0000115b      e8f0feffff     call 0x1050
            0x00001160      b800000000     mov eax, 0
            0x00001165      5d             pop rbp
            0x00001166      c3             ret
            0x00001167  ~   00f3           add bl, dh
            ;-- section.invalid29:
            0x00001168      f30f1efa       endbr64                     ; [29] --wx section size 15800 named invalid29
            0x0000116c      4883ec08       sub rsp, 8
            0x00001170      4883c408       add rsp, 8
            0x00001174      c3             ret
[0x00001060]>

This workflow can be useful for cases like CTFs, malware delivery over TCP, etc.

If this is considered out of scope for the issue tracker, I’m happy to turn this into a proper feature or plugin improvement.