You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For some challenges that are resource intensive for hosting per-connection (like kernel pwn or anything that runs a new container per connection), it's common practice to put such a challenge behind a proof of work. This typically involves making the player brute force some hashes to spend a configurable amount of time (approximate) before they're able to connect to the real challenge. This is something that can likely be integrated cleanly into PwnableHarness, so challenge authors can just add something like the following to their Build.mk files:
# Enable proof of work when connecting to the Docker containerDOCKER_PROOF_OF_WORK := 1
# Perhaps this is the average number of seconds it should take to complete the proof of work.# This would likely be used to set the hash prefix length and potentially number of rounds of hashing.# There will be a reasonable default for this, so an author will only need to modify this value# if they want to increase it for an especially resource-intensive challenge.DOCKER_PROOF_OF_WORK_DIFFICULTY := 10
The text was updated successfully, but these errors were encountered:
For some challenges that are resource intensive for hosting per-connection (like kernel pwn or anything that runs a new container per connection), it's common practice to put such a challenge behind a proof of work. This typically involves making the player brute force some hashes to spend a configurable amount of time (approximate) before they're able to connect to the real challenge. This is something that can likely be integrated cleanly into PwnableHarness, so challenge authors can just add something like the following to their Build.mk files:
The text was updated successfully, but these errors were encountered: