Ideas for future features

[engn33r]

Most of these features ideas require substantial effort, but they are worth listing in case a solution is found which makes any of these easier to implement:

• Assess whether there are unused allowances with non-zero value for the multisig address (like revoke.cash)
• Check for any shadow owners https://docs.lido.fi/guides/multisig-shadow-owners#adding-a-shadow-owner
• Check for shadow modules (same ideas as above)
• Check if signers have changed in the last 30 days

[ElliotFriedman]

Combining Halmos with fork testing should allow symbolic tests to be created that can check proper inclusion in the linked list. I've spent quite a bit of time thinking how you would detect this with a language like Typescript and the answer didn't seem obvious to me because you would need to gather up all of the used storage slots and then map them back to their inputs, and since they are hashed to get the key, you wouldn't know what that would be.

[engn33r]

Just tossing out a thought, it may be flawed: instead of trying to reverse the hash maping of a used storage slot, would it be easier to analyze the tx where that storage slot got written?

If some weird proxy tricks were involved, I don't think it's necessarily true that shadow owners/modules must be written during the deployment tx, so the first step would be identifying the block when this data was written and then finding the tx in that block. But reversing the relevant tx trace to identify the input key used may be less compute intensive than a brute force approach.

[ElliotFriedman]

I've given this a lot of thought, and that would likely be something an ML model or LLM would have to do since if you delegatecall to some wonky address and it writes to a weird storage slot, there's no way to go backwards and see which data structure that write corresponds to such as owners or modules.

The models would just give you a trust rating, maybe it sees it writes to a storage slot, has no way to know what that storage is, so gives back a low score because it can't tell what the tx is actually doing.

[ElliotFriedman]

If some weird proxy tricks were involved, I don't think it's necessarily true that shadow owners/modules must be written during the deployment tx, so the first step would be identifying the block when this data was written and then finding the tx in that block.

Correct, the strange writes can happen both during the deployment if they use a non-standard or custom deployment path and after with delegatecalls.

But reversing the relevant tx trace to identify the input key used may be less compute intensive than a brute force approach.

I'm not so sure it's possible to figure out what the input key maps to. If the attack is well executed and just does a direct write, they hash the input key with the storage offset and just write directly to that slot and since the key is the owner, if they don't expose that to you in the input you can't know it unless they tell you or you brute force it, and that's 2 * 2^160-1 possibilities of addresses it could be since it could be an owner or a module.