Finish revamp of reversing-python

Author: syreal17

example-problems/reversing-python/README.md

@@ -5,46 +5,29 @@
 1. You have `cmgr` installed and configured.
     - Refer to the [setup page](/setup-cmgr) if this is not the case for you.
 
-2. You have done the [Sanity Problem Creation
-   Walkthrough](/example-problems/sanity-static-flag/README.md). You do not have
-   to do every walkthrough that is listed as easier than this one, but you must
-   at least do the Sanity Problem Creation Walkthrough. This walkthrough is
-   presented as a set of changes from the sanity problem. The sanity problem
-   walkthrough is the core of cmgr challenges, and this problem presents what
-   must be added on top of that for a more complicated challenge.
+2. You have done the [Web CSS Problem Creation
+   Walkthrough](/example-problems/web-css).
 
 ## Overview
 
 This problem uses a container as a service host and presents this service
-through a port.
+through a port. This problem is adapted from the live picoGym problem, [Picker-I](https://play.picoctf.org/practice/challenge/400).
 
-There is 1 main change in this problem that makes it more complicated and
-potentially more interesting:
+This problem can be used as a template for any challenge that needs to host a
+service that players connect to with netcat.
 
-1. The use of a Dockerfile instead of a Makefile which vastly opens up the
-   possibilities for problem development.
-
-Being able to specify a Dockerfile lets us bring the power and repeatability
-of containers to our problem development and deployment. We're going to create
-a container that runs a Python program through a given port using socat. To use
-a custom Dockerfile, we must specify the type of the problem as `custom` in the
-`problem.md`.
-
-This problem is adapted from the live picoGym problem, `Picker-I`.
+The following walkthrough will touch on new problem files and then look at how
+to debug a Dockerfile by running it with Docker instead of cmgr.
 
 ## Walkthrough
 
 ### File Listing
 
-1. Besides problem details, the most important change in
-   [problem.md](/example-problems/reversing-python/problem.md) is changing Type
-   to "custom".
-
 1. [picker-I.py](/example-problems/reversing-python/picker-I.py) this is the
    vulnerable script that we will be hosting as a service on this container.
 
-1. [start.sh](/example-problems/reversing-python/start.sh) starts a listener that
-   receives connections. This script is ran as the last step in the
+1. [start.sh](/example-problems/reversing-python/start.sh) starts a listener
+   that receives connections. This script is ran as the last step in the
    Dockerfile. For this problem, we use socat to connect the output of our
    vulnerable script to a port, allowing users to interact with our script
    through the network.
@@ -61,6 +44,14 @@ This problem is adapted from the live picoGym problem, `Picker-I`.
    We add `artifacts.tar.gz` to this directory as well, which contains a copy
    of the source for the service being run on the container.
 
+NOTE: If you were hosting a vulnerable service that allowed arbitrary remote
+code execution, you would want to consider separating the challenge building
+container from the container hosting the service. If players landed a shell on
+this machine, they would be able to read challenge management data, which
+usually is not a problem, but is not the greatest look for a CTF competition.
+See this [problem](/example-problems/general-ssh) for how to create multiple
+containers for one challenge.
+
 ### Debugging your Dockerfile
 
 For typical problem playtest deployment and testing strategy, see
@@ -106,14 +97,13 @@ process goes a long way in being able to determine what is going wrong.
 
 ## Conclusion
 
-With this walkthrough, we created an advanced problem that used a custom
-Dockerfile to create a container that presented a service to be interacted with
-in the shell.
+With this walkthrough, we created an advanced problem that used a Dockerfile to
+create a container that presented a service to be interacted with in the shell.
+
+This walkthrough also demonstrated how to gain more debugging insight into cmgr
+problems by building the container manually with docker which provides a lot
+more information about build failures.
 
-Using the custom problem type in cmgr opens the doors to creativity but also
-needs more powerful debugging. This walkthrough also demonstrated how to
-gain more debugging insight into custom cmgr problems by building the
-container manually with docker which provides a lot more information about
-build failures.
+[Next problem](/example-problems/general-ssh)
 
 [Return to the index](/example-problems#example-problems)