Mythril bytecode analysis: deployment vs runtime code

[Gernot Salzer]

Mythril behaves differently depending on whether it thinks that the bytecode is deployment code or runtime code:

$ python myth analyze -f code.hex # code.hex is interpreted as deployment code (contract creation code)

versus

$ python myth analyse --bin-runtime -f code # code.hex is taken to be the deployed runtime code

In the first case Mythril tries to deploy and analyze the result of code.hex.

Regarding smartbugs:

• We should add the option --bin-runtime to cmd_bytecode in config/tools/mythril.yaml (after analyze)
• Should we make the functionality of Mythril, executing deployment code and then analyzing the generated runtime code, accessible to smartbugs users, e.g. via an option? Are there other tools distinguishing these two cases?
• We should recheck that the other tools interpret the supplied bytecode consistently as runtime code.

[Gernot Salzer]

In commit 2e7d9d2, I have added --bin-runtime to cmd_bytecode in config/tools/mythril.yaml.
The second point is still open for discussion: Should we make the functionality of Mythril, executing deployment code and then analyzing the generated runtime code, accessible to smartbugs users, e.g. via an option?
So far, I found only Maian which also distinguishes between analyzing deployment bytecode and deployed bytecode.

[Előd Varga]

@gsalzer If the first is available, then is there any scenario where the plain action of deployment can alter the resulting runtime code? I believe not. If the source code gets successfully deployed then it should always result in the same runtime code, therefore if we just run --bin-runtime it should be enough in all scenarios.

[Gernot Salzer]

The two scenarios deployment code and runtime code are different, both from the user perspective and the tool perspective.
With deployment code, the user provides more information, so the tools have more clues for analysis. Several tools deploy the deployment code on a chain, not only to obtain the runtime code, but also to query the storage (as initialized by the deployment code) or to try out the exploit they have constructed (to exclude false positives). These are things you cannot do with runtime code alone.
If runtime code is all we have, like when analyzing already deployed contracts, then the analyzing tools have to treat the storage variables as unknowns, which increases the search space. Moreover, they are usually not able to deploy the runtime code on a private chain, as they would have to synthesize the deployment code. I'm not aware of any tool doing that, so the exploits cannot be checked.
Sometimes deployment code is used as a script, where everything happens during deployment and there is actually no runtime code (or just a dummy). When analyzing bytecode, there are subtle differences depending on whether we assume that the bytecode is executed during deployment or during runtime, so a careful analyzer could/should take this into account.
Bottomline: There are differences between the two scenarios, and some tools offer different functionalities in the two cases.

[Gernot Salzer]

Implemented in SB 2.0