CTFZone Paper: Trust Area — Infra

Apps bootstrap

We had an emulator and a clean snapshot. Every round, we did a reset to the initial ‘clean’ state and installed the teams’ applications.

Concurrent communication chains

We inherited the checker infrastructure from the previous CTFs as a global checking platform. Within this platform, there were several checking modules (system checkers), one per service. The platform spawned tasks for the checkers totest the condition of the team’s services or update its round flag. The Trust Area checker will be referred to as the System Checker.

  • REST API to accept commands from the System Checker and results from the Checker Agent
  • Emulator Manager for Android-side deployments
  • APK Grabber 3000 to collect the teams’ applications and control their versions
  • small async glue to organize the other parts
Fig. 1. System Checker-initiated action flow
  1. The System Checker interacted with a simple REST API of the Trust Area Core and knew nothing about the complexity of the underlying communications — therefore, it was programmed in a simple synchronous manner.
  2. The Emulator Manager (within the Trust Area Core) spawned an ADB command to send the intent to the Checker Agent and waited for an HTTP request with the results from the Checker Agent (try to implement it yourself with Futures 😉).

Flags delivery

Another interesting implementation detail was the delivery of flags at the beginning of every new round. Our checking platform was designed to process such tasks/events separately in an asynchronous manner, which satisfies the needsof classic attack-defense challenges.

Fig. 2. Flags change flow

Source code:



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store



International community conference for cybersecurity researchers and professionals. No suits, no business — only hardcore research.