From JVM to EVM, Comms and Diffs
After graduating I worked for a company that manufactured Java cards (smart cards).Still, I remember the hundreds of Java bytecodes.10 years later, now I am developing Ethereum smart contracts.As such, I am feeling catharsis with how similar those are.Shortly, look at the commonalities and differences. Java carddeveloped by Java programming language,compiled to Java bytecodes,run on Java virtual machine,executed on a single computer. Smart Contractdeveloped by Solidity/Vyper/YUL programming language,compiled to EVM bytecodes,run on Ethereum virtual machine,executed on an infinite number of computers in the world. There are more in deep such as Garbage Collector, Object Ref and etc.But it’s quite enough to understand the basics.I am really enjoying developing smart contracts, and I am passionate about solving security problems.
Read More ›
Practical Solidity Experiment #21 (Ethernaut – DoubleEntryPoint)
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 ›
Practical Solidity Experiment #20
Do you need to zero-initialize every element when you allocate a new memory array in Solidity? They are saying all differently. YES – The memory may or may not be zeroed out. Because of this, one should not expect the free memory to point to zeroed out memory. NO – As all variables in Solidity, the elements of newly allocated arrays are always initialized with the default value. These two answers are written on Solidity official doc. Much confused! And as always, I decided to make an experiment to give myself a clear answer. It passes without an exception.As you see, it’s redundant to initialize the newly created array. – Tonyhttps://github.com/maAPPsDEV
Read More ›
This year 2021, the last Ethernaut Solidity game – Motorbike
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 ›
PuzzleWallet
One of the biggest advantages of Ethereum is that every transaction of moving funds, every contract deployed, and every transaction made to a contract is immutable on a public ledger we call the blockchain. There is no way to hide or amend any transactions ever made. The huge benefit is that any node on the Ethereum network can verify the validity and state of every transaction making Ethereum a very robust decentralized system. But the biggest disadvantage is that you cannot change the source code of your smart contract after it’s been deployed. Developers working on centralized applications (like Facebook, or Airbnb) are used to frequent updates in order to fix bugs or introduce new features. This is impossible to do on Ethereum with traditional patterns. The alternative is Proxy. Every Proxy pattern is based on delegatecall which is low-level functionality. delegatecall basically says that I’m a contract and I’m allowing (delegating) you to do whatever you want to my storage. delegatecall is a security risk for the sending contract which needs to trust that the receiving contract will treat the storage well. PuzzleWallet game explains about Proxy pattern and the vulnerabilities of delegatecall.If you solved it without searching online, […]
Read More ›
Destroy DEX
What is the most important issue with AMM-based DEX?Liquidity! Everyone knows.But do you know what happens if there isn’t enough liquidity in the pool?Swap prices can be easily manipulated and DEX can be destroyed.Yes, you’ve probably heard it a lot.But, but, have you ever destroyed a DEX for real? Basically, DEX reports a price based on liquidity, and a user can use this to flip back and forth and eventually drain the DEX in theory. All right. I will provide a DEX. Play with it. https://github.com/maAPPsDEV/dex-attack The goal of the game is for you to hack the basic DEX contract and steal the funds by price manipulation.Note how many swaps are needed in order to destroy a DEX that has 10 times more liquidity than you got.
Read More ›
Denial Of Service – Smart Contract
DOS – please do not remember Microsoft Disk Operating System ?. I am gonna talk about Denial Of Service on Ethereum. I thought always that a hacker was the most intelligent human.Whenever there was DOS hacking news, I couldn’t imagine how smart the hacker was. But now, I changed my mind, because now either I can do DOS with so ease.(Honestly, overkilled! ?) With “Denial” game, I am gonna show you how to make a contract to deny the services.If you are a protocol operator, you should consider ETH transfer or low-level call in security mind.Also, you can understand the difference between assert and require, especially in solc v0.8.0. https://github.com/maAPPsDEV/denial-attack
Read More ›
Bytecode, Assembly – Magic Number
The sequence of numbers below is a compiled smart contract that returns always a constant number. 600a600c600039600a6000f3604260805260206080f3 These numbers are not Solidity nor inline assembly.This smart contract has a thousand interfaces in theory. How could it be so short though? If you are an assembly engineer, you might understand.You can make a smart contract with just numbers. Solidity, Viper are just tools to make it easy. Today’s game is Magic Number. https://github.com/maAPPsDEV/magic-number-attack You will learn how to build and deploy a smart contract without Solidity or Viper.Also, you will learn about the difference in how the compiler generates bytecodes in reality and in theory. I am an assembly engineer, I have been doing this for more than 10 years.Recently you might find a new raising blockchain that uses an assembly-like language to make smart contracts – Algorand.If you’d like to learn Algorand TEAL (Transaction Execution Approval Language), contact me.
Read More ›
Solidity Library
It’s a piece of cake to replace the owner of an external contract with yourself if the contract is enough vulnerable.You should use libraries in a deep security consideration, or you will lose your ownership, which means you may lose your money.The usage of libraries is always vulnerable, because it uses delegatecall in low level. Let’s see Preservation game.This contract utilizes a library to store two different times for two different timezones. The constructor creates two instances of the library for each time to be stored. The goal of this game is for you to claim ownership of the instance you are given. https://github.com/maAPPsDEV/preservation-attack
Read More ›
