# Ethernaut

wooz3k

오랜만에 Ethernaut을 들어가보니 새로운 문제가 나와 후딱 풀고 풀이를 작성한다.이 문제는 switchOn state를 true로 만들면 풀리는 문제이다.turnSwitchOn, turnSwitchOff 2개의 함수가 switchOn state를 변경할 수 있고,

wooz3k

이 문제는 Gatekeeper One, Two 처럼 3개의 modifier를 통과하면 풀리는 문제이다. 접근 방식 문제에 의도를 처음 부터 알려주고 시작하기 때문에 modifier를 하나 씩 분석 해보자.

wooz3k

이 문제는 requestDonation()를 호출하면 10개의 coin을 받는 컨트렉트인데 모든 coin balance를 빼낼 수 있으면 풀리는 문제이다.우리의 목적은 coin의 balance를 전부 빼내는 것이기 때문에 이게 이루어지는 함수를 집중적으로 분석해보자.r

wooz3k

이 문제는 cryptovalut가 DET token을 잃는 취약점을 찾고 취약점을 방지해주는 forta bot을 만들면 풀리는 문제이다.cryptovalut에 token을 빼는 것에 대한 취약점을 찾아야 하기 때문에 관점을 cryptovalut에 DET token을 빼

wooz3k

이 문제는 UUPS proxy 패턴으로 만들어진 컨트렉트이다. UUPS proxy는 logic contract에 upgrade 기능이 구현되어있는 것을 뜻한다. logic contract를 삭제시키면 풀리는 문제이다.proxy contract는 생성자를 호출하지 못한다

wooz3k

이 문제는 Proxy Contract에 admin이 player가 되면 풀리는 문제이다. 이 문제를 풀기 위해서는 Proxy Contract에 대한 개념을 알고 있어야 하는데 간단히 설명하고 넘어가겠다.블록체인 특성상 스마트 컨트렉트를 한번 배포하고 나면 해당 스마트

wooz3k

이 문제는 Dex의 token1과 token2의 모든 balance를 빼내면 풀리는 문제이다.swap API에서 token의 address 검증을 하지 않아 발생한다.악의적인 token을 만들어 Dex가 가지고 있는 token1과 token2를 모두 drain 할 수

wooz3k

이 문제는 ERC20 API와 Dex가 무엇인지에 대해 이해를 할 수 있는 문제이다. 이 문제에서 보여주고자 하는 것은 정상적인 Dex에서 일반적인 경우에 한 쪽 풀이 0이될 경우 문제가 있다는 것을 알려주고자 한다.이 식을 보면 두 토큰을 계속 번갈아가며 swap을

wooz3k

이 문제는 Buyer interface에 맞게 구현된 컨트렉트를 작성하여 buy() 함수를 호출하는데 price에 값을 100보다 작게 만들면 풀리는 문제이다.첫 번째 price() 함수에 리턴은 100보다 커야 한다.두 번째 price() 함수에 리턴은 100보다 작

wooz3k

이 문제는 withdraw() 를 owner 가 호출하였을 때 tx가 실패되면 풀리게되는 문제이다.withdraw() 하는 과정에서 reentry attack이 발생될 수 있다.call() 호출할 때 gas 제한이 없어 전체 gas를 다 사용할 경우 tx가 revert

wooz3k

이 문제는 Ownable 컨트렉트를 상속받는데 Ownable 컨트렉트에 존재하는 owner 변수를 player의 주소로 덮어씌워야 하는 문제이다.상속을 받을 경우 부모 컨트렉트에 존재하는 변수가 storage slot 가장 앞 부터 채워짐.solidity 0.8 이전에

wooz3k

이 문제를 해결하려면 런타임 코드가 opcode 10개 이하로 42를 return 해주는 컨트렉트를 만들어야 한다.그 전에 짚고 넘어가야할 개념이 있는데 바로 배포 코드와 런타임 코드이다. 런타임 코드는 CA에 존재하는 코드이고, 배포 코드는 배포할 때만 사용되고 C

wooz3k

이 문제는 generateToken 함수를 통하여 SimpleToken instance를 생성하는데 주소를 어디에도 저장하지 않고, 해당 instance에 0.001 ether를 보내는데 이 0.001ether를 0으로 만들면 풀리는 문제이다.먼저 이더리움에서는 주소를

wooz3k

이 문제는 을 함부로 사용하면 안되는 것을 알려준다. Delegation 문제에서 설명했듯이 은 호출한 컨트렉트의 storage에 데이터가 작성되는데 이때 변수명으로 판단하여 작성되는 것이 아니라 storage slot으로 접근하여 작성하게 된다. 과 을 살펴

wooz3k

이 문제는 ERC20에 대한 이해를 하고 있냐를 묻는 문제이다. 문제는 openzeppelin에 ERC20을 상속받은 컨트렉트에서 transfer를 lockTokens라는 modifier로 override를 하여 transfer를 오랜기간 하지못하게 막아놨는데 play

wooz3k

이 문제는 개인적으로 Gatekeeper One 보다 쉬운 문제라고 생각한다.gateOne()은 Gatekeeper One과 똑같은 조건이다. 페이로드 컨트렉트를 만들자.gateTwo()는 assembly가 있어서 어렵게 보일 수 있는데 extcodesize(calle

wooz3k

이 문제는 3개의 modifier가 정의되어있는데 문제를 해결하려면 3개의 modifier가 걸려있는 enter(bytes8) 함수를 호출하여 entrant에 풀이자의 지갑 주소를 등록하면 풀리는 문제이다. gateOne()은 msg.sender가 tx.origin이

wooz3k

이 문제는 unlock(bytes16) 을 호출하여 require(\_key == bytes16(data\[2]))를 통과하고 locked=false 를 실행시키면 된다. 그러기 위해서는 private로 저장된 data를 알아내야 한다.private로 선언된 변수더라도

wooz3k

이 문제는 Building interface에 맞게 구현된 Building 컨트렉트에서 goTo(uint256) 함수를 호출하여 top이 true가 되도록 만들어야하는 문제이다.top이 true가 되려면 if (! building.isLastFloor(\_floor))

wooz3k

이 문제는 문제 이름에서 알아차릴 수 있는데 reentrancy attack의 취약하다. 이 문제에 취약점은 에서 확인할 수 있는데 king문제에서 처럼 'Checks Effects Interactions' 패턴을 사용하지 않아 생기는 문제이다. 체크하는 로직이