Do you know the offset of a parameter in the external function’s calldata area? In order to extract a parameter from the calldata area directly, you have to know the offset. It requires you to know about the layout of calldata.Calldata is a non-modifiable, non-persistent area where function arguments are stored, and behaves mostly like memory.In other words, ABI encoded function data exists in there.What is the rule to encode though?Contract ABI stands for: The Contract Application Binary Interface (ABI) is the standard way to interact with contracts in the Ethereum ecosystem, both from outside the blockchain and for contract-to-contract interaction. Data is encoded according to its type, as described in this specification. The encoding is not self describing and thus requires a schema in order to decode. We assume the interface functions of a contract are strongly typed, known at compilation time and static. We assume that all contracts will have the interface definitions of any contracts they call available at compile-time. You can understand the encoding rule of function parameters and use this knowledge to get the correct data offset you want to get in calldata.Here is a good Solidity wargame inspired by Ethernaut.Through that, you can practice calldata […]
Read More ›
Ethernaut Solidity wargame Level 25 Solution – “Motorbike” This is the latest updated game probably in this year. What will you learn?✔️ delegatecall✔️ storage layout✔️ proxy patternand✔️ all vulnerabilities for those. https://github.com/maAPPsDEV/motorbike-attack I will look forward to challenging another next level of games.And this is the last GitHub solution this year.See you next year!
Read More ›
When I first saw the modifier in the picture below, I was in despair.“Ethereum is not something I can do.”If you know how to solve this problem, you are already an expert. I was able to solve this problem only after reading the Ethereum yellow paper.By solving this problem, you will learn about the contract creation process in Ethereum. Sometimes even gates that appear to be highly secure can be passed with the right tools. I share my second “Gatekeeper” game solution. https://github.com/maAPPsDEV/gatekeeper-attack-two
Read More ›
Function modifier is a good gatekeeper that can protect your function from unexpected behavior.But you should know a few things about function modifiers. Function modifiers can be inefficient.When you add a function modifier, the code of that function is picked up and put in the function modifier in place of the _ symbol. This can also be understood as ‘The function modifiers are inlined”. In normal programming languages, inlining small code is more efficient without any real drawback but Solidity is no ordinary language. In Solidity, the maximum size of a contract is restricted to 24 KB by EIP 170. If the same code is inlined multiple times, it adds up in size and that size limit can be hit easily. Internal functions, on the other hand, are not inlined but called as separate functions. This means they are very slightly more expensive in run time but save a lot of redundant bytecode in deployment. Internal functions can also help avoid the dreaded “Stack too deep Error” as variables created in an internal function don’t share the same restricted stack with the original function, but the variables created in modifiers share the same stack limit. I managed to reduce the […]
Read More ›
