Closed f0rki closed 6 years ago
We’ve been refactoring it with the lifter in a different branch, as well as refactoring the disassembler, so we’ll hold off with this until we merge those changes into master. Some of this is likely duplication of effort, but we’ll incorporate anything else that’s good 🙂
Is the branch with the refactoring public?
Yes it’s the refactor branch
Ah, I didn't notice that branch. That's quite some refactoring. However, as I can see there are quite some EVM instructions still missing in the refactor branch, right? I'm sure you could use that part from my PR.
Some things I do not know whether they are useful:
callvalue
register which is returned by the CALLVALUE
instruction)CALL
or BALANCE
etc., are lifted to systemcall
IL instructions and set a special evm_call_nr
register to a numerical identifier of the "evm call".Hey @f0rki, I'm not sure if you're still working on this but if you are, please sign our CLA. Let me us know if you need any assistance, we're all on Slack and excited to continue working on Ethersplay.
Click through this link to sign the CLA: https://cla-assistant.io/trailofbits/ethersplay?pullRequest=25
Unfortunately, properly modeling EVM is not possible with Binary Ninja IL. Theo, Josh, and myself have all been down this route and come up short. Additionally, I've discussed this pretty extensively with the Vector35 guys and it's not going to happen. I'd rather not merge in incomplete support, so I'm going to close this PR.
If it becomes possible, I think we will definitely take this approach.
@dguido not so much anymore. I'll sign the CLA when something might actually merge.
@withzombies That is unfortunate. I found ethersplay to be pretty helpful for manually reversing contracts. Especially after I modeled most of the instructions. It was super helpful to recover constant SLOAD
or MLOAD
addresses. So I might disagree a bit, in that partial modeling/lifting is also useful :)
I'm guessing the main issue is that the EVM uses separated address spaces for everything? Maybe you can explain a bit more why it isn't possible? I'd certainly be interested what the main issues are.
This PR contains some progress with lifting EVM instructions to LLIL. I think all of the instructions are modeled in terms of their usage of the stack.
MSTORE
,MLOAD
,SSTORE
,SLOAD
are not correctly implemented because of limits of binary ninja (see #15). I tried to split the address space by adding huge offsets (e.g.2**256
for all addresses in EVM memory space), but apparently that doesn't work, because the pointer offsets can't be that big.However, the current state is still useful. I created a small plugin command that uses the partial emulation of binary ninja to get possible stack contents for interesting instructions, such as e.g.,
Here the address can be inferred, but the value depends on input/computation and is therefore unknown.
SSTORE
. It looks like this:This PR is not ready for merge, this is primarily for getting some feedback now. I moved quite some code around. So I'd appreciate some feedback. Also there seems to be a bug with LLIL emulation in the current binary ninja dev build (see this issue), so I wouldn't merge until that is resolved.