В очередном обновлении Elcomsoft Distributed Password Recovery (EDPR) была переработана функция, которая распределяет нагрузку на локальные вычислительные ресурсы каждой рабочей станции. Точечные изменения алгоритма распределения нагрузки привели к существенному сокращению времени перебора — при том, что ни видеокарты, ни процессоры не стали работать быстрее. О том, как нам удалось этого добиться — в сегодняшней статье.

Как работает ускорение на видеокартах (и почему объём данных критически важен)

О том, что такое и как работает ускорение перебора паролей на видеокартах, мы писали не раз и не два. Основной принцип в том, что рутинные вычисления переносятся с процессорных ядер (которые очень мощные, но их мало) на вычислительные модули видеокарты. Каждый вычислительный модуль в отдельности довольно медленный, зато их много: так, в видеокартах семейства NVIDIA RTX 4080 Super число вычислительных ядер CUDA —  10,240, а, скажем, в NVIDIA RTX 4070 Super число ядер CUDA — 7,168. Соответственно, если каждое ядро видеоускорителя загрузить проверкой собственного варианта пароля, мы получим возможность параллельного перебора многих тысяч паролей.

У вычислительных ядер видеокарт есть ряд особенностей, которые делают их малопригодными для традиционных вычислений, но практически идеальными — для задач, способных к массовому распараллеливанию. Для нас важны две особенности. Первая: в отличие от универсальных ядер центрального процессора, все однотипные (не будем вдаваться в разницу между ядрами CUDA и, к примеру, тензорными вычислителями; для наших задач пригодны лишь первые) ядра видеокарты могут выполнять только одну задачу в каждый момент времени. И вторая особенность: если на вход видеокарты с 10,000 вычислительных ядер мы подадим для проверки пачку из 10,000 паролей, работа завершится ровно за то же время, как если бы мы подали всего один пароль. Таким образом, нам выгодно подавать на видеокарту пачку, объём которой в точности совпадает с числом доступных вычислительных ядер.

Теперь представим, что в нашем компьютере установлена не одна, а две видеокарты: NVIDIA RTX 4080 Super с 10,240 вычислительными ядрами и NVIDIA RTX 4070 Super, в которой число ядер — 7,168. Задача планировщика, в роли которого в рамках архитектуры EDPR выступает приложение-агент, сбалансировать нагрузку. В простейшем случае (а поддержка гетерогенных вычислений появилась в продукте несколько лет назад) планировщик делит пачку паролей, поступившую на проверку, строго пропорционально числу вычислительных ядер: на видеокарту 4080 Super будет подано 10,240 паролей, а на карту 4070 Super — ровно — 7,168.

Звучит логично? Да, но есть две проблемы. Во-первых, вообще без балансировщика нагрузки размер пачки паролей, который агент получает на проверку от сервера, не будет равен 10240+7168=17408; скорее, он получит пачку статичного размера или пачку, размер которой вычисляется исходя из числа ядер путём поиска общего множителя. В этом месте возникают накладные расходы: первые пять итераций каждая видеокарта получит ровно столько паролей, сколько она способна «переварить» за один такт, но в последнюю, шестую итерацию от пачки останется всего 12,960 паролей. Обращаем внимание: это меньше, чем то число, которые способны принять на обработку видеокарты, но время на такт будет затрачено ровно такое же, как на обработку при полной загрузке (см. выше вторую особенность работы видеокарт).

Таким образом, в этом месте возникает возможность оптимизации, если сделать объём каждой пачки пропорциональным возможностям видеокарт с учётом накладных расходов. Однако, не будем спешить; на самом деле такой подход работает лишь в случаях, когда в системе установлен или единственный ускоритель, или несколько одинаковых видеокарт (в скобках заметим, что идентичных видеокарт на практике не встречается; некоторые экземпляры на практике работают быстрее других, что создаёт погрешность). В случае гетерогенных вычислений с использованием нескольких разных моделей ситуация выглядит сложнее.

Следующей проблемой является разная скорость видеокарт даже в рамках одного поколения. В описанном выше примере ядра 4080 Super работают на частоте 2295 МГц, а ядра 4070 Super — 1980 МГц. Соответственно, свою часть работы карта 4080 Super завершит раньше, чем карта 4070 Super.  Таким образом, у планировщика будет выбор: подавать следующую часть пачки по расписанию (то есть, придётся дождаться, пока более медленная видеокарта завершит обработку) или сразу. Если делать по расписанию, то определённую часть времени более мощная видеокарта будет простаивать, что заметно уменьшит общую производительность системы. Если же новую порцию работы выдавать сразу, то ближе к концу пачки у нас снова останется «хвост» — то есть, такое количество паролей, которое сможет загрузить видеокарты лишь частично. Поскольку мы не можем заранее точно предсказать относительную производительность каждой видеокарты, оставшийся «хвост» из «нечётного» числа паролей в пачке является в данном случае меньшим злом.

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

Вычислитель — это всегда видеокарта?

Нет. Вычислителями являются как видеокарты, так и ядра, встроенные в процессоры в качестве интегрированной графики, так и сами универсальные процессорные ядра. Более того, целый ряд форматов не поддаётся ускорению на видеокарте (сюда относятся либо очень старые форматы, которые и центральный процессор способен перебирать с огромной скоростью, либо новые, специально созданные для противодействия такому виду атак). Такие данные обсчитываются средствами центрального процессора и только его.

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

Отрыв в производительности видеокарт от скорости центральных процессоров огромный. В статье Ломаем пароли на том, что осталось от майнеров мы исследовали скорость перебора на центральных процессорах, встроенных графических ядрах и слабых дискретных видеокартах, а в статье NVIDIA RTX 40 Series: выбор актуальной модели для перебора паролей привели бенчмарки актуальных ускорителей. На графиках ниже наглядно показана разница в скорости перебора хэш-функции SHA-256 на нескольких моделях центральных процессоров, встроенных и дискретных видеокарт.

Так, скорость перебора видеокарты NVIDIA GeForce RTX 4070 Ti — порядка 9 миллиардов паролей в секунду, а центральный процессор Intel i7-12700 может перебирать всего около 50 миллионов хэшированных паролей в секунду. Разница — в 180 раз. Таким образом, подключив к перебору центральный процессор в качестве дополнительного вычислителя, мы увеличим теоретическую вычислительную мощность на пренебрежимо малую величину в 0.55%, зато общее энергопотребление системы (а следовательно — и требования к охлаждению как отдельной рабочей станции, так и всего помещения) возрастёт почти на треть. При этом рост накладных расходов и лишнее тепло в корпусе не просто нивелируют пренебрежимо малый прирост производительности, но и заметно снизят общую реальную производительность системы. Использование встроенных видеоускорителей несёт примерно те же последствия, но в несколько смягчённом виде из-за пониженного в сравнении с процессорными ядрами энергопотребления и более высокой (относительно центральных процессоров) производительности.

В целом, подключать к перебору встроенные графические ядра и ядра центрального процессора стоит в исключительных случаях: либо тогда, когда и скорость дискретной видеокарты невысока, либо в случаях, когда формат данных плохо совместим с графическим ускорением — в частности, для таких популярных форматов, как VeraCrypt (при использовании смешанных алгоритмов шифрования) или OpenDoc. Если выразиться более точно, то центральный процессор имеет смысл подключать к перебору, только когда это даёт выигрыш в производительности. Однако понять, будет ли выигрыш, непросто, т.к. приходится учитывать сразу несколько неизвестных: скорость CPU, скорость GPU и скорость работы на них конкретного алгоритма. В алгоритме же влиет и то, может ли он выполняться только на GPU или требует предварительных вычислений на CPU (желательно достаточно мощном). Наконец, центральные процессоры остаются незаменимыми для тех форматов, которые невозможно ускорить на GPU.

В реальных условиях постоянно помнить о том, какие именно ядра (и когда именно!) нужно или не нужно подключать — тяжело. Новая функция балансировки нагрузки решает и эту задачу. Отдельная большая тема — использование ядер CPU для подготовки пачек паролей при использовании словарей, мутаций, масок и гибридных атак. Сбалансировать использование ресурсов процессора для решения этих задач с производительностью видеокарт — отдельная и сложная техническая задача.

Балансировка нагрузки

Итак, с проблемой мы ознакомились; с тем, как она решается «в лоб» — тоже. Наконец, мы подошли к главному: в новой версии Distributed Password Recovery 4.70 мы полностью переработали алгоритм балансировки, максимально уменьшив вероятность простоя видеокарт и сократив накладные расходы до теоретически возможного минимума. Новый алгоритм балансировки нагрузки учитывает не только количество вычислительных ядер, но и оценивает их производительность, что позволяет более точно распределить задачи по вычислителям разной архитектуры; приоритет всегда отдаётся более быстрому вычислителю, а не менее загруженному. Всё вместе привело не только к повышению утилизации имеющихся ресурсов, но и, с учётом разницы в производительности различных вычислителей, позволило значительно сократить число ситуаций, когда время простоя вычислителей является не оптимальным.

Заключение

Распределение задач и балансировка нагрузки — невидимые, но очень важные компоненты любой системы восстановления паролей, которая работает более чем с одним вычислителем. В новой версии Elcomsoft Distributed Password Recovery мы значительно улучшили производительность и удобство работы с программой. Благодаря глубокой оптимизации ядра и переработке алгоритмов распределения вычислительных задач, система теперь более эффективно использует ресурсы, минимизируя простои и устраняя мелкие проблемы, которые могли создавать неудобства пользователям. Это обновление — шаг к максимально эффективной и стабильной работе даже при сложных задачах, позволяя специалистам сосредоточиться на результатах, а не на настройке и поддержке оборудования.