Мы решили учесть пожелания читателей нашего блога и подготовили небольшую статью о том, как можно извлечь код разблокировки из блокера. Отвечает старший вирусный аналитик «Лаборатории Касперского» Вячеслав Закоржевский!..

Для разбора мной был выбран один из представителей нового семейства Trojan-Ransom.Win32.Mbro. Эти блокеры заражают MBR и вымогают деньги у пользователя за снятие блокировки компьютера.

Для начала предыстория:

Некоторое время назад я приобрёл на Ebay б/у ноутбук Lenovo Thinkpad W520. Как известно, W-серия — это очень мощные ноутбуки, железки в которых дадут фору многим более современным машинам. Конечно же, я начал его обустраивать под себя, и, в частности, решил проапгрейдить имеющуюся память всем, что было в наличии, а в наличии было немало: 2 свободные планки DDR3-1600 из старого ноута — 4 и 8 гигабайт. Посмотрев на то, что было установлено продавцом, я обнаружил, что из 3 установленных планок 2 — DDR3-1600, а одна — 1333. Учитывая, что первые две были по 8 гигабайт, а последняя — 2 гигабайта, от неё я и решил избавиться. Рассчитывая получить после апгрейда 8+8+8+4=28 гигабайт DDR3-1600 в рабочем ноуте, я залил всё слюной и всё это быстренько подключил. И получил 28 гигабайт… DDR3-1333. «Что за...», подумал я и полез в гугл.

После непродолжительных поисков я обнаружил, что как официально, так и неофициально W520 поддерживает только DDR3-1333, а владельцы более быстрой памяти зря тратили на неё деньги. Мне стало немного обидно за всех таких владельцев, и я решил попробовать избавиться от этой несправедливости, тем более, что контроллер памяти, нынче, как известно, в процессоре, и установленный в моей модели Intel Core i7 2720QM официально поддерживает DDR3-1600.

Пока еще широко распространенный продукт Flash Player компании Adobe печально известен своей безопасностью. Регулярно становится известно об очередной zero-day уязвимости во Flash, используемой хакерами в APT-кампаниях. 2015 год выдался особенно урожайным на такие уязвимости. Большая доля критических RCE-уязвимостей были вызваны некорректной работой с памятью: была возможна запись в освобожденную память в куче процесса Flash.

В этой статье мы поисследовали безопасность Adobe Flash и выяснили, что многие его «дыры в безопасности» — хронические, и решить их можно разве что переписыванием кода с нуля, в то время как разработчики ставят заплатку на заплатку, что, конечно, не повышает уровень безопасности. А еще мы продемонстрируем некоторые найденные нами и незакрытые на данный момент уязвимости!

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

В качестве примера одной из таких вещей можно назвать cmd.exe. Да-да, это тот самый интерпретатор командной строки, входящий в поставку всех современных (и не очень) операционных систем семейства Windows. Исторических причин у него накопилось изрядное количество — достаточно вспомнить хотя бы то, как необходимо производить вставку и копирование в данный интерпретатор (ради справедливости стоит сказать, что в Windows 10 эту ситуацию наконец исправили, да и приложения наподобие ConEmu здорово в этом помогают). Но речь сегодня пойдёт о другом поведении, которое заствляет задуматься впервые столкнувшегося с cmd.exe человека, казалось бы, там, где этого совсем не требуется.

Как вы знаете, одной из команд, которые воспринимает cmd.exe, является «CD». Официальный хелп по этой команде сообщает следующее:

C:\Users\Nikita.Trophimov>CD /?
Displays the name of or changes the current directory.
[...]

Казалось бы, всё просто. Вызываешь CD без аргумента — в stdout выводится путь до текущей директории, передаёшь другую директорию в качестве аргумента — он сменяет текущую директорию на указанную. Подводные камни тут начинаются в том случае, если пользователь решил сменить директорию одновременно вместе с диском. Например, если вы находитесь в директории «C:\Windows\system32», то команда «CD D:\books» не сделает ровным счётом ничего. На мой взгляд, очевидного для новых пользователей в этом совершенно ничего нет, так что их спасает гугл или официальная документация, которая, кстати, сообщает:

Use the /D switch to change current drive in addition to changing current
directory for a drive.

Разумеется, этот вопрос, равно как и причины возникновения подобного поведения, уже не раз обсуждался в интернете (например, тут), так что останавливаться на подобных вещах мы не будем. Вместо этого мы попробуем отладить cmd.exe, чтобы убрать необходимость явного указания ключа "/D".

Как протекал процесс, и что из этого вышло, читайте под катом.

Доброго здравия! Не удивлюсь, что Вы раньше даже не слышали об этой программе. Как и я, до того дня, когда мне пригодился Python Debugger. Да, знаю, есть pdb, но его функционал и то, как он представлен, мне совершенно не приглянулось. После непродолжительных поисков я наткнулся на этот замечательный продукт. Тут есть все, что может пригодиться в отладке ваших Python приложений (скажу сразу: данный язык я не изучал, поэтому, если какие-то неточности всплывут, просьба не ругаться).

Этот пост будет интересно действительно тем, кто только начинает интересоваться этой темой. У людей с опытом он, возможно, вызовет только зевки. За исключением разве что, может быть, эпилога…
Реверс-инжиниринг в той менее легальной части, где он не касается отладки и оптимизации собственного продукта, касается в том числе и такой задачи: «узнать, а как у них это работает». Иначе говоря, восстановление исходного алгоритма программы, имея на руках ее исполнимый файл.
Для того, чтобы держаться азов и избежать некоторых проблем — «взломаем» не что-нибудь, а… кейген. В 90% он не будет запакован, зашифрован или иным способом защищен — в том числе и нормами международного права…

В нашей статье мы покажем, как Intel Tamper Protection Toolkit позволяет защитить критически важные участки кода и ценные данные в утилите шифрования Scrypt против статического/динамического реверс-инженеринга и изменений. Scrypt – наиболее новая и безопасная функция выработки ключа по паролю, широко применяемая на практике. Однако существует угроза фальсификации параметров функции scrypt, что приведет к появлению уязвимостей пароля пользователя. Инструментарий позволяет уменьшить эти угрозы. Мы определяем модель угроз для рассматриваемого приложения, объясняем как провести его рефакторинг для дальнейшей защиты, учитывая особенности применения инструмента Tamper Protection к приложению.
Основной целью этой статьи является демонстрация возможностей Intel Tamper Protection Toolkit по защите от атак на критически важные участки кода и ценные данные, находящиеся в реальных приложениях. Инструментарий позволяет противодействовать статическому и динамическому реверс-инженерингу путем обфускации и препятствовать внесению изменений в защищаемое приложение путем контроля целостности во время выполнения.

Перевод статьи от компании Check Point’s Malware Research Team.

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

Жертвам подобных вредоносных программ обычно рекомендуют восстановить файлы из раннего бэкапа. Но если такого бэкапа нет, перед нами остается трудный выбор — смириться с потерей данных или заплатить злоумышленнику. Однако, нам (Check Point’s Malware Research Team) удалось найти способ в случае DirCrypt восстановить почти все данные, воспользовавшись его слабыми сторонами в реализации шифрования.

Разработчики мобильных приложений зачастую сталкиваются с необходимостью хранить конфиденциальные данные пользователя на пользовательском устройстве. Это могут быть, например, номер кредитной карточки или аутентификационные данные. В этой статье мы поговорим о типичных ошибках реализации хранения конфиденциальных данных с точки зрения информационной безопасности на примере мобильной платформы iOS.
Обычно настройки приложения хранятся в конфигурационных файлах. Библиотека Cocoa Touch, используемая при разработке приложений для мобильной платформы iOS, предоставляет слой абстракции для хранения настроек приложения в классе NSUserDefaults. Класс NSUserDefaults реализует нелюбимый многими шаблон проектирования «Одиночка» (более известный как Singleton), предоставляя доступ к интерфейсу над стандартным конфигурационным файлом приложения.
Стандартный файл конфигурации приложения располагается в его домашней директории по относительному адресу Library/Preferences/<your.company.name>.<app.name>.plist. Как и другие файлы, расположенные в «песочнице», он не доступен на чтение для других приложений пользовательского уровня. Исключения составляют устройства, подвергнутые модификациям политики безопасности системы (jailbroken-устройства).
Многие разработчики по достоинству оценили удобство работы с классом NSUserDefaults. Подавляющее число приложений используют его для хранения внутренних настроек и/или настроек пользователя. К сожалению, удобство использования редко коррелирует с безопасностью. Хранение конфиденциальных данных пользователя в стандартном файле настроек является типичной ошибкой разработчиков, приводящей к утечке пользовательской информации.
В результате исследования исходного кода Приложения А на наличие ошибок в контексте информационной безопасности было выявлено, что приложение сохраняет данные аутентификации пользователя в конфигурационном файле настроек. Загрузив Приложение А на iPad под управление оригинальной операционной системы iOS версии 6.1.3, мы прошли стадию аутентификации и принялись за исследование файла настроек приложения.


Рис. 1. Загрузка приложения на iPad

Не только XSS…

Последнее время многие обращают внимание на уязвимости ПО, используемого в банковском секторе: в частности, недавно прошумела новость об уязвимостях класса XSS на веб-сайтах различных банков. Общественность негодует, и СМИ шумят. Но ведь банки богаты не только веб-составляющей. Начиная с конца 2000-х я собирал уязвимости в модулях ActiveX, которые банки гордо раздают своим пользователям, а именно клиентам системы дистанционного банковского обслуживания (ДБО). Раз в год я брал одну или две системы и ковырял их. Начиная просто так, любопытства ради (начал это дело, еще будучи сотрудником банка) и продолжая уже из исследовательского интереса. В итоге за 3–4 года я выявил уязвимости в системах от таких производителей, как BSS, Inist, R-Style, ЦФТ. Под катом находится информация об одной такой уязвимости. Большая часть описания уделена созданию простенького эксплойта для выполнения произвольного кода на стороне клиента (Windows7, IE +DEP/ASLR). Возможно, это будет полезно тем, кто хотел бы понять принципы эксплуатации старых ‘strcpy’ багов и создания ROP-эксплойтов.

Когда мы придумывали задание для конкурса по обратной разработке, который состоялся на форуме PHDays V, то хотели отразить реальные проблемы, с которыми сталкиваются специалисты по RE, но при этом старались избежать шаблонных решений.

Как обычно выглядят задачки на реверс? Есть исполняемый файл под Windows (или Linux, или MacOS, или другую популярную операционную систему), его можно запускать, смотреть под отладчиком, крутить как угодно в виртуальных средах. Формат файла — известный. Система команд процессора — x86, AMD64 или ARM.

Библиотечные функции и системные вызовы — задокументированы. Доступ к оборудованию — только через механизмы операционной системы.

С использованием существующих инструментов (например, IDAPro с HеxRays и всеми сопутствующими возможностями) анализ подобных приложений становится практически детской забавой: все получается просто и быстро.

Всем привет. Многие знают об этой замечательной игре — LIMBO! Вы даже наверняка покупали ее в Стиме, или качали с торрентов…
Я тоже ее купил когда-то (что и вам советую!), и прошел). Но, как всегда, мне было этого мало, и я, из спортивного интереса, решил изучить ее защиту. Так и появился кейген к игре LIMBO.

Поддавшись общей волне энтузиазма относительно систем «Умный дом», а также имея профильное образование инженера АСУ ТП, с удовольствием занимаюсь данной темой в виде хобби. В этой статье поделюсь с вами своим опытом реверс-инжиниринга популярного модуля ESP8266.

Содержание

1. Введение
2. Архитектура ESP8266
   
   • Карта памяти (адресного пространства)
   • Формат прошивки
   • Процесс запуска
3. Инструменты
4. Загрузка прошивки для исследования
   
   • ELF
   • Системная прошивка модуля
   • Пользовательская прошивка
5. Ассемблер Xtensa
   
   • Регистры
   • Базовые операторы
   • Функции
   • Условные переходы
6. Заключение
7. Ссылки

В мире ПО существует огромное количество программ, забытых своими разработчиками. Хорошо, когда уже есть хорошая альтернатива. А если ее нет? В программе может катастрофически не хватать каких-то мелочей, некоторые досадные ошибки могут годами доставлять массу неудобств пользователям, а на новых версиях ОС программа и вовсе может отказаться работать. Далеко не всегда имеются исходные коды, чтобы привести программу в порядок. Если программа простая — не составит труда за короткий срок создать альтернативу. Но если программа большая и сложная, что же делать в таком случае? Не всегда рационально тратить время и деньги на разработку полного аналога, ведь расширить в разумных рамках функциональность и исправить большинство ошибок можно уже в готовом исполняемом файле.
В этой статье будут продемонстрированы методики модификации исполняемых файлов на примере расширения функциональности легендарной игры Age of Empires II (стратегия реального времени).

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

Письмо

Итак, начинаем. На входе у нас письмо с текстом «Journalist shot in Georgia! See attached video. Password is 123» и с приложенным файлом «Georgia.zip».

Для более или менее полного анализа нам понадобятся:
— Самый Лучший дизассемблер в мире IDA
— Неплохой Отладчик Windbg
— python 2.5 (строго говоря, подойдет любой, просто у меня 2.5)
— Visual Studio какая-нибудь и Microsoft SDK, чтобы собрать небольшую программу на с++.
— упаковщик программ upx
— ну и чего-то еще по мелочи.

Распаковываем присланный нам файл, и видим, что наши подозрения оправданы: видео там и рядом не ночевало.

joined.exe (md5:607af96b03addadf28cf9280701df191)
Dr.Web: Trojan.Packed.151
Kaspersky: Trojan-Downloader.Win32.Agent.abqe

Вчера я разбирал «нецензурный» троян (http://vilgeforce.habrahabr.ru/blog/44130.html), а сегодня разделываю его потомка — ftp34.dll. Эта тваринка, кстати, куда как интереснее подавляющего большинства троянов. Хотя бы тем, что ворует информацию не с диска, а прямо из сетевого траффика. Как? Смотрите под кат.

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

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

1. Алиса проходит процедуру проверки в удостоверяющем центре(УЦ) и получает сертификат
2. Алиса посылает свой сертификат Бобу
3. Боб получает сертификат УЦ
4. С помощью полученных сертификатов Боб производит аутентификацию Алисы

Первым об упрощении этой схемы задумался Ади Шамир в 1984 году. Он предположил, что если бы появилась возможность использовать в качестве открытого ключа имя или почтовый адрес Алисы, то это лишило бы сложную процедуру аутентификации всякого смысла.
Долгое время идея Шамира оставалась всего лишь красивой криптографической головоломкой, но в 2000 году, благодаря одной известной уязвимости в эллиптической криптографии, идею удалось воплотить в жизнь.

Привет, Хабр. На связи Вячеслав Закоржевский, старший вирусный аналитик ЛК. Пока редакторы пишут очередные анонсы и прочую поэзию, есть возможность удивить вас мало-мальски техническим материалом.
Все, наверное, знают, что есть множество разных фишек, с помощью которых малварщики защищают свои детища. Обычно они пытаются определить, работает ли приложение под виртуалкой, обойти эвристическую или проактивную защиту и т.д. Мы решили написать небольшой пример того, как в современном FakeAV (получен буквально пару дней назад) вирусописатели пытаются обойти АВ-продукты, песочницы и т.д. В исследуемом файле я обнаружил вызов экспортируемой функции с любопытным именем:


Скриншот зловреда из Hiew

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

К сожалению, статья будет достаточно тяжелая для обычного прикладного программиста, не интересующегося тематикой защиты ПО, но тут уж ничего не поделать.

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

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

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

В качестве реципиента, по совету одного достаточно компетентного товарища, я выбрал немножко старый (но не потерявший актуальности, в силу качества исполнения) keygenme от небезызвестного Ms-Rem.

Вот первоначальная ссылка, где он появился: http://exelab.ru/f/index.php?action=vthread&forum=1&topic=4732
А потом он попал вот сюда: http://www.crackmes.de/users/ms_rem/keygenme_by_ms_rem/
Где данному keygenme был выставлена сложность 8 из 10 (*VERY VERY* hard).
Хотя, если честно, это слегка завышенная оценка — я бы поставил в районе 5-6 баллов.

Пожалуй, начнем.

Привет, хабр! Сегодня я расскажу вам о том, с чем вы можете столкнуться, если вдруг решите залезть в дебри чужого приложения на Android (в данном случае, онлайн игры). Приключения с просмотром Java-классов в .dex, изучение оп-кодов Dalvik и даже программирование в двоичном коде. Но обо всем по порядку.

Под катом трафик на ~800кб, 293 из которых – скриншоты кода (!)