Flagvent 2025: Day 4

FV25.04 - our house

Difficulty
easy

Categories
misc

Description
The damn Grinch messed around again with Santas files! And now he can't watch his favorite video. Can you help me?
Hint: This challenge consists of two parts, do not let the first one waste your time after completing it.

Author
W1nd5h13ldV1p3r

Solution

We’re given a chal.mp4 file that appears corrupted and won’t play. Inspecting the binary shows it’s mostly a valid mp4 but missing a header. We use untrunc to try to repair the video. untrunc requires a reference video with similar encoding and frame rate, which it uses to reconstruct the broken mp4.

Running strings on chal.mp4 reveals some interesting metadata suggesting the video originated from YouTube:

$ cat chal.mp4 | strings | grep "Google"                           
ISO Media file produced by Google Inc. Created on: 01/30/2025.
ISO Media file produced by Google Inc. Created on: 01/30/2025.

Therefore, for our first attempt, we use a downloaded 720p version of the Rick Roll video:

$ untrunc -s -sm -sv rick720p.mp4 chal.mp4

This gives us a partially repaired video that is playable but contains invalid frames, as shown below:

We see the text Our House in the video so we’re on the right track, but our reference video is clearly too large in resolution. Through trial and error we realise that 360p is the correct resolution:

This video plays mostly correctly but the audio stream is a bit messed up and the video and audio durations are misaligned, so something is still wrong. We take a different approach and use the EaseUs Repair website to fix the original chal.mp4. It produces a valid mp4. Comparing its header with the original shows the first 32 bytes are incorrect. We patch those bytes in chal.mp4 using the repaired file and create a working chal-fixed.mp4. Around this point we also notice that the Our House video is on YouTube.

Looking at the properties of this file, we notice that it contains two audio streams:

$ ffmpeg -i chal-fixed.mp4
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'chal-fixed.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf62.3.100
  Duration: 00:02:07.87, start: 0.000000, bitrate: 483 kb/s
  Stream #0:0[0x1](und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 640x360 [SAR 1:1 DAR 16:9], 297 kb/s, 30 fps, 30 tbr, 16k tbn (default)
      Metadata:
        handler_name    : ISO Media file produced by Google Inc. Created on: 01/30/2025.
        vendor_id       : [0][0][0][0]
  Stream #0:1[0x2](eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 129 kb/s (default)
      Metadata:
        handler_name    : ISO Media file produced by Google Inc. Created on: 01/30/2025.
        vendor_id       : [0][0][0][0]
  Stream #0:2[0x3](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, mono, fltp, 70 kb/s
      Metadata:
        handler_name    : SoundHandler
        vendor_id       : [0][0][0][0]

Track 0 is the regular tune from the YouTube video.
However, track 1 is more interesting because it’s a tone-based audio track:

At this point we spend a lot of time trying different approaches, including steganography with Audacity and Sonic Visualiser, as well as frame analysis. We also try decoding track 1 using audio encodings like Morse code with no success. Browsing the Sigidwiki active signal page, we see various signals with sample audio and spectrogram waterfall images that might point us in the right direction.

A spectrogram of track 1 is generated to compare it with the entries in the wiki:

After extensive trial and error, the Slow Scan Television (SSTV) spectrogram appears to match. Playing the sample audio further confirms it closely resembles the track.

Using an Online SSTV Decoder on track 1 produces an image containing the flag:

Flag:

FV25{0ur_h0u53}