System Architecture Overview
This overview explains how the practice environment is built. It is designed around isolation, containment, and resilience so you can focus on the challenge itself. Five points shape the design.
-
Per-User Isolation
In the three-stage Node.js → Ruby → PHP challenge, each player gets a dedicated container chain, created on demand. Targets and their state are not shared with other players. CPU and memory limits help contain resource-heavy experiments, while the underlying hosts are shared.
-
Strict Network Isolation & Pivoting
Each player has one private network connecting Node.js, Ruby, and PHP, isolated from other players and the host. Enter through the Node.js web application. Ruby and PHP Web ports accept only local connections; reach them through the previous application's SSH key and the next box's unprivileged guest account.
-
Container Hardening
Containers have no outbound internet access and a read-only root filesystem, with limited writable temporary directories. Downloading tools from the internet with
wgetorcurlwill not work. Commands must run through the compromised application.There is no platform file upload.
-
Scalability
Lab capacity is limited. If the cluster is full, new requests are queued while infrastructure auto-scales up to a hard cap. Keep /play open while you wait. If your browser stops polling for 90 seconds, you are dropped from the queue. When your turn arrives, you have 60 seconds to deploy.
-
Recorded Progress & Recovery
Labs are temporary. A lab stops after 15 minutes without activity and lasts at most 2 hours in total. Your solves are kept, but files, shells, and listeners are lost. Open the lab again from /play to get fresh boxes.
A new lab starts with 45 minutes. While active, its remaining lifetime is renewed to at least 30 minutes, within the 2-hour total limit.
Solves recorded from correct flag submissions and the resulting stage unlocks are retained.
Connecting to your lab
How the lab works
- Use Open target in /play to open the Node.js web app over HTTPS.
- Compromise the Node.js application to read its flag and find the Ruby SSH key. Use that application foothold to run commands inside Node.js.
- On Node.js, find the SSH key that opens the Ruby box, then SSH from Node.js to Ruby as an unprivileged guest.
- The Ruby search application listens only at
http://127.0.0.1:8000/inside Ruby. HTTP requests must originate inside that box. Exploit the Ruby search application to run as its application user. Only that user can read the Ruby flag and the next SSH key. SSH from Ruby to PHP lands you as an unprivileged guest again. - The PHP application also listens only at
http://127.0.0.1:8000/inside PHP. HTTP requests must originate inside PHP. Exploit the PHP application as its application user to reach the final flag and the treasure. Guest SSH access alone does not expose either. Node cannot connect directly to either box's Web port.
Keys for Ruby and PHP exist only inside the lab. No key you bring or register opens Node.js, Ruby, or PHP.
Getting in
Use Open target in /play to reach the Node.js app in your browser. Your first goal is remote code execution (RCE) through that app. Use the compromised Node.js application as your first foothold and continue toward Ruby, then PHP.
What’s off-limits
Work only on your assigned challenge targets. Outbound internet access is blocked. Other players, their boxes, the host, and the platform itself are out of scope.
Connection diagram
Scroll the diagram sideways to read it on a smaller screen.
