some fixes

[A-23187]

• add cli option --enable-mutation-pruner to control if to enable MutationPrunerBuilder
• let cli option --enable-coverage-strategy to control if to load CoveragePluginBuilder
• let cli option --enable-iprof to control if to load InstructionProfilerBuilder
• remove the redundant print in MythrilDisassembler.hash_for_function_signature
• fix the bug of non-hexadecimal numbers found when converting hex(func_hash)[2:] to bytes
• other fixes

[CLAassistant]

All committers have signed the CLA.

[norhh]

It's better if these functions are enabled by default, For example, using Mutation Pruning gives the best performance. Users can directly use -v4 to directly get InstructionProfiling results and coverage results without explicitly using the --enable flags. Adding an option to disable them is more useful.

[norhh]

Nice Catch!

[norhh]

literal_eval in line 619 in cli.py changes the hex to integer. Hence we will have to re-hex it. Hence this change will not work with the current cli.py file.

[A-23187]

literal_eval in line 619 in cli.py changes the hex to integer. Hence we will have to re-hex it. Hence this change will not work with the current cli.py file.

The problem is that re-hex an integer to a string will miss the leading zeros which causes the error of non-hexadecimal number found in bytes.fromhex().
For example:

original_hash = '0x0b95d228'
hash_integer = int(original_hash, 16)
rehexed_hash = hex(hash_integer) # 0xb95d228, missing the leading zeros compared to original_hash
bytes.fromhex(rehexed_hash[2:]) # ValueError: non-hexadecimal number found in fromhex() arg at position 7

Also, I noticed that the type hint of args.transaction_sequences in line 19 of support_args.py is List[List[str]]. And I tried to run the myth cli with something like --transaction-sequences '[["0x0b95d228"]]' (quoting the function hash), which causes the error of 'str' object cannot be interpreted as an integer due to the re-hex operation. So I removed the re-hex here.
I think we should perform different operations here to convert function hash to bytes depending on the type of function hash.

[norhh]

You do not need to use '' when using --transaction-sequence. Something like --transaction-sequences [["0x89b8ae9b"],["0xaaaaaaaa"],[]] works

[A-23187]

Yep, this works, because the shell (bash I use) expand [["0x89b8ae9b"],["0xaaaaaaaa"],[]] to [[0x89b8ae9b],[0xaaaaaaaa],[]] before passing to myth. I add a statement print(args.transaction_sequences) before do literal_eval to check the value of args.transaction_sequences, and it prints [[0x89b8ae9b],[0xaaaaaaaa],[]].

Something like --transaction-sequences '[["0x0b95d228"]]' (put the hash in " and put the whole tx sequences in ') can avoid the expansion of the shell. It seems that no one would specify --transaction-sequences so weirdly like this. But when calling mythril in a script, I hope to specify the args.transaction_sequences directly using the return value of MythrilDisassembler.hash_for_function_signature without converting to integer:

args.transaction_sequences = [[MythrilDisassembler.hash_for_function_signature('fun_name()')]] # without converting to int

# args.transaction_sequences = [[int(MythrilDisassembler.hash_for_function_signature('fun_name()'), 16)]]

So I still think it is needed to consider different types when converting function hashes to bytes.

[A-23187]

I think this issue has already been sloved in the newest commit of the develop branch, so I remove my fix code

[A-23187]

It's better if these functions are enabled by default, For example, using Mutation Pruning gives the best performance. Users can directly use -v4 to directly get InstructionProfiling results and coverage results without explicitly using the --enable flags. Adding an option to disable them is more useful.

Yay, I now change to disable options.

[norhh]

All Good! Thanks for the PR