книги хакеры / журнал хакер / 143_Optimized

Так выглядит сдампенная таблица импорта с перезаписанным массивом FirstThunk

Сам массив заканчивается структурой IMAGE_IMPORT_ DESCRIPTOR, все поля которой равны нулю.

Из всех полей этой структуры нас интересует интересуют только два:

•Name — указывает на строку с именем библиотеки;

•FirstThunk — указывает на массив структур IMAGE_THUNK_ DATA32.

Остальные поля могут быть пустыми.

Структура IMAGE_THUNK_DATA32 имеет следующий прототип:

struct IMAGE_THUNK_DATA32 { union {

DWORD ForwarderString; DWORD Function;

DWORD Ordinal; DWORD AddressOfData;

} u1;

}

Единственное поле этой структуры указывает на строку с именем импортируемой функции за вычетом двух байт (в них хранится ординал функции). Заканчивается массив нулевым элементом.

Когда происходит загрузка PE-файла, загрузчик разбирает массив структур IMAGE_IMPORT_DESCRIPTOR, загружает в память процесса соответствующие библиотеки (находит их по полю Name)

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

Почему сдампенный импорт не работает?

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

запускаться как самостоятельный exe-файл. В чем причина? В дампе таблица импорта выглядит примерно так, как показано на рисунке. Тебя не смущает значение поля ThunkValue? Оно ведь вроде как должно указывать на имя импортируемой функции. На самом деле произошло следующее: когда мы запустили зацикленную упакованную программу с целью снять с нее дамп памяти, загрузчик переписал содержимое массива FirstThunk адресами импортируемых функций, а дампер снял дамп памяти, как он есть. То есть сейчас содержимое массива FirstThunk указывает не на имя (или ординал) импортируемой функции, а на ее непосредственный адрес. Что происходит при попытке запустить этот файл на исполнение?

Происходит следующее:

1)Загрузчик по массиву DataDirectory находит таблицу импорта;.

2)Из структуры IMAGE_IMPORT_DESCRIPTOR извлекает имя загружаемой библиотеки и адрес массива FirstThunk;.

3)Анализируя массив FirstThunk, загрузчик, в надежде найти имя импортируемой функции, обращается по адресу, указанному в этом массиве, и находит там… невыделенную область памяти (сама библиотека загружается позже), обращение к которой вызывает исключение access violation, с последующим обламыванием всего процесса загрузки и выводом соответствующего ругательного сообщения.

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

Реконструкция импорта

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

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

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

В этом случае порядок действий такой: встаем отладчиком в начало распаковщика и смотрим, какая из двух таблиц присутствует в памяти (таблица импорта конечной программы еще не

ВЗЛОМ

Список импортируемых API-функций виден невооруженным глазом

распакована, поэтому в памяти ее нет). В 99,9 % случаев список импортируемых функций виден, что называется, невооруженным глазом в любом HEX-редакторе. Если же функции импортируются по ординалам, то получить полный список импортируемых функций не так просто. Проблема усугубляется тем фактом, что имеющиеся ординалы оказываются затертыми адресами функций. В этом случае единственным способом обнаружения функций является нахождение массива FirstThunk по записанным в нем адресам. Как ты знаешь, все PE-файлы имеют так называемый базовый адрес загрузки. Виртуальный адрес функции рассчитывается путем сложения этого базового адреса и относительного виртуального адреса функции. Так вот, на системах без ASLR этот базовый адрес постоянен, а при ASLR постоянен только его старший байт. Поскольку RVA адреса меньше 01000000h, то старший байт постоянен для данной библиотеки. Этим мы и воспользуемся для поиска импортируемых функций. Последовательность действий при этом такая:

1)Определяем используемые библиотеки (их имена хранятся в дампе открытым текстом и видны невооруженным глазом).

2)Находим для них старший байт базового адреса загрузки

(например, для библиотеки user32 — 7Eh).

3)Ищем в снятом дампе вхождения этого дампа; цепочка таких байтов с шагом 4h и будет основным признаком массива

FirstThunk.

Резонно возникает вопрос: «А почему для поиска функций не воспользоваться API-монитором?». Дело в том, что при анализе дампов многократно упакованной программы мы можем «промахнуться». Поясню на примере: пусть у нас есть какая-то программа, ее упаковывают пакером A, затем пакером B, ну и на погоны — пакером C. Предположим, что мы снимаем пакер C, соответственно, нам нужны функции, используемые B. API-монитор не различает, кто вызывает функцию — упакованная программа или кто-то из распаковщиков. Поэтому мы вполне можем впасть в заблуждение

иначать восстанавливать таблицу импорта основной программы, не сняв всех пакеров, что ни к чему хорошему нас не приведет. Другой вариант поиска массива FirstThunk основан на так называемом «переходнике». Дело в том, что в большинстве программ API-функции вызываются не напрямую, а через так называемый «переходник», который представляет из себя простую команду jmp на вызываемую функцию (при этом направление, куда «прыгать», берется из массива FirstThunk). Пример такого «переходника» представлен на рисунке.

Данный «переходник» выдает нам массив FirstThunk со всем его содержимым.

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

1)Находим место вызова любой библиотечной функции. Наиболее

Цепочка байтов 7Eh с шагом 4h демаскирует FirstThunk

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

2)Определяем, откуда берется адрес вызываемой функции. Если речь идет не о неявном вызове API-функций через ручной расчет их адресов (что встречается крайне редко), то браться он будет из массива FirstThunk. Выглядеть он будет примерно так, как показано на рисунке. При этом здесь перед нами будут адреса всех импортируемых функций из разных библиотек. То есть перед нами не один, а несколько массивов FirstThunk (каждый из них соответствует своей библиотеке), разделенных между собой нулевым двойным словом.

3)Осталось лишь сопоставить адреса, записанные в этот массив, с соответствующими им функциям. Сделать это можно прямо в отладчике.

Создание таблицы импорта

После того, как у нас на руках окажется вся необходимая информация, мы можем приступить к созданию (именно «созданию», потому что после распаковки массив структур IMAGE_IMPORT_DECRIPTOR исходного приложения полностью отсутствует) таблицы импорта.

Сам этот массив может быть размещен в любом месте программы, доступном на чтение. Разместим его по адресу 2040h (за массивами FirstThunk). Пропускаем первые Ch байт (в них идут первые три поля IMAGE_IMPORT_DESCRIPTOR, которые мы не будем заполнять). По адресу 204Ch пишем адрес строки «kernel32.dll» (находим ее в дампе или создаем самостоятельно). В следующие 4 байта записываем найденный адрес массива FirstThunk с функциями из библиотеки kernel32 (у нас 2000h). Теперь перезаполняем массив FirstThunk (напоминаю, что каждый элемент этого массива представляет собой двойное слово, содержащее адрес строки с именем функции, за вычетом двойки). В нашем примере первый элемент содержит адрес функции GetModuleHandleA, строка с ее именем размещена по адресу 5009h, вычитаем 2, получаем 5007h. Это значение и пишем в массив FirstThunk.

Именно по такому принципу мы и восстановим всю таблицу импорта. Самое главное при этом — не потереть важные для программы данные (строки, ресурсы, переменные). Поэтому располагать таблицу импорта лучше всего в области, состоящей из нулей. Вообще, для размещения массива IMAGE_IMPORT_DESCRIPTOR (массив FirstThunk и имя библиотеки у нас уже есть), описывающего N библиотек, нужно (N+1)*14h байт памяти.

Нам осталось только изменить адрес таблицы импорта в массиве DataDirectory и наслаждаться приложением с восстановленной таблицей.

Ресурсы

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

Переходник, через который и осуществляется вызов API-функций

двух или более секциях (кстати, хороший способ спрятать ресурсы от любопытных), а в снятом дампе они расположены именно так. На работоспособность снятого дампа это никак не влияет, так как таблица ресурсов полностью исправна и указывает на имеющиеся ресурсы. Убедиться в этом можно с помощью LordPE. Если же тебе кровь из носу нужна возможность редактирования ресурсов, то воспользуйся программой Resource Binder, которая создает новую секцию и помещает в нее все найденные ресурсы.

Определяем имя функции по ее адресу

LordPE показывает нам структуру ресурсов и их RVAадреса

ВЗЛОМ

Алексей Синцов, Digital Security a.sintsov@dsec.ru

Работа…

Если ты в будущем хочешь связать свою жизнь с ИБ, то у тебя есть множество путей реализации этой затеи. Конечно, ты столкнешься со многими препятствиями, начиная от разного понимания, что такое «ИБ», у тебя и у «босса», заканчивая тем, что в итоге, если ты хочешь генерировать ключи по ГОСТу или разбираешься в бумажках от ФСТЭК по персональным данным, то работы полно, а если ты любишь «техническую» работу, то предложений уже не так много,

и скорее всего все закончится вакансией системного администратора или программиста (хорошо, если с уклоном в ИБ). Конечно, все это я говорю о легальной, законной работе, ведь заниматься «грязью» — это для нас как переход на Темную Сторону Силы… Благодаря стандарту PCI DSS, который приподнял рынок пентестов в стране, шанс найти работу в этом направлении есть, однако я хочу поговорить о другом. Вопрос поиска работы в области ИБ достаточно индивидуален и зависит от интересов и возможностей соискателя. Поэтому я буду говорить о тех, в чьи интересы входит

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

Баг-хантинг

У баг-хантера три пути развития (на мой скромный взгляд): Вариант 1. НТП/НИИ/НПО имени кого-то там при чем-то там. Да-да. В принципе, кибер-война — это уже не шутки, и нашей стране нужно все то же самое, что и МОССАДу с ЦРУ. Поэтому багхантер и эксплойт-райтер — полезный человек. Так как в ФСБ просто так не попасть, можно найти работу в каком-либо учреждении, которое работает, выполняя заказы «сами-знаете-кого». Уверен, что они там делают полезную и важную работу :). Попасть туда можно из универа (если кафедра соответствующая), по «протекции» или при внимательном поиске работы. В принципе, и в само ФСБ после такого универа попасть реально (после года собеседований

итестов получишь офицерскую ЗП и командировки раз в год черт знает куда, и не факт, что тебе дадут ту работу, которую хочешь ты).

Вариант 2. Блэк-Хат.

Если вариант 1 был для любителей милитаризма и шлема ДартаВейдера, то данный вариант для любителей рискнуть свободой

издоровьем :). Эксплойт-паки нуждаются в пополнении новыми зеро-деями, и если у тебя есть связи, то ты легко можешь продать свежую багу/эксплойт (0day) кому надо за много-много $$$. Этот вариант я не поддерживаю, и потому не жди никаких деталей. К тому же, кто захочет, сам найдет и освоит эту дорогу; только помни, как опасен и коварен путь Темной Стороны...

Вариант 3. Свободная продажа.

В мире существует множество фирм, которые с удовольствием купят

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

Рынок 0day

Существует множество компаний, которые хотят купить у тебя 0day. Процедура покупки может отличаться, но примерно суть одна и та же. О ней мы поговорим чуть позже, а пока рассмотрим рынок на основе опроса от unsecurityresearch.com. Результат показывает, что в среднем за 0day-уязвимости на клиентской стороне можно получить от 1000/2000 долларов. Это средняя цена, потолок же может доходить и до 30000 долларов. Зависит от того, в каком продукте обнаружена проблема. Из всех компаний, покупающих уязвимости, наиболее высокий средний показатель у ребят из ZDI (Zero Day Initiative — zerodayinitiative.com), где большинство клиентских уязвимостей в промежутке от одной до трех тысяч долларов. Кроме того, ZDI сохраняют авторство в публикации, и когда инфа выходит в

Твиттер-лента от ZDI

паблик, твое имя не сотрется (если ты сам этого не желаешь). Кроме прочего, ZDI (а вернее, компания TippingPoint, основатели ZDI) являются спонсорами ежегодного конкурса PWN to OWN на CanSecFest, и именно они платят призовые фонды за взлом браузеров. Так что лично я для себя выбрал работу именно с этими парнями.

ZDI

Фактически TippingPoint является «подразделением» компании 3COM (а те, в свою очередь, продались Hewlett-Packard) и занимается разработкой системы IPS, в которую они и включают сигнатуры от купленных ими 0day-проблем. Фактически сигнатура в их IPS появляется задолго до того, как выйдет патч. Кроме того, ZDI уведомляет разработчика и проходит полный цикл от уведомления до ожидания патча и скоординированной публикации о проблеме. До того, как информация станет доступной, ZDI может делиться деталями проблемы с партнерами-вендорами решений по защите информации. Таким образом, продав 0day-багу ZDI, ты помогаешь всем владельцам железки TippingPoint защититься от потенциальной угрозы. Но хватит рекламы, рассмотрим, каким же образом поднять лавэ.

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

СточкизрениястатьиУКРФ273 анализбинарногокодасанализом уязвимостинеявляетсяПО, иужтемболеевредоносным. Несмотря нато, чтоэтаинформацияпозволяетнаписатьэксплойтиличервь, закономтакаяинформациянеописывается, поэтомупродажаZDI такойинфы— делонепреступное. Болеетого, PoC-эксплойт, например, длябраузера, которыйзапускаеткалькуляторипредупреждает обэтомпользователя, такжевредоноснымкодомнесчитается(запусккалькулятора— этожнеопасно, нопомни, что«эксперты» унас встранемогутвообщенеразбиратьсявпредмете).

КомпанияNSS анонсировалаоткрытиепортала-аукционадля пен-тестеровиэксплойт-девелоперов. Наэтомпорталеэксплойт- райтерымогутпродаватьэксплойтыкне-0day-уязвимостямвфор- матемодулейдляMetasploit. Никтонезнает, выживетлиэтаидея, но проектстоитоценить, откроетсяонужескоро.

Компаний, которыехотяткупитьутебяуязвимости, достаточно много; помимоZDI всписоквходяттакиеконторы, какiDefense — labs.idefense.com, SecuriTeam — securiteam.com илиNetraGard — netragard.com. Кромепрочего, уязвимостивбраузерахFireFox или Google Chrome можнопродатьсамимвендорам. Правда, думается мне, чтозаcode execution большеможновыручитьутехжеZDI.

ВЗЛОМ

ленных знаний и навыков, а иногда даже и чутья с везением. Но, как бы то ни было, про поиск уязвимостей уже написано немало букв. Вспомни хотя бы мою статью в апрельском ][ про эксплуатацию брешей в ActiveX-компонентах. Итак, как найти уязвимость более-менее понятно, но не рвись в бой, сначала надо определиться с жертвами. Очень большое значение имеет, ГДЕ именно найдена уязвимость. ZDI четко описывает требования к багам, которые они готовы купить:

•Удаленные уязвимости, связанные с выполнением кода

•Уязвимости, связанные с парсингом доверенных файлов

•Уязвимость должна быть в последней версии релиза ПО

•Уязвимое ПО должно быть широко распространено

Это значит, что можно забыть про XSS-, LFI- и SQL-инъекции в популярных движках. Нас интересует настоящая жесть вроде ошибок с указателями, переполнения буфера, ошибки формата строки внедрение команд и прочих багов, которые приводят к выполнению произвольного кода. Нас интересуют знаменитые FTP/веб-сервера, базы данных, системы бэкапа, а также браузеры, ActiveX и плагины популярного ПО для браузеров, ПО корпоративных систем и т.д. В этот список могут входить как платные, так и опенсорсные продукты, главное, чтобы они были популярны и широко распространены. Ну вот, собственно, и все... А вот и не все. На самом деле найти уязвимость — это зачастую задача более простая, нежели проэксплуатировать ее. Поэтому надо показать, что найденная тобой уязвимость реально опасна. Для этого можно написать Crash-PoC или эксплойт с запуском калькулятора, а можно выслать подробный бинарный анализ проблемы с выводами. От качества этой писанины зависит скорость, с которой ZDI отреагирует на твой товар и, возможно, качество этой реакции. Очевидно, что этот шаг являются самым трудным и, фактически, это и есть основная твоя работа. Чтобы выполнить его, требуется опыт и знания, за что собственно и платят деньги.

Шаг 1. Регистрация

Если нулевой шаг не поддается описанию в теме моей статьи (только затрагивает область твоих интересов), то дальше я опишу сам процесс работы с ZDI. От регистрации до вывода денег. Итак, шаг первый — регистрация. Для этого идем на сайт zerodayinitiative.com, где видим простой и понятный интерфейс. Смело жми ссылку на «Researcher Login». Нас просят ввести логин и пароль, но понят-

ное дело, что у нас их нет... ищем в верхнем правом углу ссылку «Register». Отлично! Тут мы вводим свой e-mail, пароль и желаемый логин. В принципе, этого достаточно, но чуть ниже есть поле «Referal». На него можно забить, но я рекомендую ввести туда мой логин :). Как только ты сдашь свой первый 0day, и тем самым покажешь, что твой аккаунт имеет смысл, тот, кого ты указал в качестве реферала, получит 2500 очков вознаграждения (о них позже), так что смело вводи в это поле «asintsov», а я буду ждать твоих успехов :). После регистрации ты сможешь войти в систему, но этого недостаточно — необходимо официально подтвердить свою сущность. Для этого в закладке «My Account» надо отправить несколько форм. Первая — «My Profile». Тут ты заполняешь свои настоящие ФИО, указываешь адрес и страну, откуда ты. Обрати внимание на то, что если ты из Кубы, Ирана, Северной Кореи, Сирии или, например, из Судана, то ZDI не будет с тобой работать. Отправив эти данные, знай, что на веб-сайте они не хранятся, а шифруются PGP-ключом и отправляются по e-mail'у в офис ZDI. Таким образом, на вебсервере нет никакой информации о тебе, кроме логина и e-mail'а. После отправки профайла нужно подтвердить свою личность. Для этого иди и заполняй следующую форму — «Copy of Government Issued ID». Кликнув по этой ссылке, ты получишь PDF-файл, который надо распечатать, вписать ручкой свой логин от системы, приложить свой паспорт (разворот с фоткой) и засунуть эту художественную композицию в сканер. Полученную форму отправить по электронной почте на zdi@3com.com, предварительно зашифровав на открытом ключе — https://www.zerodayinitiative.com/documents/ zdi-pgp-key.asc (если не параноик, то можешь и не шифровать). В общем, паспорт должен быть обычным, хотя можно и загран — судя по всему, им там пофиг.

Следующий пункт — самый приятный — про то, каким путем ты хочешь получать вознаграждение. Раньше было доступно три варианта: перевод Western Union, чеком или банковским переводом. Вариант с WU был шикарен, но в итоге от него отказались, и теперь существует только два варианта — чеком или банковским переводом. Я выбрал банковский перевод; для этого надо знать номер своего счета в банке (ну, и иметь этот счет), название банка, SWIFTпозывной и адрес. Все это можно узнать как в самом банке, так и в интернете. Счет должен быть открыт в долларах США. В идеале, если к этому счету привязана карточка, то деньги можно снимать без комиссии в фирменных банкоматах банка. После того, как вся эта информация заполнена и подтверждена, напротив данных форм появятся большие зеленые кружочки с галочкой — мол, все ОК. Это

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

Шаг 2. Процесс

Итак, ты нашел уязвимость, написал эксплойт и описание на английском, и что дальше? Дальше все просто — кликай по «Open Case» и заполняй эту форму. Не бойся, никто у тебя уязвимость не украдет. Желательно рассказать, какие привилегии нужны для реализации уязвимости, в конфигурации по умолчанию или нет (лучше, если да), нужны ли элементы социальной инженерии при атаке (типа, надо ли заманить на свой веб-сайт и т.д.). После того, как ты отправил уязвимость, не жди моментального ответа, а начинай искать следующую багу. Дело в том, что теперь твой «отчет» ждет проверки, и ждать он может больше месяца, поэтому не стоит терять время. Через месяц тебя могут попросить по e-mail'у уточнить какие-нибудь детали и опять исчезнуть на неделю-две, а могут сразу высказать предложение купить твою багу и права на нее. Прямо в письме будет указана и сумма. Если ты согласен, то ответь на письмо, что, мол, согласен. После этого статус баги в меню «My Cases» обновится, а еще через неделю тебе на счет в банке упадет ровно та сумма, на которую вы договорились. В меню «My Cases» можно следить за судьбой проданной тобой дырки

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

Награда

Кроме суммы на счет ты получишь очки вознаграждения. Эта фигня показывает твою полезность для ZDI. За первый баг ты получаешь 2500 очков, потом 2500 можно получать с тех, кто указал тебя в качестве реферала и уже сдал свой первый баг. А потом с каждой новой проданной уязвимостью ты получаешь эти очки. Зачем они нужны? А за тем, что, набрав 10000 очков, ты становишься бронзовым партнером, 20000 — серебряным, 35000 — золотым и, наконец, 50 000 — платиновым. Например,

всем известный хакер @WTFuzz имеет двойной платиновый статус. Эти статусы дают разные полезные и вкусные плюшки, которые начисляются в конце календарного года с момента начисления первых очков. Плюшки представляют собой следующие бонусы. Бронзовый:

•+10% к денежным наградам за все баги в следующем году

•$1000 бонус

XÀÊÅÐ 12 /143/ 10

Серебряный:

•+15% к денежным наградам за все баги в следующем году

•+25% к начисляемым очкам вознаграждения в следующем году

•$5000 бонус

•Оплачиваемая путевка (перелет + регистрация) на DEFCON в Лас-Вегасе

Золотой:

•+20% к денежным наградам за все баги в следующем году

•+50% к начисляемым очкам вознаграждения в следующем году

•$10000 бонус

•Оплачиваемая путевка (перелет + регистрация) на BlackHat и DEFCON в Лас-Вегасе

Платиновый:

•+25% к денежным наградам за все баги в следующем году

•+100% к начисляемым очкам вознаграждения в следующем году

•$20000 бонус

•Оплачиваемая путевка (перелет + регистрация) на BlackHat и DEFCON в Лас-Вегасе + запись на курсы BlackHat

Как видишь, бонусы достаточно вкусные и приятные. Кроме того, не забывай про основное вознаграждение, которое достаточно адекватно оценивает твою работу. За простое переполнение буфера в ActiveX-компоненте, которое находится за пять минут COMRaider'ом, могут заплатить 2500 — 3000 долларов. Если находить по две уязвимости в месяц, то можно жить — не тужить вообще. Многие западные ресерчеры только за счет ZDI и живут. Однако нельзя же всю жизнь только баги искать...

Выводы

Если ты хочешь начать свою баг-хантерскую жизнь, то я рекомендую начать ее с ZDI. После года-двух успешной работы ты получишь опыт, знания, новые интересные контакты и шанс попасть на работу ресерчером/пен-тестером/консультантом куда угодно, ведь нет лучшего резюме, чем связка адвайзори от ZDI с твоей фамилией. Главное — не зацикливаться на однообразных задачах, а развиваться. Желаю тебе удачи! z

065

ВЗЛОМ

Маг icq 884888, http://snipper.ru

Программы для хакеров

Заапдейтами, исходникамииподдержкой советуюобращатьсяпрямикомнастраничку программывпроектеSourceforge — hyenae. sourceforge.net.

Программа:CmosPwd ОС:*nix/win

Автор:ChristopheGrenier

Навернякатынеразсталкивалсяспроблемой забытогопаролявBIOS. Вследующийразвтакойситуациитебепоможет незамысловатаякроссплатформеннаяпрога CmosPwd,котораяумеетрасшифровывать пароли,хранящиесявcmosспомощьюдоступак BIOSSETUP.Утилитаподдерживаетследующие видыBIOS'ов:

•ACER/IBM BIOS;

•AMI BIOS;

•AMI WinBIOS 2.5;

•Award 4.5x/4.6x/6.0;

•Compaq (1992);

•Compaq (New version);

•IBM (PS/2, Activa, Thinkpad);

•Packard Bell;

•Phoenix 1.00.09.AC0 (1994), a486 1.03, 1.04, 1.10 A03, 4.05 rev 1.02.943, 4.06 rev 1.13.1107;

•Phoenix 4 release 6 (User);

•Gateway Solo - Phoenix 4.0 release 6;

•Toshiba;

•Zenith AMI.

Из приятных дополнений можно отметить тот факт, что прога также умеет бэкапить, восстанавливать и стирать/«убивать» cmos.

ВотсписокосновныхкомандCmosPwd:

cmospwd.exe [/d] //дамп cmos в ascii + сканирование кода

cmospwd.exe [/d] /[rlw] cmos_бэкап_файл //воссстановить/загрузить/записать бэкап cmos

cmospwd.exe /k //«убить» cmos cmospwd.exe /m[01]* //выполнить выбранный модуль

Подробнейшиймануалпопрограмметы сможешьнайтипоадресуcgsecurity.org/ cmospwd.txt, официальнаястраничка— cgsecurity.org/wiki/CmosPwd.

Программа:DSGoodChecker ОС:Windows2000/XP/2003 Server/Vista/2008Server/7 Автор:NightEagle