The MesaNet Portal hosts a "Rail Broadcasts" application accessible through a JSON gateway API. A low-privilege operator account can interact with several broadcast endpoints, but a confidential note owned by a privileged automated user sits just out of reach. The challenge requires chaining the broadcast creation pipeline with the automated oversight system to escalate access without ever touching the privileged session directly.
Objetivo: Using the gateway, probe the `/api/notes/get` endpoint with sequential note IDs to find the one note your session cannot read.
Contexto: The portal also exposes a notes API through the gateway. Your `operator` session has clearance L3. Try fetching notes by integer ID — start from 1 and increment. Pay close attention to the difference between error messages: some IDs will say the note doesn't exist, while one specific ID gives a different error.
Revela solo las que necesites. Claude lleva la cuenta de cuántas usaste para calibrar la retroalimentación.
Try sending `POST /gateway` with `endpoint: "/api/notes/get"` and `data: {"id": 1}`. Then increment the ID. The wording of error responses changes at a specific ID — that difference is meaningful.
One note ID returns `"Insufficient permissions to read this note"` instead of `"Note not found"`. That phrasing means the note EXISTS but your clearance level is too low. Every other ID either succeeds or says it wasn't found.
Note ID `6` is the one that returns the permissions error. All other IDs (5, 7, 8, etc.) either return content or "Note not found". Note 6 has `classification: confidential` and belongs to a user other than you.
Chatea con un tutor anti-spoiler para este paso. Usa solo la especificación de este lab y empieza por la pista más pequeña que sirva.
Cuéntale qué probaste, dónde te atoraste, o pega la respuesta/error que estás viendo.
¿Te gusta Hintru? Buy me a coffee ☕ ☕