Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP - Update smart contracts to Solidity 0.5 #123

Closed

Conversation

paulinablaszk
Copy link
Contributor

@paulinablaszk paulinablaszk commented Apr 30, 2019

Issue #117

The goal is to make all smart contracts to compile using Solidity 0.5.0.
Due to a large number of changes, I add this as Work in Progress.

What have been done

  • updated pragma statements
  • added constructors
  • changed zeppelin-solidity to openzeppelin-solidity
  • changed returned statements in createInstance in levels factories (form instance to address(instance)”
  • added address payable
  • added visibility and data location
  • converted values of contract type to addresses before using an address member
  • added empty string as .call() and .delegatecall() arguments
  • changed handling of return statements of .call(), .delegatecall()
  • changed disallowed sha3 to keccak256
  • changed StandardToken to DetailedERC20
  • changed types conversion

Next steps

Make all the contracts compile correctly:
Level factories to do:

  • Fallback

  • King

  • Re-entrancy

  • Denial

  • Update attack contracts

STATUS UPDATE - TESTS

  • Ethernaut
  • Fallback
  • Coin Flip
  • Telephone
  • Token
  • Force
  • Vault
  • King
  • Re-entrance
  • Shop
  • Instance
  • MagicNumber
  • Naught Coin
  • Gatekeeper Two
  • Privacy
  • Preservation
  • Recovery
  • Denial
  • Delegation
  • Gatekeeper One
  • Elevator
  • Fallout

"MUSEUM"?

  • Locked - (memory modifier added to struct inside register function)
  • Alien Codex -(The ABI decoder reverts in the beginning of functions if passed calldata is too short or points out of bounds?)

@@ -1,4 +1,4 @@
pragma solidity ^0.4.18;
pragma solidity ^0.5.0;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this attack still work with 0.5? As I understand the last note here, STATICCALL should prevent it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! Have you tested it?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I just did the 0.4 version and then read the docs...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, thank you! I'll definitely test it

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whilst the Elevator contract compiles, to get the test to pass, need to change the interface to no longer be view due to STATICCALL

function isLastFloor(uint) external returns (bool);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, thank you Andrew!

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This level is solvable on new solidity with a view function:

contract Hogwarts is Building {
        function isLastFloor(uint floor) view public returns (bool) {
                return floor == Elevator(msg.sender).floor();
        }

        function businessAsUsual(address elevator) public {
                Elevator lift = Elevator(elevator);
                lift.goTo(lift.floor() + 1);
        }
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work @NieDzejkob.

I will get updated.

@paulinablaszk
Copy link
Contributor Author

Hi, I am considering necessary changes in Fallback level (and probably it will repeat in others). I need to make the owner address payable and I can see two options:

  • using just address payable owner instead of Ownable.sol
    or
  • casting owner to address payable by using address(uint160(owner()))

The second option requires fewer changes but it makes the smart contract less readable, especially for beginners. What do you think @martriay ?

@frangio
Copy link
Contributor

frangio commented May 13, 2019

@paulinablaszk That's interesting... Very annoying that owner cannot be used as is. I'm trying to see if we could provide something in OpenZeppelin to help this scenario.

Do any of the levels use functionality of Ownable other than the owner function?

@paulinablaszk
Copy link
Contributor Author

@frangio No, only owner function is used. But scenario from Fallback repeat in many levels

@frangio
Copy link
Contributor

frangio commented May 14, 2019

@paulinablaszk Then I'd say we go for the simplest thing:

  • using just address payable owner instead of Ownable.sol

Note that this also implies adding owner = msg.sender in the constructor.

I actually think it's a good thing for the levels to be self-contained. On the other hand, it's also good to show players/learners that OpenZeppelin exists and is helpful for development. 😃 But SafeMath in the other levels is already serving that purpose.

@paulinablaszk
Copy link
Contributor Author

paulinablaszk commented May 15, 2019

@frangio Could you please take a look at my last commit - I would like to make sure that such a convention will be ok before I make changes in more levels ;)

Copy link
Contributor

@frangio frangio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it looks good. Keep in mind I'm not familiar with the levels themselves so I don't know if, for example, transferOwnership is necessary in any of them.

contributions[msg.sender] = 1000 * (1 ether);
}

function owner() public view returns (address payable) {
Copy link
Contributor

@frangio frangio May 15, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of writing the manual owner() getter, it would be ok to just use a public variable directly. I think it's preferable because it allows the player to focus on the rest of the code. We don't do that in OpenZeppelin because we want to have internal variables, but that's not a concern here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, thank you very much!

contracts/levels/Fallback.sol Outdated Show resolved Hide resolved
@abcoathup
Copy link
Contributor

My suggestion for a Fallout level is in the forum:
https://forum.openzeppelin.com/t/ethernaut-fallout-with-solidity-0-5/1066/4

@abcoathup
Copy link
Contributor

I haven't managed to find a way to convert Locked yet so that it compiles and passes the tests.

@abcoathup
Copy link
Contributor

As far as I can work out, Locked needs to be removed/retired as a contract with the vulnerability can't be compiled.

See the write up in the forum:
https://forum.openzeppelin.com/t/ethernaut-locked-with-solidity-0-5/1115

@abcoathup
Copy link
Contributor

Locked level should be retired. Checked with author
https://forum.openzeppelin.com/t/ethernaut-locked-with-solidity-0-5/1115/2

@abcoathup
Copy link
Contributor

AlienCodex can be modified removing the first part of the level:
https://forum.openzeppelin.com/t/ethernaut-aliencodex-with-solidity-0-5/1120

@abcoathup
Copy link
Contributor

Locked level should be retired. Checked with author
https://forum.openzeppelin.com/t/ethernaut-locked-with-solidity-0-5/1115/2

@paulinablaszk once Locked level is retired, then all truffle tests should pass.

Assume we need to delete the following:

  • contracts\levels\Locked.sol
  • contracts\levels\LockedFactory.sol
  • test\levels\Locked.test.js
  • gamedata\descriptions\levels\locked.md
  • gamedata\descriptions\levels\locked_complete.md

and update:

  • gamedata\gamedata.json to remove locked data

Once this is done the tests should pass.

Next step after this is to update the contract deployment. 😄

@paulinablaszk
Copy link
Contributor Author

@abcoathup I've just deleted all 'locked' files

@abcoathup
Copy link
Contributor

Hi @paulinablaszk the build now passes!! Great work.

There is an issue with deploying the Ethernaut contracts that I am seeing if I can track down. It looks like it is an issue with package versions.

@abcoathup
Copy link
Contributor

Hi @paulinablaszk
To enable npm run deploy:contracts to work need:
paulinablaszk#1
paulinablaszk#2

@abcoathup
Copy link
Contributor

After deploying the contracts, when I try to run Ethernaut with npm start I get the following errors due to truffle-contract.

I assume we need to transpile truffle-contract with babel? I am not sure where to configure this (I am new to JavaScript). I have tried in webpack.config.dev.js to no avail.

Failed to compile.

Error in ./~/truffle-contract/lib/execute.js
Module parse failed: /mnt/c/Users/andre/Documents/projects/forum/ethernaut/node_modules/truffle-contract/lib/execute.js Unexpected token (117:39)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (117:39)
 @ ./~/truffle-contract/lib/contract.js 4:16-36

Error in ./~/truffle-contract/lib/contract/constructorMethods.js
Module parse failed: /mnt/c/Users/andre/Documents/projects/forum/ethernaut/node_modules/truffle-contract/lib/contract/constructorMethods.js Unexpected token (36:8)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (36:8)
 @ ./~/truffle-contract/lib/contract/index.js 2:22-53

Error in ./~/truffle-contract/lib/utils.js
Module parse failed: /mnt/c/Users/andre/Documents/projects/forum/ethernaut/node_modules/truffle-contract/lib/utils.js Unexpected token (313:8)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (313:8)
 @ ./~/truffle-contract/lib/contract/properties.js 1:14-33

Error in ./~/truffle-contract/~/scryptsy/lib/scrypt.js
Module parse failed: /mnt/c/Users/andre/Documents/projects/forum/ethernaut/node_modules/truffle-contract/node_modules/scryptsy/lib/scrypt.js Unexpected token (8:6)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (8:6)
 @ ./~/truffle-contract/~/scryptsy/lib/index.js 2:15-34

Error in ./~/truffle-contract/~/scryptsy/lib/utils.js
Module parse failed: /mnt/c/Users/andre/Documents/projects/forum/ethernaut/node_modules/truffle-contract/node_modules/scryptsy/lib/utils.js Unexpected token (52:6)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (52:6)
 @ ./~/truffle-contract/~/scryptsy/lib/scryptSync.js 5:4-22

@frangio
Copy link
Contributor

frangio commented Sep 4, 2019

I wasn't able to reproduce that error. I checked out this branch, and followed the instructions for "Running locally" in the README. Upon running npm start, it compiled successfully, only with a few warnings.

@abcoathup
Copy link
Contributor

I wasn't able to reproduce that error. I checked out this branch, and followed the instructions for "Running locally" in the README. Upon running npm start, it compiled successfully, only with a few warnings.

Hi @frangio,

We cannot deploy the contracts locally without making the following changes:
https://github.com/paulinablaszk/ethernaut/pull/1/files
https://github.com/paulinablaszk/ethernaut/pull/2/files
(Otherwise I can branch and apply these so that you can just clone my branch)

Which once made means that the app can't be started due to a compile error.

Details of my setup process below:

git clone https://github.com/paulinablaszk/ethernaut.git
change to solidity-0.5-#117 branch
npm install

npx truffle compile

In src\contants.js changed to NETWORKS.LOCAL

// export const ACTIVE_NETWORK = NETWORKS.ROPSTEN
export const ACTIVE_NETWORK = NETWORKS.LOCAL

Attempting to deploy the contracts
npm run deploy:contracts
Deploy fails with the following error TypeError: Cannot read property 'getListening' of undefined

Need to make the following modifications to be able to deploy
https://github.com/paulinablaszk/ethernaut/pull/1/files
https://github.com/paulinablaszk/ethernaut/pull/2/files

Can then deploy the contracts
npm run deploy:contracts

But fails when running
npm start

Failed to compile.

Error in ./~/truffle-contract/lib/execute.js
Module parse failed: /mnt/c/Users/andre/Documents/projects/forum/ethernaut/node_modules/truffle-contract/lib/execute.js Unexpected token (123:49)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (123:49)
 @ ./~/truffle-contract/lib/contract.js 4:16-36

@paulinablaszk
Copy link
Contributor Author

paulinablaszk commented Sep 5, 2019

Hi, @abcoathup I'm getting the same error. I also think that it looks like a problem with handling async functions by babel. I was trying to use some other options but without success by now

@frangio
Copy link
Contributor

frangio commented Sep 5, 2019

Okay, I was able to reproduce it. I'm not sure how to fix it. 😅

@obernardovieira
Copy link

Hmm, I've got it working after following @abcoathup last message.

I didn't even have errors when runing npm run deploy:contracts.

Could this be because there are some new versions in some dependencies?

@abcoathup
Copy link
Contributor

Hi @obernardovieira,

I am still getting the same error.

Failed to compile.

Error in ./~/truffle-contract/lib/execute.js
Module parse failed: /mnt/c/Users/andre/Documents/projects/forum/ethernaut/node_modules/truffle-contract/lib/execute.js Unexpected token (117:39)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (117:39)
 @ ./~/truffle-contract/lib/contract.js 4:16-36

Using the following branch:
https://github.com/paulinablaszk/ethernaut/tree/solidity-0.5-%23117

To enable npm run deploy:contracts to work need:
paulinablaszk#1
paulinablaszk#2

@hensha256
Copy link
Contributor

This work was included in #151

@hensha256 hensha256 closed this Nov 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants