Небольшая история о путешествии в мире аудита

Этот пост был написан прекрасным аудитором Charles Wang день или два назад. Он делится своим опытом в старте аудита смарт контрактов, и что сработало для него больше всего. Думаю, этот пост будет полезен всем, кто собирается стать аудитором и участвовать в конкурсах.

Первый шаг: Построчный аудит

Когда я только начинал заниматься аудитом, мой подход был чрезвычайно стандартным. Я проверял каждый контракт строка за строкой, понимая бизнес-логику, функцию за функцией.

На этом этапе я сосредоточился на том, чтобы понять, что делает каждая функция и как она вписывается в общую функциональность. Однако такой построчный подход, хотя и был тщательным, имел свои ограничения:

1. Пропущенные уязвимости: Некоторые ошибки, особенно сложные, связанные с кросс-функциональной логикой или логикой, основанной на состояниях, просто невозможно найти, используя только этот подход.

2. Трудности с восприятием общей картины: Сосредоточенность на отдельных строчках кода мешала понять более широкий дизайн контракта или то, как взаимодействуют различные части.

На этом этапе я развивал базовые навыки: понимая синтаксис, структуру и логику, лежащую в основе различных функций, но еще не разработал метод, позволяющий выявить некоторые более сложные или тонкие уязвимости.

На этом этапе было очень тяжело, потому что ресурсы для изучения solidity (не говоря уже об аудите) были крайне ограничены.

Второй шаг: Внедрение перехода между функциями и дифференциации состояний

На втором этапе я адаптировал свой процесс, чтобы устранить ограничения чисто построчного аудита. Я начал переходить от одной функции к другой, отслеживая, как различные функции связаны и взаимодействуют друг с другом. Этот переход помог мне лучше понять управление состоянием контрактов:

1. Лучшее понимание контекста: Понимая взаимосвязи между функциями, я смог выявить уязвимости при переходе от одного состояния контракта к другому.

2. Аудит на основе функциональности: Вместо того чтобы сосредоточиться на отдельных строках, я начал рассматривать функции как часть более широкого контекста. Это позволило мне обнаружить логические проблемы, возникающие при использовании функций вместе или в определенной последовательности.

Такой подход помог мне выявить больше ошибок и улучшил мою способность анализировать сложные взаимодействия функций. К этому моменту у меня сформировался более целостный взгляд на код, но способность эффективно выявлять теоретико-игровые проблемы или уязвимости в состояниях контракта все еще не была совершенной.

Третий шаг: Первоначальная оценка через разделение state

На третьем этапе я начал аудит с первоначальной оценки на основе состояний контракта. С приобретением опыта я обнаружил, что могу выявить потенциальные слабые места, просто составив карту различных состояний и взаимодействий:

1. Предварительная идентификация ошибок: Во время этой первоначальной оценки я уже мог находить ошибки, просто классифицируя и понимая состояния контракта. Процесс разделения и анализа этих состояний прояснил многие уязвимости с самого начала.

2. Распознавание паттернов и чувствительность: Опыт научил меня распознавать закономерности и определять области, которые могут содержать уязвимости. Определенные шаблоны кодирования или переходы состояний становились «красными флажками», и я интуитивно понимал, где искать. Не следует путать это с подбором шаблонов, чем в наши дни занимается большинство аудиторов.

Такое смещение фокуса позволило мне глубже понять динамику контракта, что облегчило обнаружение уязвимостей в более широкой логике, а не только в отдельных функциях. На этом этапе я начал выявлять более сложные ошибки и крайние случаи, особенно связанные с переходами состояний и чувствительностью переменных.

Четвертый шаг: Свободный аудит и лиды, основанные на интуиции