I'm trying to test the article at https://blog.golemproject.net/how-to-find-10m-by-just-reading-blockchain-6ae9d39fcd95, which suggests that for a function that takes an ethereum address as its first parameter and then a uint value as its second parameter, if the function is called with an address ending in 0 (but without entering the final 0) the value of the uint parameter will be shifted to the left and the value made larger.

I have the following function:

function sendether (address to, uint value) {

And an address 0x196218dc0f59bd7247b5c10f97cdc503d7c8cb80 (ending in 0).

Calling my function as follows, for example (omitting the final 0 in my address):

contractInstance.sendether("0x196218dc0f59bd7247b5c10f97cdc503d7c8cb8", 10, {from: web3.eth.accounts[0], gas:4000000}

Actually sends the 10 wei to address 0x0196218dc0f59bd7247b5c10f97cdc503d7c8cb8 instead (the missing 0 is added at the start, right after 0x, instead of the end).

And results in the following transaction:


If I were to call the function with the correct address (0 at the end) as follows:

contractInstance.sendether("0x196218dc0f59bd7247b5c10f97cdc503d7c8cb80", 10, {from: web3.eth.accounts[0], gas:4000000}

It has the following transaction:


The right side of these two transactions (...000000a) which represents the uint value is the same, and both just send 10 wei. I am wondering if (per the article) there is still a vulnerability here and a function that takes an address as a parameter should verify it's an address of the right length.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.