# 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