Bytecode Becomes Contract Address In Exploit Output

[Danc2050]

Description

Okay, really weird bug here. Runnnig mythril over the address 0xD99b6e04d6911f032d2e9139Bd3309D2641Dc706 causes the final exploit found to be an address not of its own (i.e., "0xD99b..."). Instead, it is part of the bytecode with a 0x thrown in front of it.

...
==== Exception State ====
SWC ID: 110
Severity: Low
Contract: 0x6012c8cf97bead5deae237070f9587f8e7a266d
Function name: giveBirth(uint256)
PC address: 6528
Estimated Gas Usage: 1932 - 2687
A reachable exception has been detected.
It is possible to trigger an exception (opcode 0xfe). Exceptions can be caused by type errors, division by zero, out-of-bounds array access, or assert violations. Note that explicit `assert()` should only be used to check invariants. Use `require()` for regular input checking.
--------------------
Initial State:

Account: [ATTACKER], balance: 0x0, nonce:0, storage:{}
Account: [SOMEGUY], balance: 0x0, nonce:0, storage:{}

Transaction Sequence:

Caller: [SOMEGUY], function: unknown, txdata: 0x3030303000303030303030303030303030303030303030303030303030903030, value: 0x0

How to Reproduce

myth -v4 analyze -1 --execution-timeout 3600 -a 0xD99b6e04d6911f032d2e9139Bd3309D2641Dc706

Expected behavior

All exploits should have the address of the contract, not a subsection of the bytecode.

Other examples

The contract 0x1c764a70797DeB7100037581e679684Cc5C9CA42 produces the same problem. However, in this contract the output that is incorrectly put at the end as an exploit from a bug that grabs the bytecode IS a contract (e.g., 0x8d12a197cb00d4747a1fe03395095ce2a5cc6819), which can be easily confusing to people looking at output. I am fairly certain it is not a dependency of this contract, because it would be too coincidental that the bytecode also matched a contract address of a dependency.

[norhh]

Actually that's because a call happens to that contract which is then executed, so the exception is in that contract.

[Danc2050]

Oh, how odd. I guess there is really nothing you could do except to check if the contract was a valid contract, but that is not really ideal either since a contract could be self destructed and then it would be harder to tell (e.g., getCode would not work). Thanks for the update, I'll ignore this output then.

[Danc2050]

I am not closing this as I am not sure if you wanted to do anything with it, though it clearly is the offending contracts fault, not mythrils :1st_place_medal: .

[norhh]

Mythril loads any new contract to which a call is executed and then executes a call, So I don't think this is a bug. As exception gets triggered when a call to 0x6012... is being executed. If you make a call to 0xD99b6.... with some calldata then this might get executed, currently, the interface isn't supported to provide the sequence of calldata for such calls when running on addresses.

[Danc2050]

@norhh Call me slow, but I was running into another contract that had the same properties of this one and I am still doubtful as to whether this is a bug or not (and maybe this is because I wasn't super clear originally). The contract 0x6012c8cf97bead5deae237070f9587f8e7a266d does not actually exist, so even though mythril is loading the contract that is called (which does not exist), how is mythril claiming this contract has an exploit? If anything, it should be the 0xD99b6e04d6911f032d2e9139Bd3309D2641Dc706 that should have an exploit.

[norhh]

@Danc2050 , It was some python error. The contract should be 0x06012c8cf97bead5deae237070f9587f8e7a266d . Python skips a leading zero while printing hex, so while searching just add a bunch of leading zeros if the length is != 40, I should correct this in mythril.

[Danc2050]

Great! Thank you for your help.