Hey! That’s most likely caused by a compiler mismatch. Mythril uses the solc version installed on your system & Parity wallet only compiles with older compilers.
Check out this article from last year about detecting Parity bug 2 with Mythril. We also have a support channel on Discord if there’s any issues.
Smart contract bugs happen, but insecurity is not a fundamental property of smart contracts. It is a known problem that is being addressed on multiple fronts: Best practices, human audits, verifiable languages, verified components, security tooling, and lots of interesting research.
Awesome article Tyler :)
Mythril should catch a few more of the Ethernaut bugs, at least “Fallout” and “Delegation”. For delegation, you need to deploy and link the contracts first and run an on-chain analysis, because Mythril can’t tell the interdependencies from the source code.
Edit: I’d also argue that the “Ether Send”…
Hi withzombies, that’s because of the way dynamic array elements are laid out in storage. In this particular case,
a1 is a dynamic array that maps to storage position 1, which means that:
keccak(1) + offset
Hi Davide, it depends on what you mean by “used in production”. If you’re planning to roll out a new contract to production, using Mythril during development and audit is certainly helpful. It won’t give you a security guarantee though.
As for the state of development, it’s relatively stable and detects a nice variety of…
If you have an architecture that pulls markup from somewhere else then there is no “safe” alternative to dangerouslySetInnerHTML. In that case, you’d have to be extra careful to escape any untrusted data inside that markup. Pretty much just follow standard anti-XSS best practices :