IoT Hacking Challenge Walkthrough - RTSP TO HTTP

Introduction

Entering the HiveHack room at CyberSea, I was immediately impressed by the densely packed array of challenges ranging from door hijacking and lockpicking to intricate puzzles all meticulously crafted by HackHive. After systematically working through several tasks, my focus shifted to the multimedia streaming challenge. Unlike the others, this task remained untouched, offering a distinct and technically engaging opportunity involving an IP camera and an older Samsung smart TV.

The challenge appeared straightforward in its description but revealed layers of complexity: gaining access to the local area network (LAN), intercepting the video stream from the IP camera connected to that network, and successfully displaying the live feed on the legacy smart TV.

Surveying the physical setup, I observed a router, the IP camera, and the smart TV arranged in close proximity. Rather than attempting to breach Wi-Fi security via brute force or social engineering, I chose a direct wired connection through Ethernet to the router. Although this approach bypassed some real-world constraints, it allowed me to focus intensively on network reconnaissance and exploitation without the added difficulty of wireless access.

Network Reconnaissance

Spotting the IP camera on the table, my first step was to verify if it was operating with default settings especially the RTSP streaming port and credentials. Many IP cameras come pre-configured to use the standard RTSP port 554, so I tested connectivity assuming those default configurations, which proved successful.

Building on this, I then aimed to identify the camera’s precise IP address within the network. To achieve this, I ran a targeted network scan focusing on port 554, the typical RTSP port, across the subnet range where the device was likely connected:

nmap -p 554 192.168.1.1/24 | grep -B 4 "554/tcp open"

RTSP Credential Brute-Forcing

After identifying the IP camera's address and confirming the open RTSP port, the next hurdle was gaining access through authentication. Many IP cameras use default or weak credentials, so I developed a custom Python script, rtsp_crack.py, to automate brute forcing RTSP login credentials.

The script iterates through a supplied list of common usernames and passwords, attempting to establish an RTSP connection using each combination. RTSP protocol handlers to validate successful logins by checking the server's response headers and status codes.

This targeted brute force approach significantly reduced the time needed to find valid credentials compared to manual attempts, ultimately allowing me to authenticate to the camera's stream securely.

python3 rtsp_crack.py --target 192.168.1.100 --userlist users.txt --passlist passwords.txt

The script output clearly indicated successful authentication attempts, enabling me to proceed with capturing and relaying the live RTSP stream to next step.

Testing the RTSP Stream

With valid credentials in hand, the next step was to verify if I could successfully access and view the RTSP video stream from the IP camera. I chose popular media players such as VLC or ffplay from the FFmpeg suite, both of which support RTSP streaming.

Using VLC, I opened a network stream by entering the RTSP URL in the format:

rtsp://admin1:admin1@192.168.1.100:554/stream1

Similarly, ffplay was launched from the command line to test the live feed:

ffplay rtsp://admin1:admin1@192.168.1.100:554/stream1

Both methods confirmed successful streaming of the live camera feed, providing real-time video that could now be captured and relayed for further processing.

Converting RTSP to HTTP Streaming

To relay the live RTSP feed to devices that better support HTTP streaming, the next step involved converting the RTSP stream into an HTTP-compatible format using FFmpeg. Specifically, I used FFmpeg to transcode and segment the video into HTTP Live Streaming (HLS), which breaks the video into small chunks (.ts segments) and serves a playlist (.m3u8) for playback in browsers.

The core command employed FFmpeg with parameters to scale the video to 1920x1080 resolution, encode it with the H.264 codec at 25 frames per second, compress it to balance quality and bandwidth, and generate HLS segments with a 5-second duration:

ffmpeg -v verbose -i rtsp://USERNAME:PASSWORD@CAMERA_IP/LIVE_PATH \
-vf scale=1920:1080 -vcodec libx264 -r 25 -b:v 1000000 -crf 31 -acodec aac \
-sc_threshold 0 -f hls -hls_time 5 -segment_time 5 -hls_list_size 5 OUTPUT_PATH

To streamline this process, I automated the workflow using a bash script that:

• Deletes old video segment files before starting fresh.

• Loads necessary environment variables such as camera credentials, IP, stream path, and output directory from a .env file.

• Executes the FFmpeg command with the loaded variables.

• Loops the process to ensure continuous streaming.

./live_stream.sh

Hosting the Stream via Python Server

With the HLS playlist and video segments prepared, I needed a way to serve them over HTTP so that any browser or smart device could access the stream directly. For simplicity and portability, I wrote a minimal Python simple server that hosts both the video segments and a dedicated HTML player page.

The server exposes the root path ( / ) to serve index.html, and a secondary route (/video/<filename>) to serve the .m3u8 playlist and .ts segments:

python3 server.py

Once running, any device connected to the local network could access the stream by visiting the server's IP address ( printed in the terminal when the server starts ) in a browser:

http://192.168.***.***:8000

Displaying on the Smart TV

The final stage of the challenge was to display the HTTP stream on the Samsung smart TV. Since the TV had a built-in browser but no native RTSP support, the HLS-based approach proved ideal. Using the TV’s remote, I launched the browser and navigated to the server IP address ( printed in the terminal when the server starts ).

http://192.168.***.***:8000

Within seconds, the video began to load and stream seamlessly. The player controls were functional, allowing pause/play interaction, but the goal was simply live display and it worked perfectly.

Conclusion

This challenge was a brilliant exercise in network reconnaissance, protocol exploitation, and creative video delivery. From probing RTSP ports and brute-forcing camera credentials to converting and serving a live stream over HTTP, the end-to-end workflow highlighted how real-world security oversights like default passwords or exposed streaming ports can be leveraged to hijack video feeds. More importantly, it showcased how quickly technical problems can be solved with a blend of scripting, open-source tools, and strategic thinking.

In a real-world context, this highlights the importance of:

• Changing default credentials on all IP-connected devices.

• Isolating surveillance hardware from general-access networks.

• Monitoring open ports like RTSP and HTTP using automated scans.

The HiveHack experience was an excellent example of applying penetration testing techniques to unconventional targets and turning a static camera into an active element in the puzzle.

Resources

All the scripts and tools used throughout this challenge, including the RTSP credential brute-forcing script (rtsp_crack.py), the FFmpeg streaming automation script, and the Python HTTP server code, are publicly available on my GitHub repository:

DarkSoulEngineer/RTSP_TO_HTTP

Feel free to explore the repository for full source code, usage instructions and more details on the techniques used in this challenge.