nisedo's Trail of Bits Slither Secureum Workshop Submission

Detectors

I managed to complete the first three detectors. I attempted the 'mul-reduction' but without satisfactory results, and due to time constraints, I haven't tried the other three.

I approached these detectors as I would CTF challenges, aiming to detect instances present in their corresponding example.sol. However, I'm aware that I did not consider other edge cases or follow best coding practices.

ID	Name	What it detects	Examples	Completed
0	unused-event	Events that are not used	example.sol	✅
1	isContract	Incorrect isContract function/modifier	example.sol	✅
2	divide-by-total-supply	Division by the total supply	example.sol	✅
4	mul-reduction	Mul can be replaced by add	example.sol	❌

EntryPoints Printer

Rather than write my own detectors, because I didn't have any interesting ideas for new detectors, I wanted to write a printer that detects all the entry points of a codebase, because that's something I look for in each of my audits.

My goal was to have a simple printer that shows all public/external non-view/pure functions (aka public state-changing functions). This allows quick identification of user flows within a codebase and their starting points (the entry points) during the initial phase of an audit.

This is the current output I get: https://app.warp.dev/block/FRO4T8Dy4zG1SUrAEMHbrC

The printer outputs:

• Public and external functions, displaying any associated modifiers.
• Functions are sorted by those without modifiers first, followed by those with modifiers.

The printer excludes:

• View and pure functions that do not change state.
• Functions that are part of libraries or interfaces.
• Constructors, as they do not serve as regular entry points.

Notes

I've tested this tool on multiple codebases and it has consistently identified entry points without any false positives.

Going forward, I plan to enhance the output format to align with modern design standards, similar to the tabular outputs seen in tools like Foundry. This update will focus on improving readability and providing a more structured presentation of data, making it easier to interpret during audits.

---

Slither secureum workshop

The goals of this workshop are to:

• Learn about Slither's API
• Write your first detectors
• Experiment with writing new detectors rules
• Experiment with how to evaluate static analyzers

Detector list

For each detector:

• Use the example.sol file in the evaluation/NAME directory
• Create more test cases, and try your detector on various codebases
• Highlight any edge-case that is properly detected by your detector in its documentation

ID	Name	What it detects	Examples
0	unused-event	Events that are not used	example.sol
1	isContract	Incorrect isContract function/modifier	example.sol
2	divide-by-total-supply	Division by the total supply	example.sol
3	storage-read	Unnecessary storage read	example.sol
4	mul-reduction	Mul can be replaced by add	example.sol
5	copy-propagation	Costly operations can be replaced	example.sol
6	read-only-reentrancy	Read only vulnerability	No example provided
7	NAME1	Your own detector :)	N/A
8	NAME2	Your own detector :)	N/A
9	NAME3	Your own detector :)	N/A

The list does not follow a particular order. The read-only-reentrancy is considered as the most challenging detector to write (you might take inspiration from the existing detectors). We would recommend trying to write your own detector's idea after writing 2-3 of the provided ones.

Judging criteria

• Novelty and complexity handling
• False alarms rate
• Code quality
• Test quality

Setup

• Fork this repo
• Update the detectors in detectors/NAME/detector_name.py
  • For a new detector, update detectors/all_detectors.py to import the class
• Add more tests in evaluation/NAME/. Ensure the code compile with solc 0.8.20 (if another version is needed, precise it)

Python tips

• Use a python virtual environement.
  • For example: https://virtualenvwrapper.readthedocs.io/en/latest/
  • mkvirtualenv secureum - generate a python virtual env
  • workon secureum - open the virtual env
• From the virtual env, run pip install -e .. This will add the detectors in slither.
• You can then run you new detector with slither path/to/file.sol --detect NAME

Ask in discord if you have problems

Submission

Send your fork of this repo to [email protected] by Sunday 23th end of day (no timezone requirement):

• Either with a zipfile
• Or if you use a private github repo, add montyly to the repo

You can provide a readme with any relevant details (ex: highligting specific edge case handled, showing the different tests)

References

• Tutorials
• Adding a new detector
• Slides