← Back to Writeups
CUSTOMMediumForensics

Счет на минуты (Counting by Minutes)

XESXOR9/2/20265 min read
#forensics#custom#medium#ascii_offset_decoding#minute_field_encoding#timestamp_steganography#linux

Счет на минуты (Counting by Minutes)

Platform: bug-makers | Category: Forensics | Type: Challenge | Difficulty: Medium | OS: Linux | Author: XESXOR | Date: 2026-05-29 | Status: Solved Techniques: ascii_offset_decoding, minute_field_encoding, timestamp_steganography

Summary

Task: a leaked Google Docs security report whose chronology of timestamped events hides a note. Solution: extract the minute field of each of the 19 timestamps in order and add 60 to map each value to an ASCII character, recovering the flag (boundary minute values 3 and 5 map to the brace delimiters).

Счет на минуты (Counting by Minutes) — bug-makers

Description

В отдел утечек данных попал внутренний отчёт службы безопасности о попытке взлома сервера 47-A. Документ выглядит стандартно — технические детали, времена, подписи. Однако аналитики заметили несоответствия и подозревают, что автор оставил скрытую заметку для коллег. Отчёт был Google-документом: https://docs.google.com/document/d/1iHZtQztwIx3MAxIV-0-VFkwALsm8UihC699Et6_M_BI

English summary: A leaked internal security-service report about a hacking attempt on server 47-A reaches the data-leak department. The document looks like a standard incident report (technical details, timestamps, signatures), but analysts spotted inconsistencies and suspect the author hid a note for colleagues. The artifact is a Google Doc; the goal is to recover the hidden flag. ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

Analysis

The challenge title "Счет на минуты" (literally counting by minutes / every minute counts) is the central semantic clue. The report body reinforces it: it states that "активность злоумышленника имела строго упорядоченные интервалы — атака велась по минутам" (the attacker's activity had strictly ordered intervals — the attack was conducted by the minute).

The "inconsistencies" analysts noticed are between the narrative prose times (12:06, 12:57, 13:43, 16:49) and the structured chronology list at the end of the report. The chronology section lists 19 events, each with an HH:MM timestamp. ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

The title and body both point to the minute component of the timestamps being the carrier of hidden data, not the hours.

Dead ends checked first

  • HTML colors — the exported HTML contained color:#ffffff, but it was only the page-background CSS class c10, not hidden white text.
  • No comments / suggestions in the document.
  • Inter-event minute deltas, h*60 + m, (h-12)*60 + m, and offset-from-start arithmetic — none produced readable output.

The unlocking reference

A CTF Writeup search surfaced the writeup 20260322_tamuctf_time_capsule ("Time Capsule", tamuctf, forensics), where timestamps encode ASCII via a minutes×60 + seconds style formula. That confirmed the right family — use the timestamp minute fields directly as encoded values — and led to trying a simple constant ASCII offset on the minute field. ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

Solution

  1. Export the Google Doc as plain text:

    bash
    curl -sL "https://docs.google.com/document/d/1iHZtQztwIx3MAxIV-0-VFkwALsm8UihC699Et6_M_BI/export?format=txt" -o report.txt
  2. Read the chronology section and extract the minute field of each of the 19 events, in order:

    minutes = [6, 57, 43, 7, 24, 10, 3, 24, 45, 17, 41, 35, 13, 23, 35, 47, 9, 29, 5]
    
  3. Apply the ASCII transform minute + 60 to each value.

  4. The result is BugCTF?TiMe_IS_kEYA. The two boundary characters — 3+60 = 63 = '?' (position 7) and 5+60 = 65 = 'A' (last position) — correspond to the flag brace delimiters { and }. The author deliberately chose minute values 3 and 5 to mark the opening and closing braces; substituting them yields the clean flag. ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

Decoding table

#TimestampMinute+60ASCII
112:06666B
212:5757117u
313:4343103g
414:07767C
514:242484T
615:101070F
716:03363? → {
816:242484T
916:4545105i
1017:171777M
1117:4141101e
1218:353595_
1319:131373I
1419:232383S
1519:353595_
1620:4747107k
1721:09969E
1821:292989Y
1922:05565A → }
‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

Solve script

python
#!/usr/bin/env python3
# 19 chronology timestamps from the report, in order.
times = [(12, 6), (12, 57), (13, 43), (14, 7), (14, 24), (15, 10),
         (16, 3), (16, 24), (16, 45), (17, 17), (17, 41), (18, 35),
         (19, 13), (19, 23), (19, 35), (20, 47), (21, 9), (21, 29), (22, 5)]

# ASCII transform: minute field + 60
vals = [m + 60 for h, m in times]
raw = ''.join(chr(v) for v in vals)
print(raw)  # BugCTF?TiMe_IS_kEYA

# The boundary minute values (3->'?', 5->'A') mark the flag braces.
flag = raw[:6] + '{' + raw[7:-1] + '}'
print(flag)  # BugCTF{REDACTED}

‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

Related

  • CTF Writeup: 20260322_tamuctf_time_capsule ("Time Capsule", tamuctf, forensics) — timestamps encoding ASCII via a minutes/seconds formula; the conceptual sibling that pointed to decoding the minute field here. ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍