Appearance
S2C5: Assembly Memory
1. Problem
The contract uses Yul inline assembly for memory operations and numeric calculations. It is necessary to understand and manipulate these low-level operations to satisfy the mintFlag conditions.
2. Cause
The contract uses non-standard numeric handling in Yul assembly (such as special bit shifting operations and memory layout manipulation), causing Solidity-level security assumptions to break down.
3. Solution
Analyze the Yul assembly code to understand which storage slots and memory regions it modifies. Satisfy the conditions through precise call parameters.
4. Pitfalls Encountered
Yul Assembly Semantics: The semantics of operations like shl, shr, and mstore in assembly differ from Solidity high-level code (e.g., the bytes4 type is left-aligned in assembly).
5. Pitfall Causes
In Solidity, bytes4 is right-aligned (occupying the lower 4 bytes), but in Yul assembly, bytes4 is left-aligned in a 32-byte stack slot (occupying the upper 4 bytes). Using shl(224, bytes4) shifts the data to the wrong position.
6. How to Resolve
At the Solidity level, first convert bytes4 to uint256, then perform the bit shift. Avoid directly operating on bytes types in assembly:
solidity
bytes4 selector = bytes4(keccak256("someFunction()"));
uint256 shifted = uint256(uint32(selector)) << 224; // correct
7. Key Technical Points
| Point | Description |
|---|---|
| bytes4 alignment in Yul assembly | bytes4 is left-aligned in assembly stack slots, unlike Solidity's right-alignment |
| Data type conversion | Data type encoding between Solidity and Yul may differ |
| Memory operations | Yul's mstore and mload directly operate on raw memory |