Building a Custom Slither Detector for CEX Interface Security

How I built a zero-false-positive detector for Centralized Exchange smart contract vulnerabilities using Slither 0.11.6 and Python

The Problem: CEX Interfaces Are High-Value Targets
Smart contracts that interact with centralized exchanges (CEX) handle critical operations: API key management, cross-chain withdrawals, order execution, and price oracle feeds.

A single vulnerability in a CEX interface can lead to catastrophic losses:

Hardcoded API keys → Attacker extracts credentials and drains exchange account

Missing signature verification → Unauthorized parties trigger withdrawals

Insecure nonce handling → Replay attacks manipulate order execution

Plaintext credentials → Sensitive data visible to anyone on-chain

Yet, most existing Slither detectors focus on general DeFi vulnerabilities. There was no dedicated tool for CEX interface security.

So I built one.

What is Slither?
Slither is the most popular static analyzer for Solidity smart contracts, developed by Trail of Bits. It detects vulnerabilities like reentrancy, unauthorized access, and uninitialized variables.

But Slither's real power lies in its custom detector API — you can build your own detectors tailored to specific use cases.

Why Build a Custom Detector?
Existing Slither detectors are excellent for general vulnerabilities, but CEX interfaces have unique patterns:

API key management — Contracts store exchange credentials

Signature verification — External calls must be cryptographically authenticated

Nonce handling — Request signing often uses timestamps (vulnerable to manipulation)

Rate limiting — Functions need usage limits to prevent abuse

I needed a detector that understands these patterns and produces zero false positives.

Architecture of the CEX Detector
The detector is built as a Python package that extends Slither's AbstractDetector class, defining its argument name, help text, impact level, and confidence level.

Detection Logic
The detector runs four specialized checks:

Hardcoded API Keys — Scans state variables for sensitive names (api_key, api_secret, private_key)

Missing Signature Verification — Checks if external functions call other contracts without ecrecover or signature validation

Insecure Nonce Handling — Flags functions using block.timestamp for nonces (but excludes safe rate-limiting patterns)

Plaintext Credentials — Identifies credentials stored as string or bytes types

Smart False Positive Reduction
The key challenge was avoiding false positives. For example:

Rate limiting uses block.timestamp safely → Detector checks for lastRequestTime patterns

Signature verification might be in helper functions → Detector searches the entire contract for ecrecover

Encrypted credentials use bytes32 → Detector excludes bytes32 and variables with "encrypted" in the name

Real-World Examples
Example 1: Vulnerable Contract
A typical vulnerable CEX interface stores a live Binance API key and an API secret as public strings, plus a mapping of user credentials — all in plaintext. Its executeCEXCall function forwards arbitrary calldata to an external address with no signature verification whatsoever.

Detector Output:

text
Found 3 vulnerabilities:

1. Function 'executeCEXCall' lacks signature verification
   Impact: High
   Confidence: Medium

2. Plaintext credentials: 'apiSecret'
   Impact: Critical
   Confidence: High

3. Plaintext credentials: 'userCredentials'
   Impact: Critical
   Confidence: High
   Example 2: Secure Contract
   A properly secured version stores credentials as encrypted bytes32 values, keeps an immutable owner address, and tracks per-user nonces. Its executeCEXCall function hashes the endpoint, data, and nonce, verifies the signature via ecrecover against the owner, increments the nonce, and only then executes the call.

Detector Output:

text
No vulnerabilities found! ✅
Zero false positives. The detector correctly identifies that:

Signature verification is present (via ecrecover)

Credentials are encrypted (bytes32, not string)

Nonces are properly incremented (not using block.timestamp)

How to Use the Detector
Installation
Clone the repository from GitHub, move into the project directory, create and activate a Python virtual environment, then install the package in editable mode with pip.

Basic Usage
Run the detector script against a Solidity file to analyze a contract, and pass the JSON flag to export results in structured form.

JSON Output
The detector exports results in a structured JSON format, perfect for CI/CD integration. Each finding includes a type (such as missing_signature), a human-readable message, impact and confidence levels, and an element object describing the affected function — its name, type, visibility, source mapping, and parent contract.

Integration with CI/CD
You can integrate the detector into your GitHub Actions workflow. The workflow triggers on pushes to main that touch Solidity files under contracts/. It checks out the code, sets up Python 3.10, clones and installs the detector, runs the security check against your contract with JSON output, and uploads the results as a build artifact.

Test Results
I tested the detector against two contracts:

Contract Vulnerabilities Found False Positives Status
VulnerableCEXInterface 3 0 ✅ Correct
SecureCEXInterface 0 0 ✅ Perfect
The detector successfully identifies critical vulnerabilities while maintaining zero false positives on secure code.

What's Next?
This is just the beginning. Future improvements include:

CEX-specific patterns — Detection for Binance, Coinbase, and Kraken API patterns

Hardcoded private keys — Identify private_key = 0x... patterns

Cross-chain bridge vulnerabilities — Detect insecure message passing

PyPI publication — pip install slither-cex-detector

Conclusion
Building a custom Slither detector is a powerful way to extend smart contract security tooling for specific use cases. The CEX Interface Security Detector demonstrates that you can achieve high accuracy with zero false positives by understanding domain-specific patterns.

If you're working on CEX integrations, DeFi protocols, or any smart contract that handles sensitive credentials, this detector can help you catch vulnerabilities before they become exploits.

Resources
GitHub Repository: github.com/rdin777/slither-cex-detector

Slither Documentation: github.com/crytic/slither

DeFi Security Blueprint: github.com/rdin777/defi-security-blueprint

If you found this article helpful, please consider starring the repository on GitHub! ⭐

Questions or feedback? Reach out on Twitter or open an issue on GitHub.

web3 #security #ethereum #smartcontracts #python

Comments

[rim dinov]

Thanks for reading! If you have ideas for new CEX-specific patterns to detect, drop them in the comments or open an issue on GitHub!