Modify state inside of hooks

[Bruisr]

It would be very useful to be able to modify the state of an operation inside of a hook. E.g.

Wasabi.analysis = {
    binary(location, op, first, second, r) {
        // If result for i32.eq operations in function 47 are 0, change it to 1 
        // then continue execution with the new result.
        if (op == 'i32.eq' && location['func'] == 47 && result == 0) {
            result = 1;
            console.log(location, op, "result =", result);
        }
    }
};

[danleh]

Good point, this is definitely useful. Out of interest: What would be your application? (E.g., something along the lines of fault injection by randomly changing instruction results?)

Unfortunately, I think we won't support this in the near future (say, 6 months) because of some technical challenges/open questions:

• How is the modified instruction result handed back? The most natural API for the JavaScript analysis hooks, I think, is just as return value. Another option is what your example shows, i.e., assigning to a result variable. (Assigning to the result parameter of the analysis function won't work for numbers, because of call-by-value, though.)

• Since JavaScript has no native support for i64 values (yet), they are currently passed as a tuple of (i32, i32) from Wasm -> JS. We would have to do the same for results then too (e.g. for i64.add).

• The problem with the expansion of i64 -> (i32, i32) is that the analysis functions have a regular Wasm function type, and those can have only a single return value (unlike parameter lists, which can have arbitrary length). In order to fix this, we would either have to wait for the multi-value extension to Wasm (🛤 Multi-value WebAssembly/design#1146) or emulate multiple return values with mutable globals (similar to https://blog.scottlogic.com/2018/05/29/transpiling-webassembly.html).

• Probably only a small subset of instruction results need to be modified, so I'd like to avoid paying for this for every analysis. Maybe we need different flavors of hooks, e.g. binary vs. binary_overwrite?

[ctfhacker]

One application of this would be to force particular paths in a debugging session. If we happen to know some condition needs to be set, but don't quite understand why it needs to be set, having the ability to modify the state would be immensely useful.

[danleh]

If we happen to know some condition needs to be set, but don't quite understand why it needs to be set, having the ability to modify the state would be immensely useful.

I.e., flipping conditions in order to explore previously unreached paths in a program? If so, that sounds more constrained (and thus doable) then modifying any instruction result. In particular, conditions are always i32s, so the problems with i64 handling do not apply.