Привет, Хабр. На пороге Новый год. Как всегда в конце года хочется понять, а чем же был для нас, компании Smart Engines, год уходящий? Продуктивным - да, и бизнес-результаты, и научные достижения, и технологии - как игрушки на елке - радуют. А где же игрушки - спросите вы и будете правы. Ведь один их сверкающий вид открывает двери празднику. А ниже они обязательно будут. Сегодня мы поделимся с вами нашим взглядом на 12 месяцев, а поможет в этом наш STE. Тот самый продукт для томографической реконструкции, над которым мы не устаем трудиться, дополняя, стабилизируя и запуская, как проходческий щит, в неосвоенные туннели условий томографической съемки.

Результат наших трудов покажем на томографии 12 объектов, каждый из которых символизирует один из 12 месяцев года. Да-да, интересная задача перед нами стояла в декабре - собрать 12 объектов, сфотографировать, сделать томографию и соорудить календарь из них. Кстати, и ты, дорогой читатель, можешь стать обладателем календаря от Smart Engines, но обо всем по порядку!

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

В нашем проекте PT Application Inspector реализовано несколько подходов к анализу исходного кода на различных языках программирования:

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

Наш цикл статей посвящен структуре и принципам работы модуля сигнатурного поиска (PM, pattern matching). Преимущества такого анализатора — скорость работы, простота описания шаблонов и масштабируемость на другие языки. Среди недостатков можно выделить то, что модуль не в состоянии анализировать сложные уязвимости, требующие построения высокоуровневых моделей выполнения кода.

К разрабатываемому модулю были, в числе прочих, сформулированы следующие требования:

• поддержка нескольких языков программирования и простое добавление новых;
• поддержка анализа кода, содержащего синтаксические и семантические ошибки;
• возможность описания шаблонов на универсальном языке (DSL, domain specific language).

В нашем случае все шаблоны описывают какие-либо уязвимости или недостатки в исходном коде.

Весь процесс анализа кода может быть разбит на следующие этапы:

1. парсинг в зависимое от языка представление (abstract syntax tree, AST);
2. преобразование AST в независимый от языка унифицированный формат;
3. непосредственное сопоставление с шаблонами, описанными на DSL.

Данная статья посвящена первому этапу, а именно: парсингу, сравнению функциональных возможностей и особенностей различных парсеров, применению теории на практике на примере грамматик Java, PHP, PLSQL, TSQL и даже C#. Остальные этапы будут рассмотрены в следующих публикациях.