Closed sunbeomso closed 4 years ago
You missed taking the padding into account for burn(), it’s not 109, it’s a huge number as mythril ignores padding the right hand side
@norhh
Does Mythril "never" pad zeros?
Given only Mythril's non-padded inputs, is it always possible to decode Mythril's inputs correctly? I think there may be some ambiguous cases, e.g., multiple arguments or non-fixed sized array cases.
If the correct decoding is always possible, could recommend a way to do it?
In case of multiple args mythril pads everything except the last input.
If the correct decoding is always possible, could recommend a way to do it?
Just check the size of the last chunk, if it's not the size of an int256 then pad it to that.
@norhh
Thank you for explaining it.
Just check the size of the last chunk, if it's not the size of an int256 then pad it to that.
What if some previous (which is not located in the last chunk) chunks have dynamic types?
@norhh
In case of multiple args mythril pads everything except the last input.
Does Mythril always pad with '0', or does it sometimes pad with 'f'?
In the below example, the address type argument is ffffffffffffffffffffffffaffeaffeaffeaffeaffeaffeaffeaffeaffeaffe
, i.e., input[8:8+64]
.
It seems that Mythril padded with 'f', not '0'.
"input": "0x79c65068ffffffffffffffffffffffffaffeaffeaffeaffeaffeaffeaffeaffeaffeaffeffffffffffffffffffffffffffffffffffffffffffffffffff",
"name": "mintToken(address,uint256)"
==> Decoded as: mintToken(0xaffeaffeaffeaffeaffeaffeaffeaffeaffeaffe,1606938044258990275541962092341162602522202993782792835301375
It seems that Mythril padded with 'f', not '0'.
That can't exactly be called as padding,it's just some solution.
Does Mythril always pad with '0', or does it sometimes pad with 'f'?
I mean the 0 padding at the end.
What if some previous (which is not located in the last chunk) chunks have dynamic types?
That shouldn't matter, excluding the function signature if the output len() isn't divisible by 64 then it should be padded with 0s to make it divisible.
@norhh Thanks, I will try.
Description
For full Solidity code and further details, please see
How to Reproduce
.Mythril reported that
totalSupply - _value
inburn
function may underflow (see below), and generated corresponding transactions below. I have decoded the input data of the last two transactions after the deployment as following:I generated those transactions in my testnet and checked that if an underflow can occur in the
burn
function with the following code:However, these inputs fail to reproduce the underflow.
How to Reproduce
Testing file: https://etherscan.io/address/0xd1f55c30aa2f9e26c3ddf267ab61d3bd821f272a#code
My command:
Mythril's output (removed some parts irrelevant to this issue):
Expected behavior
My second transaction (
burn(109)
) is supposed to be reverted, but I couldn't get any failures. Regarding decoding, I double-checked possible mistakes with two abi-decoders:Two decoders output exactly the same result I reported.
Could you check if there is anything I missed?
Environment