Since there doesn't seem to be any community writeups on this one:

1. The expected solution is this bug https://bugs.openjdk.java.net/browse/JDK-4523159 it's not much of a 0day (since it's from 2001) but it has never been solved.
- jar resource loader assumes that `!` denotes the boundary of the jar
- if the jar is inside a path with `!` loading resources will fail
- solution: provide username ending with `!`, and the password will be `default`
2. There was another, unintended solution, attacking the runner script. It was possible to trigger a race condition between launching the jar and cleanup function
- connect to the service and solve PoW
- wait almost 10s
- right before cleanup is called from sigalarm, provide any username
- if you're lucky, the jar will start, but before the resources are loaded, cleanup will remove the jar, causing the resource load to fail
- if you manage to trigger this, and still send password and receive response, before the connection is broken, you will actually receive the flag

We know that there were teams who managed to trigger this race condition! :)