247CTF - Custom Protocol Writeup
We are working on our own custom command and control protocol. Can you identify any hidden features in the service? We also included a packet capture of some old sessions so you can learn how it works.
我们正在开发自己的自定义命令与控制协议。您能发现该服务中有哪些隐藏功能吗?我们还提供了一些旧会话的数据包捕获文件,以便您了解其工作原理。
PCAP Investigation with Scapy
The first step was to examine the provided packet capture
(custom_protocol_log.pcap) to understand the communication
pattern. I used scapy to extract and decode raw data from
the TCP streams.
1 | #!/usr/bin/env python3 |
Protocol Reversal
By analyzing the hex data from the traffic between
172.17.0.1 and 172.17.0.2, a clear pattern
emerged:
1 | b925afc1 00 31 00 30 00 323430323435313235 |
The protocol structure appears to be:
[Session ID] [Null] [Counter] [Null] [Command] [Null] [Checksum]
- Session ID: A 4-byte identifier (e.g.,
b925afc1). - Counter: Increments with each request.
- Command: Hex-encoded numbers (e.g.,
30for0,31for1,32for2). - Checksum: A CRC32 calculation of the preceding bytes, where the result is converted to a decimal string and then hex-encoded.
Checksum Verification
Using Python to verify the CRC32 logic:
1 | import zlib |
Solution
Exploit Script
The script enumerates the 15 single-byte command values
0x30..0x3e, corresponding to ASCII
0..9:;<=>. Encoding decimal strings
10..14 would produce different multi-byte fields and is not
supported by the retained trace. CRC32 matches all three displayed
request fixtures offline; the PCAP and remote command semantics have not
been rerun.
1 | #!/usr/bin/env python3 |
Execution Output
1 | [*] Starting brute-force with commands: ['30', '31', '32', '33', '34', '35', '36', '37', '38', '39', '3a', '3b', '3c', '3d', '3e'] |
The returned flag belongs to the launched service instance; no cross-instance invariance is established. Record the generation/retrieval method and use the current instance response instead of a fixed-answer spoiler.