Счет на минуты (Counting by Minutes)
Счет на минуты (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 classc10, 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
-
Export the Google Doc as plain text:
bash read-only • copy allowedcurl -sL "https://docs.google.com/document/d/1iHZtQztwIx3MAxIV-0-VFkwALsm8UihC699Et6_M_BI/export?format=txt" -o report.txt -
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] -
Apply the ASCII transform
minute + 60to each value. -
The result is
BugCTF?TiMe_IS_kEYA. The two boundary characters —3+60 = 63 = '?'(position 7) and5+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
| # | Timestamp | Minute | +60 | ASCII |
|---|---|---|---|---|
| 1 | 12:06 | 6 | 66 | B |
| 2 | 12:57 | 57 | 117 | u |
| 3 | 13:43 | 43 | 103 | g |
| 4 | 14:07 | 7 | 67 | C |
| 5 | 14:24 | 24 | 84 | T |
| 6 | 15:10 | 10 | 70 | F |
| 7 | 16:03 | 3 | 63 | ? → { |
| 8 | 16:24 | 24 | 84 | T |
| 9 | 16:45 | 45 | 105 | i |
| 10 | 17:17 | 17 | 77 | M |
| 11 | 17:41 | 41 | 101 | e |
| 12 | 18:35 | 35 | 95 | _ |
| 13 | 19:13 | 13 | 73 | I |
| 14 | 19:23 | 23 | 83 | S |
| 15 | 19:35 | 35 | 95 | _ |
| 16 | 20:47 | 47 | 107 | k |
| 17 | 21:09 | 9 | 69 | E |
| 18 | 21:29 | 29 | 89 | Y |
| 19 | 22:05 | 5 | 65 | A → } |
| |
Solve script
python read-only • copy allowed#!/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.