here my overall thoughts about this ctf. On difficulty alone, I'd weight it around 40-45, as they have some decently hard revs and pwns (though I heard the crypto was kinda weak)... with that being said, I have a few nitpicks, and if there were to be a future iteration of this ctf (just to reiterate, I think challenges were okay difficulty and weren't guessy/bad, my issue really I guess is with the overall execution rather than the concepts themselves):

- infra was unstable at the beginning, (ctfd tends to be super laggy if you don't load balance it correctly when everyone starts pinging the server at the beginning of a ctf)
- with ultrushawasm rev, the concept was interesting, tho the overall execution was poor. our team didn't personally solve it, so I can't be entirely sure of it, but imo searching though tons of rust library code compiled to wasm for some backdoor really wasn't a super great use of time to be spending. It honestly also seems like a low-effort type challenge (as I suspect the author probably wrote maybe a few lines of rust and maybe added some magic backdoor, and then called it a rev challenge), and the compiler does most of the work for you.
- pwnbox was interesting, but might've benefited from some message saying that vdso isn't a standard from one of the more common ubuntu distros, if not provided outright, especially since it seems pretty critical for this challenge. I can see part of the intended solution was to leak vdso, but our team ended up spending quite a bit of time before then trying to test every single vdso in common ubuntu 18.04/20.04/etc...
- generally I don't like challenges that take large random oss projects and make a few patches/changes and call that a challenge, unless that is something well-known/popular/ubiqitous (i.e. linux kernel/ browsers/etc...) since it also requires the player to have a prequisite of understanding how the project(s) mesh together, before even starting to do some pwning (i.e. flagtrust, sqg). flagtrust is probably the bigger offender here with having a couple of libraries in golang compiled to wasm (one of them I think has some specs for some blockchain-like vm), that is run by some lesser known wasm interpreter of some sort.
- this ctf is also only 24hrs long, having plenty of hard and "long"-going challenges, and therefore, likely that there are many challenges unsolved. I guess if it were a 48hr, it would probably give most teams at least some time to be able to solve some of the harder challenges, but that would also require maybe adding a few more challenges in the various categories.

Anyways the challenges here are still nice, considering the ton of other ctfs out there with a ton of easy/shoddy/guessy challenges, where many teams end up competing for how quickly they can solve every single guessy challenge. I just think some of the challenges here could have better execution, but this is the first ctf by LINE so I guess a good first one.

This is one of the CTF challenge makers. Since a lot of time has passed, I think it's good to answer the questions I've created.
I've never seen players easily. Players are hackers who are better than me, and I always did my best to produce the challenge with respect for them.

- ultrushawasm rev was not a low-effort type challenge, It took the most time to make. I don't remember how much i spent because it's been a while, maybe it took about two weeks. I modified rust-wasm-toolchain to inject a tiny backdoor code. To me, Custom rust-toolchain build was super slow and so many crazy errors. verification was also crazy to prevent unintended solution. web assembly's memory operation is relatively simple compared to a desktop, it should have arithmetic operations to conceal secret constant values and also had to hide values that were too easily exposed to the stack.
- pwnbox, vdso of pwnbox is not a custom version. I just used official debian image as an operating system. Worried that most ubuntu-based players would suffer, we put in a clearly visible memory dump bug. The reason I chose debian is that my development environment was just debian, and the expoit was also done in the development environment. I tried to port to Ubuntu, but I couldn't exploit until the CTF was held.
- The wasm OSS used in flagtrust is a wasmer (https://github.com/wasmerio/wasmer), an engine that connects to the cosmwasm addon in the cosmos blockchain. Cosmwasm executes wasm smart contract on the blockchain, imitating a practical situation that can cause enormous financial damage if there is a bug. It was a time when the blockchain was so popular (and still now), and I was also interested in web assembly, so I put it as a theme challenge. It is also the time when Cosmos-based LINE LINK chain (CBDC) was unveiled. And the compile of customized oss was also crazy.
- baby chrome, which many people have solved and criticized, was intended to make it fun to warm up at the beginning of the CTF, and i chose the right one from the actual bugs at crbug.com to make it easier to find the regression js testcase.
- sakura, There were many unintended solutions. It was definitely my mistake.

I was not the main CTF operator, and I was a person who helped with the challenge production, but i am leaving a comment because I am worried that there may be a misunderstanding that LINE CTF problem makers are trying to produce the problem with little effort.
All of my colleagues respect the players and were afraid that the challenges would be solved too quickly. we didn't underestimate players at all.
And personally, 24 hours was a little short for me, too.

Perhaps in the next CTF, other cool people in LINE will create challenges. LINE has many cool hackers.
FYI, Security Engineer Job applications are also welcome at any time.

Once again, thank you very much for playing, and I always respect you, those who love full-time hacking.
Have fun!