The game is trivially broken.

[Rupsbant]

Since the hash is predictable and the search space is very small the current arena is trivially broken. The Defender needs to survive for at least 6 instructions. But the Attacker has full control of the seed and can thus predict where the PC of the defender points at the start of the game.

Even if the Defender reacts to the changing hash it is vulnerable with a birthday paradox attack with a complexity of 2^8. The Attacker needs 4 or more instructions to place an irq. The Defender needs to react to all since any of them can be constant. It stays vulnerable to the birthday paradox.

Possible fixes:

1. give the defender access to the source code of the attacker during setup. But it probably won't help that much. Setup time will be too short to analyse the full source code.
2. replace the transaction hash by another deterministic unpredictable value: for example: append sha256(sha256(secret||blockHash)) to each block. the seed of the next round is sha256(secret||blockHash). It won't be possible to relinquish control over the hackcha.in server. Going back to a proof of work scheme returns control of the secret to the Attacker. Which returns the birthday paradox.

Not fixes:

1. Make the attacker space writable. The first operation would be a jump between 0 and 63 forward.

Source code of trivial program:

• lui r1 0x1000
• lw r2 r1 xx
• lw r3, r1, yy
• sw r2 r3 0
• xx:
• data defendAddress
• yy:
• data 0xe001

[indutny]

@Rupsbant thank you so much for this analysis!

I agree that the hash should be replaced by some pseudo-random value, possibly an hmac using server's secret as you suggested.

The attacker script's memory is vulnerable in the most recent version of hackcha.in