Viable input forms in Cops and Robbers challenges

Question

So, recently in the Hello World CnR challenge I've come across this crack to my submission.

I don't think it's ever clearly defined before in any CnRs what exactly is allowed as an input and what is not.

So, what exactly constitutes a valid input to a function? What is allowed and what is not allowed?

Answer 1

Input should not rely on existing custom state

The value given as input should not rely on any other state - global variables, environment variables, etc. - created by the robber. It may set this state itself, but cannot rely on them being set prior to the input being given to the function.

The following JavaScript is valid, since the input does not rely on any external state - although a global variable is created, it is not important for the input to work (only for creating the input);

obj = {a: 1};
f(Object.freeze(obj));

The following JavaScript is invalid, since the input relies on non-input state (namely that there exists a global function called g):

g = () => "Hello, World!";
f("g"); // f = string => eval(string)()

The following JavaScript is valid, since the input creates the state itself (it creates a global variable called g)

input = "g=()=>'Hello, World!',g";
f(input); // f = string => eval(string)()

The following JavaScript is not valid, since it relies on non-input state (namely overwriting a variable used by the cop)

v = () => true;
f([]); // v = [].every; f = array => v.call(array, v=>v)

Answer 2

Robber answer should not completely modify the language's behaviour such that passing any solution is trivial

...Which is called a hack, not a crack. It's a standard loophole.

e.g Overriding equality and comparison operators for everything in the language (Ruby, and C++, I'm looking at you).

Answer 3

Robber inputs should be standalone and performs all the necessary tasks (including global assignments) at least after being passed into the function

So, for example, given this cop:

from random import uniform
def f(a):
    return a == uniform(0,float('+inf'))

This Python class which is equal to anything is a valid input because it stands up to itself:

class Wildcard(object):
    def __eq__(self, other):
        return True
w = Wildcard()
print(f(w))

This JS snippet, however, is not:

Cop: 
f=()=>1==2

Robber:
f=()=>2==2,f('foobar')

or:

Cop:
g=()=>false,f=()=>g()

Robber:
f((g=()=>true))

Because they have effects that occur before the cop function is even evaluated.

If they are performed after the control flow is passed inside the cop function, then it is okay. e.g:

Cop:
f=e=>{i=NaN;while(e!=i);return}

Robber:
f({valueOf:()=>(i=0,0)})

---

Strictly speaking, every action must be performed at least after the cop function is evaluated. So if the Robber's proposed solution is:

var i=0;
var e={toString:()=>['a','b','c','true'][i++]}

He should transform it so that everything is sit inside a variable:

var e={i:0, toString:()=>['a','b','c','true'][e.i++]}

which would allow one to call the cop solution directly like f(e).

Answer 4

Input should match what the cop function actually receives

or

Input is not a statement

A typical way of stretching the definition of input too far is when said "input" is a statement, and only the evaluated result of it is actually passed into the cop function.

For example:

cop:
f=_=>[].some(e=>e)

robber:
f(Array.prototype.some=_=>true)

This proposed input is not an input because while the robber proposed Array.prototype.some=_=>true, what the function actually receives is Array.prototype.some (or _=>true), which does not match what the robber has stated.

Additionally, passing in either of the two actual input above (that the cop function actually receives) doesn't work:

f(Array.prototype.some) // -> false
f(_=>true) // -> false

Which means this robber crack is not valid.

Answer 5

Crack can be object, modifed before sending

JS example

Cop's sumbission

var crackme = x => { x["foo"] = ""; if(x["foo"] == "bar"){ return "OK"; } }

Robber's crack

var key = {"foo":"bar"};
Object.freeze(key);
crackme(key);

Answer 6

Microcontroller input can be series of I/O signals

With timings if needed.

Also it can use UART, USB or another same periphericals

Answer 7

Input can be interactive

Howto

We need to make a biderectional pipe

mkfifo fifo0 fifo1
prog1 > fifo0 < fifo1 &
prog2 < fifo0 > fifo1

Minuses

• tio doesn't support it now

Pluses

• Way to new extraordinary cracks
• We can patch tio to add this support

Answer 8

If the cop's code has a "natural way" of getting input, that's the only thing allowed to use by default

Consider this cop. It shows TeX code that reads input from stdin using \read16to. This is a clear indicator that your input should indeed come from stdin.

Now, TeX allows to call a program from within a code snippet you provide at the commandline, and I used this in my suggested crack to first redefine one of TeX's macros before the cop code is executed. According to the general rules in the challenge, input may come from command line arguments as well. But it conflicts with what I said above. Therefore, I suggest the following guidelines:

• Input should use the "natural way" that's obviously provided by cop's code if not explicitly stated otherwise in cop's description.
• Other forms of input are valid only if you can prove they are strictly necessary for a crack.
• To avoid any ambiguity, a cop submission should explicitly state which method of input is acceptable.

To clarify: I'm unsure whether my suggested crack would be valid according to these guidelines. I don't see any other way of cracking the cop in question, but that doesn't mean there is none. The cop author claims it's possible using only stdin. I would require such a solution to work with any implementation of TeX, so if it relies on some undocumented behavior of some TeX implementations, I'd consider it "impossible" (because the cop doesn't mention which TeX implementation to use).

Therefore I would now wait and see, I'm just posting this answer as suggested guidelines and a base for discussion.

Answer 9

Input Should Fit Inside the Function Call

Simply put, if your language allows you to place it in between the parentheses (or other language construct), it is allowed. If you cannot place it in between the parentheses (or other), it is not allowed.

If you cannot pass it to the function as is, you can't pass it. If, for example, your language doesn't support anonymous functions or anonymous objects, then unless the cop explicitly states that you have to construct the input outside the function call, you can't.