list error on disassembly about mythril

[muellerberndt]

Works for me:

$ myth -d -a "0x2a0c0dbecc7e4d658f48e01e3fa353f44050c208"
0 PUSH1 0x60
2 PUSH1 0x40
4 MSTORE
5 CALLDATASIZE

Do you still get the error in the latest version (0.4.2)?

[pirapira]

@step21 I was seeing the same error, and I found I had version 0.1.6

$ pip show mythril
Name: mythril
Version: 0.1.6
Summary: Mythril is an assembler and disassembler for Ethereum VM bytecode
Home-page: https://github.com/b-mueller/mythril
Author: Bernhard Mueller
Author-email: [email protected]
License: MIT
Location: /home/yh/.local/lib/python2.7/site-packages
Requires: ethereum

[pirapira]

@step21 I also saw the same error when I connected to a cpp-ethereum node.

[muellerberndt]

@pirapira does the error still occur in 0.5.6?

Try to install with:

$ pip install mythril==0.5.6

[pirapira]

@b-mueller yes, but only when I use eth from cpp-ethereum instead of geth. Your README is explicit about using geth.

[muellerberndt]

Maybe a difference in the RPC protocol. Would be great if you can commit a fix if you figure it out (I don't have cpp-ethereum available myself).

[step21]

Ok, just installed 0.5.6 (z3-solver took forever) but this still happens. I don't think it is related to cpp-ethereum as such, or not only, as I only ever used geth with mythril. However, when writing the ipc code, I switched between rpc and ipc sometimes. While I think that for the most part the code should have failed if the ipc code returned something unexpected, I did not directly compare this and I think it wasn't necessary as in geth internally the rpc/ipc calls do the same thing and return the same thing. Still, can you think of a good way to check data consistency of the mythril storage? (otherwise I'll try to just resync everything and see if that fixes it)

[muellerberndt]

I don't think it has anything to do with the database because mythril -a doesn't require it.
Actually, with the symbolic EVM a lot of the code disassembly.py isn't needed anymore so I'm gonna get rid of that. Maybe that will fix the error. I'll also add some more debugging options just in case.

[muellerberndt]

I just release 0.5.7 which removes block parsing from disassembly.py. It probably won't fix the error though, because from the output you are getting it seems that core of the problem is the RPC/IPC response.

If you install the update and run it with -v2, it should print the received bytecode as follows:

$ pip install mythril==0.5.7
$ myth -d -a "0x2a0c0dbecc7e4d658f48e01e3fa353f44050c208" -v2
DEBUG:root:Input bytecode: 0x6060604052361561012d5763ffffffff60e060020a60003(...)

I assume that would return some kind of error or an empty code string?

[step21]

Mmh yeah true. Actually I found another error when initially syncing with ipc, as web3py doesn't require a hex_to_dec helper function (it returns dec) and somehw for blockNumber I had not removed it. But so far it does not seem to be related (still syncing).
I manually added some print statements for debugging, though it didn't give me a solution so far. But in case it helps:

safe_decode hex string 0x
signatures size 5914
jmptable_indices []
blocklen 0
num_instructions 0
instruction_list []

I hope the description is sufficient to show 'what is what'.

[step21]

For your new version, it is the same, it gives the 'hex string' with 0x such as

myth --ipc -d -a "0x2a0c0dbecc7e4d658f48e01e3fa353f44050c208" -v2
DEBUG:root:Input bytecode: 0x

[muellerberndt]

Sounds like RPC / IPC is returning an empty result? Can you try to dump the whole IPC response?

Does it work with any other address?

[muellerberndt]

Another reason could be if your geth node is not fully synced & the contract code is not available yet..

[step21]

Yeah. It is actually not fully synced up, but not really old either, so I assumed it should be fine. Sorry if that turns out to be the culprit, but I do most work on my small laptop so I do not always let it sync because it makes the fan/cpu go crazy...
I cannot easily dump the ipc response as that is handled by web3py. If I dump the rpc response it is {'id': 1, 'result': '0x', 'jsonrpc': '2.0'}
Edit: Ok, so I think this really was the problem. F.e. if I use 0xFa52274DD61E1643d2205169732f29114BC240b3 it works. Thanks for helping to debug and sorry for not thinking of this myself. Maybe it was even the same for @pirapira

[muellerberndt]

ok, cool! I'll add a note on this to the README.

[muellerberndt]

If you get an infura key you can try remote RPC:

./myth --rpchost "mainnet.infura.io/{INFURA_KEY}" --rpcport "443" --rpctls="True" -g ./graphlol.html -a "0x2a0c0dbecc7e4d658f48e01e3fa353f44050c208"

[step21]

Yeah, that is a great feature as well. At least for direct querying it should be nice.

[muellerberndt]

I'm assuming this is resolved :)