Как Google анализирует исполняемый код для поиска схожих файлов и выявления вариантов вредоносного ПО

Термины и определения

Assembly Language Source Code (Исходный код на языке ассемблера)

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

Code Block (Блок кода)

Фрагмент исполняемого кода. Executable Portion файла делится на последовательность таких блоков в точках изменения потока выполнения.

Code Manager (Менеджер кода)

Основная система, реализующая логику изобретения. Включает компоненты Block Builder (построитель блоков), Hasher (хешер) и Analyzer (анализатор).

Cryptographic Hash Function (Криптографическая хеш-функция)

Алгоритм (например, SHA-256), используемый для генерации необратимого хеша фиксированной длины (например, 256-бит). Идентичные блоки кода всегда имеют идентичный хеш.

Executable Portions (Исполняемые части)

Части файла, содержащие инструкции кода, которые выполняются процессором (машинный код).

File Database (База данных файлов)

Хранилище, где файлы хранятся не в исходном виде, а как последовательность хешей (Hashes), представляющих их Code Blocks.

Hash (Хеш)

Уникальная строка значений (дайджест) фиксированной длины, сгенерированная для Code Block.

Non-Executable Portions (Неисполняемые части)

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

Ключевые утверждения (Анализ Claims)

Claim 1 (Независимый пункт): Описывает основной метод определения сходства кода.

1. Система получает множество файлов.
2. Для каждого файла выполняется обработка:
   1. Идентификация Executable Portions.
   2. Разделение Executable Portions на Code Blocks.
   3. Генерация Hash для каждого Code Block.
   4. Сохранение файла в File Database как последовательности хешей.
3. Система получает запрос на проверку сходства первого файла с другими файлами в базе.
4. Система определяет, совпадает ли какой-либо Hash из последовательности первого файла с каким-либо Hash из последовательности любого другого файла.
5. Если обнаружено совпадение хеша между первым и вторым файлом, система генерирует ответ, указывающий, что второй файл похож на первый.

Claim 2 и 3 (Зависимые): Детализируют процесс разделения на блоки (Claim 2) и определяют критерии для этого разделения (Claim 3).

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

Claim 4 (Зависимый): Уточняет, что идентификация Executable Portions включает удаление по крайней мере одной Non-Executable Portion файла.

Claim 5, 8 и 9 (Зависимые): Уточняют характеристики хеширования. Хеш генерируется с фиксированной длиной (Claim 5). Используется Cryptographic Hash Function (Claim 8), например, генерирующая 256-битный хеш (Claim 9).

Claim 7 (Зависимый): Описывает важную возможность предварительной обработки.

Система может дизассемблировать файл из машинно-исполняемого кода (бинарного) в assembly language source code. Это позволяет сравнивать функциональность кода, даже если он был скомпилирован для разных процессорных архитектур.

Где и как применяется

Этот патент описывает технологию анализа файлов, которая не вписывается в стандартную архитектуру веб-поиска (Crawling, Indexing, Ranking), предназначенную для обработки веб-контента и ранжирования сайтов.

Это специализированная система анализа исполняемого кода, которая, вероятно, используется во внутренних инструментах Google, связанных с безопасностью и управлением кодом, таких как:

• Безопасность (Security Analysis): Анализ приложений в Google Play, вложений в Gmail или файлов, скачиваемых через Chrome (Safe Browsing), для выявления известных фрагментов вредоносного кода.
• Управление кодом (Code Management): Идентификация повторного использования кода или использования open-source библиотек.

Если рассматривать процесс в контексте общей обработки данных:

CRAWLING – Сканирование и Сбор данных
На этом этапе система получает файлы для анализа (например, файлы, собранные краулерами, специализирующимися на поиске бинарных файлов или приложений).

INDEXING – Индексирование и извлечение признаков
Основная работа системы. Block Builder анализирует файлы, извлекает исполняемый код и разбивает его на блоки. Hasher генерирует хеши (признаки файла). Эти признаки сохраняются в File Database.

Входные данные:

• Файлы, потенциально содержащие исполняемый код (например, бинарные файлы, приложения, библиотеки).

Выходные данные:

• Идентификация файлов, которые имеют сходство (т.е. содержат хотя бы один идентичный блок исполняемого кода).

На что влияет

• Конкретные типы контента: Влияет исключительно на файлы, содержащие исполняемый код (приложения, бинарные файлы, библиотеки DLL/SO). Не влияет на стандартный веб-контент (HTML, текст, изображения), если только он не используется для доставки исполняемого кода.
• Конкретные ниши или тематики: Применяется в нишах распространения программного обеспечения, кибербезопасности и анализа вредоносного ПО.

Когда применяется

• Условия работы: Применяется при необходимости сравнить функциональность двух или более файлов, независимо от их метаданных или ресурсов.
• Триггеры активации: Загрузка нового файла в систему для индексации или целенаправленный запрос (query) на анализ сходства конкретного файла с базой данных.

Пошаговый алгоритм

Процесс А: Обработка и сохранение файла (Индексация)

1. Получение файла: Система получает файл для анализа.
2. Идентификация и Фильтрация: Block Builder идентифицирует все Executable Portions. Non-Executable Portions удаляются или игнорируются.
3. (Опционально) Дизассемблирование: Если файл представлен в машинном коде, он может быть дизассемблирован в язык ассемблера.
4. Разделение на блоки: Block Builder анализирует поток выполнения инструкций. В точках изменения потока (например, переходы, ветвления) код разделяется на последовательные Code Blocks.
5. Хеширование блоков: Hasher обрабатывает каждый Code Block и генерирует для него криптографический Hash фиксированной длины.
6. Сохранение: Файл сохраняется в File Database как упорядоченная последовательность сгенерированных хешей.

Процесс Б: Анализ сходства (Обработка запроса)

1. Получение запроса: Система получает запрос на проверку сходства Первого Файла.
2. Сравнение хешей: Analyzer сравнивает каждый Hash из последовательности Первого Файла со всеми хешами всех других файлов в File Database.
3. Идентификация совпадения: Система проверяет наличие точного совпадения хешей.
4. Определение сходства: Если хотя бы один Hash Первого Файла совпадает с хешем Второго Файла, система определяет, что файлы похожи.
5. Генерация ответа: Система возвращает ответ (response), указывающий на сходство Первого и Второго файлов.

Какие данные и как использует

Данные на входе

Патент фокусируется исключительно на анализе структуры и содержания файлов.

• Технические факторы (Исполняемый код): Ключевыми данными являются последовательности инструкций в Executable Portions файла (машинный код или язык ассемблера). Анализируется поток управления кодом (Control Flow).

Все остальные типы факторов (контентные, ссылочные, поведенческие, временные, географические, пользовательские и т.д.) в данном патенте не упоминаются, не используются и/или явно исключаются из анализа (как Non-Executable Portions).

Какие метрики используются и как они считаются

• Hash Value: Основная метрика, вычисляемая для каждого Code Block. Используются криптографические хеш-функции (например, SHA256), генерирующие дайджест фиксированной длины (например, 256 бит).
• Сходство (Similarity): Бинарная метрика на уровне файла. Два файла считаются похожими, если у них есть хотя бы одно точное совпадение Hash Value. Патент не описывает расчет степени сходства (например, процент совпадающих блоков), только факт наличия сходства.

Патент является чисто техническим и описывает внутренние процессы Google для анализа кода, без прямых рекомендаций для SEO.

1. Фокус на исполняемом коде: Система целенаправленно игнорирует все неисполняемые части файла (ресурсы, метаданные), концентрируясь только на функциональной логике. Это обеспечивает устойчивость к методам обфускации, которые не затрагивают логику работы кода.
2. Гранулярный анализ: Сходство определяется на уровне отдельных блоков кода (Code Blocks), разделенных по логике выполнения, а не на уровне всего файла. Достаточно совпадения одного блока кода (одного хеша), чтобы система признала два файла похожими.
3. Эффективность и Масштабируемость: Использование криптографических хешей фиксированной длины позволяет быстро и эффективно сравнивать миллионы файлов на наличие идентичных фрагментов кода.
4. Кросс-архитектурный анализ: Возможность дизассемблирования машинного кода в язык ассемблера позволяет системе сравнивать код, скомпилированный для разных платформ.
5. Отсутствие связи с SEO: Механизмы, описанные в патенте, не имеют отношения к алгоритмам ранжирования веб-поиска, анализу контента веб-страниц, E-E-A-T, ссылочным или поведенческим факторам.

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

Best practices (это мы делаем)

В контексте SEO-продвижения сайтов прямые рекомендации на основе этого патента отсутствуют.

Если рассматривать патент в контексте безопасности сайтов (которая косвенно влияет на SEO):

• Мониторинг безопасности файлов: Если сайт распространяет программное обеспечение или исполняемые файлы, важно понимать, что Google обладает мощными инструментами для анализа этих файлов на предмет наличия вредоносного кода. Необходимо следить за чистотой распространяемых файлов, чтобы избежать санкций со стороны систем безопасности Google (например, Safe Browsing).

Worst practices (это делать не надо)

В контексте SEO-продвижения сайтов прямые рекомендации на основе этого патента отсутствуют.

В контексте безопасности:

• Распространение взломанного или вредоносного ПО: Попытки скрыть вредоносный код путем изменения метаданных или ресурсов файла неэффективны против описанной системы, так как она анализирует только исполняемую часть.

Стратегическое значение

Стратегическое значение для SEO минимально. Патент подтверждает высокий уровень компетенции Google в области статического анализа кода и обработки больших объемов данных для задач кибербезопасности. Это укрепляет понимание того, что системы безопасности Google (которые могут косвенно влиять на SEO через пессимизацию зараженных сайтов) используют сложные и гранулярные методы анализа.

Практические примеры

Практических примеров для SEO нет.

Технический пример работы системы (не SEO):

Сценарий: Обнаружение варианта вредоносного ПО

1. Файл А (Известное Вредоносное ПО): Содержит исполняемый код и ресурсы (иконка, текст). Система обработала его и сохранила как последовательность хешей H1, H2, H3. Хеш H2 соответствует вредоносной функции.
2. Файл Б (Новый Вариант): Злоумышленник взял Файл А, полностью изменил иконку и текст, но оставил вредоносную функцию без изменений.
3. Анализ Файла Б: Система игнорирует измененные ресурсы (Non-Executable Portions). Она анализирует исполняемый код.
4. Результат: Система генерирует хеши для Файла Б: H4, H2, H5.
5. Сравнение: Analyzer обнаруживает, что хеш H2 присутствует как в Файле А, так и в Файле Б.
6. Вывод: Система маркирует Файл Б как похожий на Файл А (Известное Вредоносное ПО), несмотря на внешние различия файлов.