Приветствую,

Думаю, пришла пора. Наболело/накипело/есть мнение. С выходом Гидры ситуация с инструментарием для реверс-инженеров достаточно сильно изменилась. Если раньше выбора чем пользоваться особо не было (здесь не будут упоминаться Binary Ninja, Hopper, JEB или Radare2, потому как в известных мне ИБ-компаниях и комьюнити ими пользуется очень малое количество человек, либо же порог вхождения в некоторые (привет, Радар) очень высок, либо же покрытие архитектур ограничено лишь x86/x64/ARM/ARM64/MIPS), то теперь мы имеем очень мощного конкурента Hex-Rays в лице АНБ с их GHIDRA.

Как найти зловреда (нет) с WinDbg

Вступление

В этой статье я покажу, как, например, с помощью WinDbg найти, какой такой зловред (или нет) заменил адрес вызова системной функции в DLL, подгружаемым каким-нибудь приложением. Так я, к примеру, искал почему не загружается модуль защиты в конфигурацию 1С.
Для демонстрации нам понадобится приложение, которое загружает пару DLL: одну из них назовём victim (жертва), другую — хищник injector. Последнняя внедряется в жертву, заменяя вызов системной функции (для простоты возьмём Sleep), и будет вызывать AV при определённых условиях (что понадобится в следующей статье).

Т.к. приложения, написанные на Delphi, "не падают" в core-dump из-за необработаных исключений, то наше главное приложение (DLLInjectionDemo) написано на С, линковано ранним связыванием с DLL-жертвой, а для простоты воспроизведения ситуации, будет загружать DLL-injector, переданную в опциях при запуске, и вызывать в ней метод, который навредит жертве. Конкретно для этой статьи нам подошло бы приложение, написанное на любом языке программирования, но убьём двух зайцев сразу.

Исходные коды приложений написаны на C и Delphi 10.3 Rio Community Edition, и компилируются MinGW и Delphi, как для Win32, так и для Win64 (а также FPC в Lazarus-е).

Итак компилируем обе DLL и главное приложение

Не секрет, что Net-Tools пора на почетную отставку. Да, многим админам и мне в том числе, до условного рефлекса Павлова знакомы команды ifconfig, route, netstat. На первый взгляд нет причин что-то менять, а лучшее как всегда враг хорошего.

Давайте узнаем почему Net-Tools уже не тот и как безболезненно с него перейти на iproute2 .

Телеметрия давно стала горячо обсуждаемой темой с момента, когда Microsoft выпустил первую версию Windows 10. Microsoft решил глубоко интегрировать сбор данных в операционную систему — да так глубоко, что у пользовательских выпусков Windows 10 Home и Windows 10 Pro не было опции по полному отключению телеметрии.

«Важная истина, что вещи не всегда являются тем, чем кажутся, общеизвестна…»

―Дуглас Адамс, Автостопом по Галактике

Делая пере-реализацию QInst на LLVM, я столкнулся с такой проблемой: QEMU в режиме эмуляции одного процесса естественным образом перехватывает все «гостевые» системные вызовы. В итоге плагин инструментации имеет единую точку входа для их предобработки, где можно по номерам SYS_* и значениям аргументов принимать решения. Это довольно удобно. Проблема в том, что все системные вызовы делает, в основном, libc и, переписывая код статически, мы просто до этой части в большинстве случаев не доберёмся. Конечно, можно было бы использовать ptrace, который как раз предназначен и для этого в том числе. Но тогда не уверен, что получилось бы обойтись без отдельного процесса, а семантика QInst предполагала тривиальный «синхронный» перехват — пришлось бы как-то инжектить вызов обработчика, а это сильно сложнее привычного LD_PRELOAD. Можно оборачивать каждый системный вызов — но это, как минимум, неудобно (к тому же, можем что-нибудь пропустить, ведь в этом случае мы перехватываем на самом не системные вызовы, а их конкретные обёртки).

Под катом — решение, не привязанное к LLVM, но заточенное под Linux на x86_64 (но адаптируемое для Linux на других архитектурах).

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

Как работает паника в Rust

Что именно происходит, когда вы вызываете panic!()?
Недавно я потратил много времени на изучение частей стандартной библиотеки, связанных с этим и оказалось, что ответ довольно сложный!

Мне не удалось найти документы, объясняющие общую картину паники в Rust, так что это стоит записать.

Зачем нужны индикаторы прогресса?

Индикаторы прогресса (progress bar) — визуальное отображение процесса работы. Они избавляют нас от необходимости беспокоиться о том, не завис ли скрипт, дают интуитивное представление о скорости его выполнения и подсказывают, сколько времени осталось до завершения.

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

Введение

Подготовка: исходники Quake 3

Введение.

Перевод статьи подготовлен специально для студентов курса «Разработчик С++». Интересно развиваться в данном направлении? Смотрите запись мастер-класса «Практика использования Google Test Framework»!

Часть 3 — Виртуальное наследование

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