OrderBook

Description:

The OrderBook contract uses abi.encodePacked(...) to concatenate multiple dynamic values into a single string (e.g., inside getOrderDetailsString). While not currently hashed, if this packed encoding were ever passed to a keccak256 hash (e.g., for generating unique IDs or keys in mappings), it would become vulnerable to hash collisions due to Solidity’s non-standard packed mode.

When dynamic types (like string or bytes) are used in abi.encodePacked, Solidity concatenates them without length-prefix padding, which allows different sets of inputs to result in the same hash.

Impact:

If the packed-encoded string is ever hashed (e.g., keccak256(abi.encodePacked(...))) and used for:

…then it may allow collision-based overwriting or order hijacking, resulting in order spoofing, loss of funds, or incorrect attribution

Proof of Concept:

Recommended Mitigation:

Avoid using abi.encodePacked(...) with multiple dynamic types if the result is passed into keccak256 or used for uniqueness/sensitive logic.

1. Use abi.encode(...) instead — it includes padding and avoids ambiguity.

2. use bytes.concat(...) if working purely with bytes or string.

3. If you're only converting to a string for human display (e.g., getOrderDetailsString()), abi.encodePacked(...) is fine — but document clearly that it must never be reused in hash-based logic.