You are obviously a very intelligent person and an extremely talented coder, adriaanbaelus. I'm sure this kata is absolute genuis and I appreciate that it could be fun and a good learning experience to figure out how to "bypass a mechanism that you have no control over". I applaud that idea.

However, I think that for any coding challenge, we at least need some awareness of what the problem is we are trying to work on, otherwise what's the point of coding? Why would I approach a problem if I'm not even aware that it exists?

I don't want to join the list of people here that say this kata should be removed, because I suspect those people, including myself, simply don't appreciate or understand the kata. But I do think there needs to be some thread of explicit instruction just to make the user aware of the problem to be solved. Perhaps a couple of prerequisite katas with proper instruction to introduce the idea?

I ended up liking this kata. but it took too long to figure out what it was about. I had to read this comment to finally understand what the kata was about. At first I thought it was just a nonesense kata and was going to skip it. You should add that bit about "[figuring] out a way to bypass a mechanism that you have no control over", or something similar, to the description. That would allow people coming to it for the first time to actually give it a chance.

Inspecting for any objects/properties under 'this' produce no "BlackKnight". This is a terrible set-up for a kata that doesn't work for some users.

I can +1 the fact that it wasn't clear you could adjust the difficulty.

This happens a lot. Need to figure out how to make the UX better.

I almost mentioned that... You need to click the '<- Reply' link just under the comment. (Right next to the 'Spoiler' flag link.) The text box at the bottom of the page is for new comments to the overall thread.

Bloos experimented here with the user-adjustable difficulty setting as a way of trying to tie together multiple katas that would all be very similar.

Take a look at some of the other solutions. Notice how each have specified a difficulty? Try solving this kata again with difficulty = 'impossible'; and you will see that the puzzle changes when you specify a different difficulty. The reason for doing this was to help you learn in incremental steps. Each difficulty setting could have been a separate kata, but that would disrupt the educational experience.

My solution passed all of the tests in the Kata, and is what I submitted. The instructions are incomplete, like I've already said in my first comment. Are you saying that is the whole point of your Kata? To be incomplete?

Was it your intention for it to be possible to pass in any way whatsoever?

This kata is a wonderful example of how katas should be made.

• I love how you tie into the difficulty setter to initialize the system.
• Having the self-adjustable difficulty is an interesting approach to the problem of helping students self-guide their instruction. My own experience working on this kata was to solve each difficulty one by one. My first solution got me through 'medium'. A few quick tweaks got me through 'harder'. Then I spent about an hour mucking around on 'impossible' before I gave up and submitted my 'harder' solution so i could see if anyone had solved the 'impossible' level. Was not disappointed! I have learned something new now and am excited about that.
• The bits of code that I could see of your initialization showed that you have constructed this kata thoughtfully and cleanly. I love it!
• Having the variable difficulty rating makes rating the kyu not so straightforward. I think the rating should align with the relative difficulty associated with the easiest possible solution. In the future I hope to see features for varying levels of honor awarded for 'extra credit' when completing a kata. That would work perfectly in addressing this kata's difficulty rating and honor awarded.

This was a ton of fun. I really hope someone cracks this nut.

Yeah I would just leave this kata up. It will probably exist in beta forever but its a fun way to try to hack codewars. It would be very cool to see more kata in the spirit of this one (and Hard Time Bomb).

To answer your questions. I'm not actually freezing the entire global scope (as that would lock down everything, not just Test). Using Object.defineProperty actually seems to be locking it in place pretty securely. However the issue is that when people reference the Test object they are using Test instead of this.Test, which means all someone needs to do is create a local variable called Test which will shortcut the scope chain. I had tried to fix that issue by defining var Test = this.Test right before the fixture block. However constablebrew hacked into Math.random so that when it was called it would reset the global variable back to something else. My fix for this was then to wrap the fixture block within its own closure so that its local Test variable couldn't be tampered with.

I am no longer using __Test__asdifuh since trying to obfuscate the secret is no longer needed (I can just reference this.Test).

I wonder how secure the Ruby implementation is...

Ha. Well you put up one hell of a fight - but somehow I have a feeling this victory won't last very long.

This... this is what defeat feels like... JHoffer, I think you have won for now.

My next approach is to try and inject code from the sandbox into the noderunner. So far this is my best effort:

var obj = {"toJSON":function(){
  return {"victory":"sweet","toString":"success"};
}},
x = JSON.stringify(obj);
print(x);

This throws an error "The property 'toString' is not a function". This is being thrown by the code in shovel.js when it attempts to parse the string output for the console:

71          case 'stdout':
72            var v = JSON.parse(value)[0]
73            console.push(v ? v.toString() : v);
74            break;

JSON sanitizes functions, so I don't think there is much more I can do along this path, but it is still interesting. If anyone else gets inspired by this, please make a go of it!

One additional potential place to attack could be in passing the object with a "toJSON" function, which may then have access outside of the safe context since it is evaluated in the send() function after it is passed the msg parameter from the print() function: (Again, in shovel.js)

41    var send = function send(event) {
42      "use strict";
43      //
44      // All comm must be serialized properly to avoid attacks, JSON or XJSON
45      //
46      comm.send(event, JSON.stringify([].slice.call(arguments,1)));
47    }
48    global.print = function(msg){
49        send('stdout', msg)
50    }

I haven't had any success yet in working this route:

var obj = {"toJSON":function(){
  var out = [];
  (1,eval)('var myGlobal = this;'); // Still can't break out of the context :-(
  for(var p in myGlobal){out.push(p);}
  return out.join(', ');
}};
print(obj);

That's actually a good idea, but implementing it would break all the current solutions. Hmm, I'll have to think about it little before make a change like that.