Сага о викинге Эрланге. Высоконаучный брутфорс на практике

Николай Байбородин / www.dreamboss.ru /

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

Erlang: Стать подмастерьем

С языком Erlang я тебя познакомил, да вот беда, не успел рассказать, как программировать с его помощью. Чтобы постичь Дао Erlang программиста, тебе придется познать четыре великих секрета:

конкурентное программирование. Не заморачиваясь на нюан сах, можно сказать, что процесс написания конкурентного кода выглядит несколько сложнее, чем процесс написания традици онного последовательного кода. Зачастую приходится совмещать несовместимое — реализовать последовательный алгоритм, обеспечивая возможность его параллельного выполнения. То еще удовольствие, особенно при неправильном подходе. Большинс тво кодеров пытаются решить проблему в лоб — реализовать в одном программном модуле и параллельную, и последовательную обработку данных. Я покажу тебе, как правильно структурировать код, распределив его по двум модулям — один для параллельной обработки, а другой — для последовательной;
обработка ошибок. Ты уже понял, что в этом языке все делается через ж..., в смысле — не так, как в других языках программирования. Спешу тебя обрадовать: отстреливание и обработка ошибок — не исключение. Уф, какой лингвистический выверт у меня получился — errors exception is not exception!
процессы первичны, остальное вторично. Надеюсь, ты еще не забыл главную фишку Erlang’а, согласно которой все — процессы? Сегодня ты убедишься в этом на практике!
преднамеренное программирование. «Что за муть?», спросишь ты — а я отвечу: это такой стиль кодинга, при котором кодер, очнувшись от вчераш ней бурной вечеринки, не пытается постигнуть смысл бытия (написанного им же днем ранее кода). Ему не надо изо всех сил стараться понять, что же ему сегодня написать, чтобы чертов проект наконец-то пролез через компилятор, не выплюнув ни одной критической ошибки. Он просто садится и пишет, так, будто он просветленный Будда. Секрет кроется в том самом преднамеренном программировании, согласно которому уже написанный код определяет код, который должен быть написан. Кстати, фишка эта достаточно почтенного возраста. Erlang — функциональный язык. А какой функциональный язык круче Солнца и всех остальных языков програм мирования вместе взятых? Правильно — Lisp. И именно в Lisp’е впервые появилась идея программ, которые пишут другие программы (если тебе это интересно и ты намерен копнуть глубже — копай в сторону Lisp-макросов).

Конкурентное программирование

Давай вспомним матчасть — а именно, клиент-серверную архитектуру. На всякий случай, я со своим атрофированным чувством прекрасного попытался изобразить эту шведскую семейку на картинке («Три плюс один»). Модель клиент-сервер отличается от прочих тем, что в ней есть некий центральный узел (такой весь на распальцовке сервачок), к которому подключены несколько дремучих провинциалов-неудачников. Что им нужно от сервера? Очевидно, эти кровососы вовсю юзают один из его ресурсов. По максимуму упростив модель, всю выполняемую сервером работу можно представить в виде некоторой функции F. Теперь представь, что у нашего сервера есть несколько возможных состояний — State (упал под DDOSом, обрабатывает спам-лист, брутит пассы). Наш сервачок постоянно тревожат клиенты своими запросами (Query). Серверу не позавидуешь, потому что пока он жив, он обязан отвечать на все поступившие запросы (Replay), поменяв свое текущее состояние со State на State 1. Все это можно сжато и емко выразить с помощью синтаксиса Erlang:

{State1, Replay} = F(Query, State)

А теперь перейдем от теории к практике — напишем свой первый сервер:

-module(server1). -export([start/3, stop/1, rpc/2]). start(Name, F, State) -> register(Name, spawn(fun() -> loop(Name, F, State) end)). stop(Name) -> Name ! Stop. rpc(Name, Query) -> Name ! {self(), Query}, receive {Name, Replay} -> Reply end. loop(Name, F, State) -> receive stop -> void; {Pid, Query} -> {Reply, State1} = F(Query, State), Pid ! {Name, Replay}, loop(Name, F, State1) end.

Страшно? А никто и не обещал, что сбрутить пассы через распределенку будет легко. Это тебе не формочки в дельфях клепать. Но на самом деле, разобраться вполне реально. Клиент осуществляет RPC-запрос (строки с 13 по 17), отправляя сообщение серверу (строка 14) и ожидая от него ответ (строки с 15 по 17). Сервер получает посланный клиентом запрос (строка 23), формирует ответ и, меняя свое состояние, прокручивает ответ через хвостовую рекурсию (строка 26). Почему я выбрал именно этот пример с клиент-серверной архитектурой? Потому что он неплохо иллюстрирует хорошо распараллеливаемый алгоритм — для обработки каждого запроса запускается свой поток. Теперь допустим, что наш сервер нужно обвесить разными рюшечками, не предполагающими параллельной обработки: например, написать функцию, которая будет сбрасывать сбрученный пароль в текстовик. Это будет уже последовательная операция (пока пароль не найден — в файл лить нечего) и глупо пихать ее в один модуль с распараллеленным алгоритмом. Логичнее создать новый модуль, подключив к нему те, что поддаются распараллеливанию:

— import (server1, [start/3, stop/1, rpc/2]). — import (dict, [new/0, store/3, find/2]).

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

Сапер ошибается дважды

Пользуясь случаем, хочу передать пламенный привет сишным кодерам, отстрелившим себе не только обе ноги, но и то, что так мешало им танцевать полечку на костях функциональной парадигмы программирования. Среди парней, что паяют компьютерное железо в промышленных масштабах в ходу термин «fault-tolerance». Это же понятие можно встретить в идеологии Erlang’a. Сравни два фрагмента кода:

rpc(Name, Query) -> Name ! {self(), Query}, receive {Name, crash} -> exit(rpc); {Name, ok, Replay} -> Reply end.

И второй вариант:

case (catch F(Query, State)) of {'EXIT', Why} -> log_error(Name, Query, Why), From ! {Name, crash}, loop(Name, F, State); {Replay, State1} -> From ! {Name, ok, Replay}, loop(Name, F, State1) end.

Надеюсь, ты уже успел заметить ключевые отличия первого фрагмента от второго, встретив там до боли знакомое словечко catch. Но не будем торопиться и рассмотрим обработку ошибок в Erlang по шагам.

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

Получается интересная штуковина: RPC как бы подчиняется транзакционной семантике, которая в свою очередь определяется состоянием сервера — если состояние сервера изменилось, значит, все ОК. Если нет — случился страшный писец и нужно срочно принимать меры по спасению вселенной от последствий роковой ошибки. Приведенная схема прекрасно работает в том случае, если нужно урезонить клиентов, отправляющих серверу невменяемые запросы. А теперь представь такую ситуацию: клиент отправляет серверу корректный запрос и вполне на законных основаниях ожидает от него ответ. Тем временем наш сервер лежит без чувств, сраженный безжалостным DDOSом. Чтобы такое ожидание не длилось вечно, нужно предусмотреть возможность отстрела ошибок и на стороне клиента:

rpc(Name, Query) -> Name ! {self(), Query}, receive {Name, crash} -> exit(rpc); {Name, ok, Reply} -> Reply after 10000 -> exit(timeout) end.

Думаю, решение очевидно. За исключением одного маленького, но принципиального вопроса — как долго ждать ответ от сервера, прежде чем начинать паниковать? Ткнув пальцем в небо, я написал: десять тысяч миллисекунд. При грамотном подходе (если ты хочешь показать кому-то всю свою невозможную крутость) клиент вовсе не должен проверять работоспособность сервера. Не барское это дело! Для такого случая, согласно идеологии Erlang, нужно создать отдельный процесс (перевожу на русский — написать отдельный программный модуль), называемый гипервизором (Hypervisor). Задача гипервизора состоит в том, чтобы с заданной периодичностью проверять состояние сервера и сообщать о нем клиентам.

Чужие секреты

Ты уже достаточно много знаешь о языке программирования Erlang. Не исключено, что у тебя уже появились свои собственные идеи, как можно было бы организовать систему распределенного брутфорса. Но один вопрос по-прежнему не раскрыт, и возможно, не дает тебе спокойно заснуть с любимым журналом под подушкой. Собственно, это вопрос о том, каким образом можно реализовать криптографические инструменты средствами Erlang. Не волновайся, как говаривала добрая бабушка в одном бездарном российском блокбастере. Среди разнообразных библиотек, поставляемых вместе с самим языком, криптографических инструментов присутствует достаточно. Как решать с помощью этих инструментов конкретную задачу, ты и сам прекрасно разберешься, покурив хорошенько документацию. Я, в силу ограниченного журнального пространства, покажу тебе лишь общее направление на простом примере использования алгоритма MD5. На всякий случай напомню, что алгоритм MD5 для своего аргумента вычисляет уникальное 32-разрядное число (обычно представляемое в шестнадцатеричной нотации). Для вычисления MD5 в Erlang есть специальная встроенная функция, возвращающая хэш в виде структуры чисел:

>erlang:md5("hello"). <<93,65,64,42,188,75,42,118,185,113,157,145,16,23,197 ,146>>

Однако, это не совсем то, что мы привыкли видеть, и не совсем то, что мы ожидаем получить от функции md5()! Чаще всего результат работы алгоритма MD5 фигурирует в виде шестнадцатеричной строки. Поэтому после вычисления значения хэш-функции есть смысл воспользоваться функцией конвертирования binary_to_list():

>binary_to_list(<<93,65,64,42,188,75,42,118,185,113,15 7,145,16,23,197,146>>). [93,65,64,42,188,75,42,118,185,113,157,145,16,23,197, 146]

Следующий шаг — преобразование каждого целого числа в списке в его шестнадцатеричный эквивалент. Как бы ты это сделал, не имея под рукой компьютера? С помощью разложения на множители по модулю 16! Реализация этого алгоритма на любом языке — задача для школьника. Такое преобразование нужно выполнить для каждого элемента списка. Я бы тебе порекомендовал воспользоваться для этого стандартной функцией lists:map, пропустив через нее преобразование каждого десятичного числа к его шестнадцатеричной нотации:

> lists:map(fun(X) -> int_to_hex(X) end, L).

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

— module(md5). — export([md5_hex/1]). md5_hex(S) -> Md5_bin = erlang:md5(S), Md5_list = binary_to_list(Md5_bin), lists:flatten(list_to_hex(Md5_list)). list_to_hex(L)-> lists:map(fun(X) -> int_to_hex(X) end, L). int_to_hex(N) when N < 256 -> [hex(N div 16), hex(N rem 16)]. hex(N) when N < 10 -> $0+N; hex(N) when N >= 10, N < 16 -> $a + (N-10).

И — результат работы:

>md5:md5_hex("hello")."5d41402abc4b2a76b9719d911017c592"

Finita la comedia

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

Главное в Erlang — его модель легковесных процессов. Пере- фразируя для Erlang слоган текущего дня — «Everything is an object» («Все является объектом»), можно сказать: «Everything is a process» («Все является процессом»). Процессы дешевы, а их создание занимает не больше ресурсов, чем вызов функции. Единственным способом взаимодействия процессов является асинхронный обмен сообщениями.

Процесс при желании может или установить связь (link) с другими процессами (по выбору), или получить сообщение об их смерти с указанием причины, или разделить их участь. Процесс имеет свой «почтовый ящик», откуда может выборочно читать сообщения. В этом очень помогает сопоставление по шаблону; код проверки «ящика» чем-то похож на программу awk. Нужное выгребается и обрабатывается, остальное остает- ся или выбрасывается.