# Slither's Hidden Gems you might've missed *Beyond basic vulnerability detection: How to use Slither in your arsenal for systematic security research* --- Most security researchers know Slither as "that tool that finds reentrancy bugs." They run `slither contract.sol`, scroll through a wall of findings, and call it a day. But this approach misses Slither's true power: its reconnaissance capabilities that can transform how you approach smart contract security analysis. ## The Arsenal Nobody Talks About While most researchers use Slither's 70+ vulnerability detectors, they completely ignore its most powerful feature: the printer system. These aren't just pretty output formatters—they're intelligence gathering tools that reveal the architecture, attack surfaces, and permission hierarchies that help you find the bugs. ## Phase 1: Intelligence Gathering Before hunting for vulnerabilities, you need to understand what you're attacking. Think of this as your pre-engagement reconnaissance. ### Mapping the Territory **The Bird's Eye View** ```bash slither contract.sol --print human-summary ``` This single command reveals the scope of your challenge: - Total contracts and functions you're dealing with - Complexity metrics that indicate review difficulty When you see 20+ external functions, you know you're dealing with a complex protocol that requires systematic analysis, not ad-hoc poking around. **Untangling Inheritance Webs** ```bash slither contract.sol --print inheritance-graph dot -Tpng contracts.dot -o inheritance.png ``` Modern DeFi protocols often have quite scary inheritance chains. The visual inheritance map reveals: - Hidden parent contracts containing forgotten vulnerabilities - Unexpected inheritance patterns creating attack vectors - Access control hierarchies with privilege escalation opportunities That "minor" admin function in a parent contract three levels up? It might be the key to draining the entire protocol. **Identifying Attack Vectors** ```bash slither contract.sol --print entry-points ``` This shows every state-changing function external actors can invoke—your potential attack surface. Instead of randomly reading code, focus your manual review on these entry points first. Each external function is a door into the system; some lead to treasure. ### Understanding the Architecture **Contract Stats at a Glance** ```bash slither contract.sol --print contract-summary ``` This reveals function visibility patterns, state variables, and modifiers across all contracts. Look for: - Contracts with many public/external functions (higher attack surface) - Unusual modifier patterns (potential access control issues) - State variable distributions (where the valuable data lives) ## Phase 2: Deep System Analysis Once you understand the basic structure, dive deeper into the system's inner workings. ### Control Flow Intelligence **Mapping Execution Paths** ```bash slither contract.sol --print cfg ``` Control flow graphs reveal the logic structure of complex functions. They're essential for: - Understanding branching conditions that might hide vulnerabilities - Spotting unreachable code paths that could indicate dead code or logic errors - Analyzing loop conditions that could enable denial-of-service attacks Complex conditional logic often hides the most subtle vulnerabilities. If a function's control flow graph looks like a subway map, it deserves extra attention. ### Permission Mapping **Following the Authorization Trail** ```bash slither contract.sol --print vars-and-auth ``` This printer shows which functions can modify which state variables and what authorization they require. It's invaluable for finding: - Functions that mysteriously bypass access controls - Critical state variables lacking proper protection - Authorization patterns with logical flaws In DeFi protocols, unauthorized state modifications often lead to the most devastating exploits. ## Phase 3: Targeted Vulnerability Hunting Now that you understand the system architecture, deploy specific detectors based on your reconnaissance findings. ### DeFi Protocol Hunting For financial protocols, focus on value-flow vulnerabilities: ```bash # The classics that drain protocols slither contract.sol --detect reentrancy-eth,reentrancy-no-eth # Financial calculation errors slither contract.sol --detect divide-before-multiply # Silent failures in value transfers slither contract.sol --detect unchecked-transfer,unchecked-send ``` ### Access Control Analysis For governance and admin systems: ```bash # Functions that can destroy the protocol slither contract.sol --detect suicidal,unprotected-upgrade # Hidden admin backdoors slither contract.sol --detect shadowing-state # Weak randomness in gaming/lottery contracts slither contract.sol --detect weak-prng ``` ### Token Contract Auditing For ERC20/ERC721 implementations: ```bash # Standard compliance issues slither contract.sol --detect erc20-interface,erc721-interface # The classic token drain vector slither contract.sol --detect arbitrary-send-erc20 # Value locked forever slither contract.sol --detect locked-ether ``` ### Upgradeable Contract Risks For proxy and upgradeable systems: ```bash # Storage collision nightmares slither contract.sol --detect unprotected-upgrade # Uninitialized state variables slither contract.sol --detect uninitialized-state,uninitialized-storage ``` ## Advanced Integration Techniques ### IDE Integration for Real-Time Analysis ```bash slither contract.sol --sarif results.sarif ``` The SARIF output format integrates with modern IDEs, providing real-time vulnerability highlighting as you code. This transforms Slither from a batch analysis tool into a continuous security assistant. ### Multi-Language Protocol Analysis Modern protocols often combine Solidity with Vyper contracts. Slither's multi-language support enables comprehensive analysis This is crucial for protocols using Curve's Vyper contracts alongside Solidity components. ## The Art of False Positive Analysis Here's where most researchers go wrong: they dismiss "false positives" without investigation. In smart contract security, many "false positives" are actually edge cases worth exploring. When Slither flags something that looks incorrect: 1. **Understand why it flagged it** - The logic might reveal an assumption you missed 2. **Check edge case conditions** - Can you manipulate inputs to make it exploitable? 3. **Consider interaction effects** - The "false positive" might be real in combination with other functions Bugs often hide in these edge cases that automated tools struggle to classify clearly. ## Common Pitfalls That Kill Analysis Quality ### Information Overload Syndrome Running all 70+ detectors simultaneously creates analysis paralysis. Focus on detectors relevant to your reconnaissance findings. ### Visual Analysis Neglect The inheritance graphs and control flow diagrams reveal patterns your pattern-matching brain can't catch from reading code linearly. Use them. ### Automation Dependency Slither finds vulnerability candidates; you confirm exploitability. The tool provides leads, not final answers. ### Scope Creep Start with external entry points and work inward. Don't get lost in internal helper functions until you understand the main attack surface. ## Building Your Analysis Workflow Here's a systematic approach that combines reconnaissance with targeted hunting: 1. **Quick Survey**: `human-summary` and `contract-summary` for scope assessment 2. **Architecture Mapping**: `inheritance-graph` and `entry-points` for attack surface analysis 3. **Deep Reconnaissance**: `vars-and-auth` and `cfg` for critical functions 4. **Targeted Detection**: Protocol-specific detector combinations 5. **Manual Validation**: Confirm exploitability of flagged issues ## The Bottom Line The most impactful vulnerabilities aren't found by running automated scanners—they're discovered through systematic analysis that combines automated intelligence with human insight. Slither provides the intelligence. Your expertise provides the insight. The combination finds the bugs that matter. The bugs are there. The question is whether you'll find them before someone else does. Happy Hacking, anon