Bugfix function signature misreport

[yitacls]

Description

• Implement a filter to exclude common false positive signatures, such as account_info_rotate_tine(uint256), as well as 0x00000001.
• Add --ignore-false-funcs argument to ignore false positive function signatures

This PR introduces a new command-line argument --ignore-false-funcs in cli.py. This argument accepts a list of function signatures to be ignored as false positives.

Usage Example:

python myth a -a 0x0aaeb2f7209b5796a3f323dcdf9cc4a7981ec8bf -t 1 --bin-runtime --unconstrained-storage --infura-id <infura-id> --transaction-sequences [[0x022c0d9f]] --ignore-false-funcs [0x00000001]

[norhh]

tests/integration_tests/coverage_metrics_test.py::test_basic_coverage seems to fail at the literal_eval statement.
Can you add a testcase for this argument?

[CLAassistant]

All committers have signed the CLA.

[yitacls]

Thanks for pointing this out. I had missed handling function signatures provided in dict form, but this has been fixed in a recent patch. I've also added a test case for the --ignore-false-funcs argument in tests/integration_tests/ignore_false_funcs_test.py.

However, during testing, I discovered a new issue. The Transaction Sequence: in mythril/analysis/templates/report_as_text.jinja2 uses function signatures from the concrete_transactions input fetched directly from the database (or defaults to "unknown" if not found). If a signature passed via --ignore-false-funcs exists in the DB (e.g., 0x83197ef0 for "destroy()"), there may be a mismatch between the function name shown in the vulnerability report and the one in the transaction sequence. While this is a potential issue, I believe it's not critical and fixing it would likely require significant changes, which I don’t have bandwidth for at the moment.