Breaking Down the Vulnerability in All Safe Contracts Using Common Sense Language: (More Plain English; Part Three/Four)

The whole point of prefixing 0x19 + 0x01 + domain separator to the hash of actual transaction contents/struct (EIP-712) when creating an EIP-712 compliant hash for signature validation isn't just to promote cryptographic integrity by imbuing replay protection. This standard was also created to (a) provide determinism in EOA signature creation & validation for transactions, (b) provide structure and specificity to transaction data in a way that allows 3rd-party providers (i.e., Metamask) to programmatically decode EIP-712 compliant transaction data sent to end-users for signature request.

Finally, and perhaps most important, the EIP-712 signature standard was/is meant to be an evolution of its predecessor, the EIP-191 standard,0 by also (c) ensuring that once EIP-712 compliant data is signed that it can't / won't be re-used or even used at all in a different context (i.e., as a personal sign message versus a transaction). What that means, in effect, is that it should not be possible to repurpose data that was processed, encoded as a transaction and then keccak256 hashed (EIP-712) as a personal sign message EVER (which is exactly what every version of Safe's contracts do).

In the Bybit hack, the calldata of the hacked TX clearly shows data corresponding with a typed transaction - not a personal signed message. So why is the hash of the transaction mutated by nesting the EIP-712 signed hash within the EIP-191 standard?? Resulting in the submitted signatures being validated against a hash that reflects something vastly different than what the signer actually signed originally or what we can see at all on the blockchain?

Breaking Down How This Took Place in the Bybit Hack

1. The actual hash that we get from hashing the contents of that hacked transaction is = 0xea68fc75e93bf7286b1257680ca8e2033bfadd8e1cb8a23f3ca18f1031ecf1e0. This is given the value of safeTxHash in the contract.

2. That gets prefixed with a 0x19 byte & 0x01 byte. Then appended to that is the domain separator. This value is saved in the storage of the proxy contract (not the logic) to ensure transactions signed that are targeted for this proxy (as a recipient) can only be used on this proxy (and not the 10+ others that this same group of owners has deployed on the same blockchain; no for real). For the hack transaction, that value was 0x1901b3ded2bdbff5db1a87f6d551fa256e9f2bd6517a3bb84f4c2ea863fb3a559622ea68fc75e93bf7286b1257680ca8e2033bfadd8e1cb8a23f3ca18f1031ecf1e0 (result of the encodeTransactionData function).

3. In the execTransaction function (this is the one responsible for all of the signature validation logic), we see that this long 66 byte value (`0x1901b3ded...`), which is now the EIP-712 encoded transaction (hence the name of the function: encodeTransactiondata), then get properly hashed in the statement:

solidity 
bytes memory txHashData = encodeTransactionData(
                to, value, data, operation, // Transaction info
                safeTxGas, baseGas, gasPrice, gasToken, refundReceiver, // Payment info
                nonce
            );