Phink – ink! fuzzer for security and robustness
Phink, the ink! fuzzer
Phink is an innovative, open-source fuzzing tool specifically designed for ink! smart contracts within the Polkadot ecosystem. Fuzzing is an essential in the developer toolbox and will increase the security and reliability of ink! smart contracts.
Developed by Security Research Labs (SRLabs), Phink aims to enhance the hacking resilience and robustness of smart contracts by utilizing advanced coverage-guided fuzzing techniques and smart mutations.
Goals of Phink
-
Enhanced Security Testing: Phink leverages cutting-edge fuzzers like AFL++ and Honggfuzz to provide comprehensive code coverage and systematic exploration of smart contract code paths, effectively identifying potential vulnerabilities.
-
Comprehensive Invariant Testing: By supporting both developer-specific and common smart contract invariants, Phink allows for rigorous verification of native code conditions and critical inputs, helping developers prevent bugs and ensuring long-term robustness.
-
Broad Compatibility: Designed to be free from ink! version dependencies, Phink enables developers to use their own runtime, storage, and state, making it highly flexible and applicable across various environments.
-
Open-Source and Easily Accessible: As an open-source tool, Phink encourages community contributions and continuous improvement. We create all resources necessary for developers to start fuzzing without the need for prior experience, including how-to tutorials and comprehensive documentation.
-
User-Friendly Interface: Phink includes an intuitive interface that visualizes code coverage, state transitions, and invariant testing results, making it accessible and easy to use for developers, auditors, and researchers.
Proposal Objective
SRLabs seeks funding to develop Phink, addressing the limitations of current smart contract fuzzing tools by incorporating advanced fuzzing techniques for more systematic and adaptive security testing. The project will involve the development of a fuzzing harness, custom instrumentation, a user-friendly interface, and thorough documentation to support community use and contribution.
Full Proposal: For a detailed understanding of the Phink project, including the context, identified problems, and proposed solutions, read our full proposal here.
SRLabs: Learn more about Security Research Labs and our commitment to enhancing cybersecurity on our website. Find our previous work on open-source fuzzers for the Polkadot community here and here.
We Value Your Feedback
We invite the Polkadot community to provide feedback on our proposal. Your insights on the critical features and improvements for Phink will help us better serve the ecosystem. Please share your thoughts and suggestions to refine our approach and enhance the security of ink! smart contracts.
Comments (8)
Requested
Proposal Passed
Summary
0%
Aye
0%
Nay
Aye (47)0.0 DOT
Support0.0 DOT
Nay (17)0.0 DOT
Hey @SRLabs,
Interesting proposal! Working closely with Ink! contracts analytics (and previously audits as well), we have some questions:
In order to identify smart contract output as an error, one needs to have a set of definitions of what the error actually is (either in documentation or in code). This is very rare in web3 and often makes it impossible for fuzzers to discover eg. reentrancy attacks. Do you maybe have an idea how to tackle this?
As long as fuzzing is working pretty well in local environments, how do you envision smart contract fuzzing where smart contracts are dependent on the blockchain state and connected to external smart contracts (eg. in DeFi)? This increases the number of potential inputs geometrically compared to local environment.
What is the current coverage you're achieving with Phink?
Best,
Kamil
@Tokenguard
Hey Kamil -- Thanks much for the positive feedback and attention to detail!
We have collected some thoughts on the points you raised.
Defining errors in smart contracts
You raise an excellent point about the need for predefined error definitions to identify issues like reentrancy attacks. To address this, we are integrating checks for common issues (e.g. index-out-of-bound errors, unwrap and expect usage, division by zero).
Additionally, we will heavily rely on invariant development (facts about the protocol that should remain true in any case) to derive assert conditions. This includes both ink! function-level and system-level invariants. We also use existing smart contract security audit reports and test cases in open-source projects to identify smart contract patterns that could indicate potential vulnerabilities.
Fuzzing smart contracts dependent on blockchain state
This indeed comes at increased complexity. To handle the dependencies, we are developing a module that uses snapshotting to allow for efficient state resets for fuzzing, maintaining consistency across test runs.
Additionally, we are creating a simulation environment that can mimic blockchain interactions, allowing for realistic fuzzing scenarios. We will allow mocking the states of multiple contracts in the fuzzing campaign, enabling cross-contract calls. For example, Contract A can call Contract B's give_me_your_state() message to fetch runtime B’s state.
Furthermore, we are exploring ways to fetch and fork storage entries similar to a basic Substrate chain, enabling us to manage complex interactions and states.
Phink coverage
As for the current coverage with Phink, it is still in development. Our initial prototype has shown promising results, reaching predefined abort conditions in test contracts in a matter of minutes. We aim to provide a detailed performance and coverage metric after completion of our performance evaluation (Milestone 6 in the proposal).
If you have further questions or would like to discuss in more detail, feel free to reach out. We’re here for you to continuing the conversation.
Thanks again for your questions!
How much of the codebase will be extendible for future non-Ink! smart contract development plans i.e. PolkaVM, Plaza and so on.
Will those require a new repository for fuzzing tools significantly different or is there any chance to bootstrap those in the future from this repo? We have voted AYE already because fuzzing remains an important element in smart contract development's pipelines.