Nexus.sol is not compatible with eip-712
The below snippets are how the signatures are created/expected, see https://github.com/Cyfrin/2024-07-biconomy/blob/9590f25cd63f7ad2c54feb618036984774f3879d/contracts/Nexus.sol#L327-L341
And https://github.com/Cyfrin/2024-07-biconomy/blob/9590f25cd63f7ad2c54feb618036984774f3879d/contracts/Nexus.sol#L367-L370
Issue however is that this is not compatible with EIP712, because from EIP712:
The dynamic values bytes and string are encoded as a keccak256 hash of their contents.
However in our case the construction of the signatures are done directly with the hash
instead of first applying a keccak hash to the procedure.
As a result, a signature generated using common EIP712 tools (e.g. using the signTypedData function from ethers.js) would not pass validation .
As hinted under Vulnerability Details, signatures generated using common EIP712 tools (e.g. using the signTypedData function from ethers.js) would not pass validation, which showcases how the current logic is broken.
Manual review
Re-encode the contents before computing the digest.
Invalid, `bytes32` is not a dynamic value as oppose to `bytes`, since it is exactly 32 bytes long, so the encoding is correct, no issues here that is inconsistent with the `encodeData` definition highlighted in EIP712. > The atomic values are encoded as follows: Boolean false and true are encoded as uint256 values 0 and 1 respectively. Addresses are encoded as uint160. Integer values are sign-extended to 256-bit and encoded in big endian order. bytes1 to bytes31 are arrays with a beginning (index 0) and an end (index length - 1), they are zero-padded at the end to bytes32 and encoded in beginning to end order. This corresponds to their encoding in ABI v1 and v2.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.