Day 75 of #100DaysOfDeFI π today 3/4 of the challenge is done! π Also today I finish exploring Solidity vulnerabilities with learning about Denial of service (DoS) attacks π¦ΉπΌββοΈ #womenwhocode#100DaysOfCode
How it works π§΅
1/ There are many ways to attack a smart contract and at some point create a DoSβ‘
2/ Denial of Service attack paralyzes a smart contract and makes it temporarily unusable π
3/ Letβs see an example of a simple game EtherKing that can be broken by a DoS. A goal of the game is to send more Ether to the contract than the previous king; then the former king gets their funds back πΈ
4/ Now define the Attack smart contract π¦Ήπ½ββοΈ The contract doesnβt have a fallback function, so any attempt to send the Ether back will fail πΈ
5/ Letβs try it out! Deploy KingOfEther then set value to 1 Ether and click βclaimThroneβ π We can see that the king is the account address we used to claim the throne π
6/ Now change the account address and deploy the Attack contract πΊ
7/ Set the value to 2 Ether and claim the throne again! Now the balance is 2 Ether king is the Attack πΊ
8/ Finally try to beat the Attack and get the crown back. Change the account again and set value to more than 2 Ether. Click claim the throne function and weβll get an error π
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
Day 74 of #100DaysOfDeFI π Today I learned about Delegate Call vulnerability in #Solidity π¦ΉπΌββοΈ When using delegatecall opcode one should be careful because wrong usage will lead to unexpected results β οΈ #womenwhocode#100DaysOfCode
How it works π§΅
1/ What delegatecall is? When contract A uses delegatecall to call contract B it means that the contract B code will be executed inside context of the contract A: storage, msg.sender, msg.value, msg.data, etc will be the Aβs context.
2/ Storage layout must be the same for contract A and contract B β it means both contracts should declare the same state variables in the same order πΎ
Day 73 of #100DaysOfDeFI π Learned about Self Destruct vulnerability in #Solidity π¦ΉπΌββοΈ Selfdestruct deletes the contract from the blockchain and and sends all Ether to a designated address πΈ In some scenarios it can lead to unexpected problems β #100DaysOfCode
How it works π§΅
1/ Letβs see how it works with an example of a simple game π² Players send to the contract 1 token πͺ the one who deposits the fifth token wins π
Game code π
1/ An overflow in Solidity occurs when a number is incremented beyond its maximum value. For example, if we have a uint8 with a value of 255 and increment it by 1, it will βresetβ and set a value to 0. Remember, the maximum value for uint8 is 255β
2/ Similar thing happens when we decrease a value beyond its minimal level. Taking the same example, if a uint8 is set to 0 and we decrease it by 1, it will set to 255, since 0 is the minimal value of uint8β
Day 71 of #100DaysOfDeFI π looked at Re-Entrancy vulnerabilityπ¦Ήπ» It is one of the most destructive attacks in the #Solidity smart contracts πΈ The untrusted contract that exploits the vulnerability is able to drain all user's funds π° #100DaysOfCode
How it works π§΅
1/ To make it happen, there should be 2 contracts: a vulnerable contract and an attackerβs contract πΊ
2/ The attacker should deposit some funds into the vulnerable contract π°
1/ The Factory will include:
π· createPair - create a Liquidity Pool;
π· adjustAmount - adjust a number of tokens using a formula;
π· getReserves - a getter function;
π· addLiquidity - add liquidity to the LP;
π· removeLiquidity - withdraw liquidity;
π· trade1for2 - swap tokens.
1/ In this example of the Pair smart contract Iβll implement the following methods:
πΆ getReservers - get quantities of each token;
πΆ updateReserves - update the tokensβ quantities;
πΆ swap - exchange two tokens;
πΆ withdrawTokens - send the tokens back to the LP.