Closed jjordan-quantum closed 1 year ago
When searching the bytecode for the the set of encoded method signatures (encoded form the contract's ABI), I get the following results:
found: 0xad5c4648
found: 0xe8e33700
found: 0x1703a5d7
found: 0xc45a0155
found: 0x5a2b5106
found: 0xff0fb72c
found: 0x85f8c259
found: 0x054d50d4
found: 0xad615dec
found: 0xbaa2abde
not found: 0x00879679
found: 0x810c48c3
found: 0x6041ab15
found: 0x136e9ee9
found: 0xa0bee3f5
found: 0x96e52138
found: 0x18dd2b35
found: 0x38ed1739
found: 0x5c11d795
found: 0x4d3d2739
found: 0x8803dbee
There's definitely something going on here that I don't understand. Maybe something to do with optimization?
Ok...the issue is that the hashed function selector turns out to have 2 leading 0's, therefore it is stored in a JUMP3 opcode, not a JUMP4. Cheers
Hi @jjordan-quantum, thanks for sending this. You're right, in this case the selector is being pushed with PUSH3
opcode. You can confirm this by running the new sevm
CLI tool included in the repo.
In the following,
issue.bytecode
contains the bytecode posted in the original issue.
$ sevm dis issue.bytecode | grep 879679
341 PUSH3 0x879679
However, when running the symbolic analysis, this value is correctly detected as a function selector. Try
$ sevm selectors issue.bytecode
0xc45a0155 factory()
0xe8e33700 <no signature>
0xff0fb72c <no signature>
0xad5c4648 WETH()
0xad615dec <no signature>
0xbaa2abde <no signature>
0x8803dbee <no signature>
0x96e52138 <no signature>
0xa0bee3f5 <no signature>
0x810c48c3 <no signature>
0x85f8c259 <no signature>
0x5a2b5106 <no signature>
0x5c11d795 <no signature>
0x6041ab15 <no signature>
0x38ed1739 <no signature>
0x4d3d2739 <no signature>
0x136e9ee9 <no signature>
0x1703a5d7 <no signature>
0x18dd2b35 <no signature>
0x00879679 <no signature>
0x054d50d4 <no signature>
Moreover, you can see where this data flows by running
$ sevm dis issue.bytecode --with-stack | grep 00879679
345 EQ 〒 eq(msg.sig, 00879679)|local0
346 PUSH2 0x01ab 〒 [J]0x1ab|eq(msg.sig, 00879679)|local0
meaning that 0x01ab
is the program counter for this function's selector.
Yeah I guess the issue was with the repo you forked from - when I was originally using the getFunctions()
method, it was missing the functions being pushed with a PUSH3, as you can see here - it only filters for PUSH4. At the time, I was blindly trusting the conditions of this filter as a way to identity all contract functions in the code. Tis clear now.
I have a compiled contract for which I used the
decode
function found within theopcodes.ts
file in this repo.With the resulting set of opcodes, I have parsed / formatted the pushdata into an array of strings for all 'PUSH4' items.
Within that final set, there seems to be a method hash missing from one of the smart contract functions.
The missing method hash is 0x00879679. The method can still be called though, so its definitely there. And it's state changing, so called in tx.
This method was also missing when decompiling using the repo you forked from by @MrLuit
Here is the code: