Как найти зловреда (нет) с 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 и главное приложение

Я довольно часто сталкивался с тем, что разработчики на Delphi (можно сказать традиционно) компилируют свои приложения "ручками", что далеко не production-решение, а со стороны выглядит кустарщиной и "делаем на-коленке", хотя продукты бывают весьма серьёзными и продаваемыми. Вероятно, это пошло ещё с тех пор, когда для автоматизации нужно было придумывать свои батнички, которые запускали компилятор командной строки dcc32 с нужными параметрами. Некоторые даже сделали свой "Публикатор" — Delphi-expert, который делает работу сервера сборок: компилирует (правда, открытый в IDE) проект, выставляя ему взятый из какой-то БД инкрементированный номер версии, записывает некий changelog и копирует это куда-то в сетевой каталог.

Я не буду вдаваться в исторический экскурс как было раньше. Я расскажу как есть/можно сейчас, и как это использовать для повышения эффективности своей работы.

Файл проекта современной версии Delphi — это .dproj-файл (здесь и далее я буду ориентироваться на Delphi 10 Rio, но с небольшими отличиями это верно для всех более ранних версий Delphi, начиная с 2007). В нём хранятся все настройки проекта, которые обычно изменяют в IDE (меню Project - Options (Ctrl+Shift+F11)). В рамках данной статьи я сконцентрируюсь на "основных", которые понадобятся для демонстрации общих принципов: это Config — конфигурация, Platform — платформа, OutputDirectory — путь выходного файла и ConditionalDefines (директивы условной компиляции). Остальные настройки, если таковые нужно менять при сборке, я предлагаю выявить самостоятельно. Этот же .dproj-файл, если в него заглянуть обычным текстовым редактором, является ничем иным как скриптом сборки MSBuild (давайте создадим простое консольное приложение и назовём его DelphiAutomatedBuild):

В серии про надежное программирование [1], [2] остался незаслуженно забытым Swift. Я, честно говоря, просто не считал его кроссплатформенным, а работающим исключительно для macOS/iOS. Тут случайно выяснилось, что Swift также поддерживается такой средой разработки, как RemObjects Elements.

Оказалось, у неё Универсальный Компилятор. Умеет компилировать программы на C#, Go, Java, Oxygene Object Pascal, Swift для: Android, Cocoa (MacOS, iOS, tvOS), JVM, Linux (x64, armv6, aarch64), .NET/.NET Core/Mono, Native Windows(x86/x64), WebAssembly.

Причем делает это практически в любых комбинациях язык → целевая система! Например, можно написать программу на Java, которая будет использовать WPF для целевой платформы .NET, и это все есть в примерах, идущих в поставке.

Итак, представляю мини-заметку про RemObjects Elements, а заодно про надежность двух поддерживаемых в ней языков — Swift и Oxygene.

Рисунок с сайта radionetplus

Около двух лет назад наша команда поведала Хабру о своём проекте по оптимизации ОС Windows с помощью технологии нейросетей.

За прошедшие два года многое изменилось, но самое главное осталось неизменным. И в этой статье мы хотим поделиться теми открытиями и теми выводами, которые сделали за эти два года.



Если вам интересно, как в 2020ом обстоят дела по независимому продакшену софта для ПК, добро пожаловать под кат.

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

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

Давайте разберёмся, как же это работает, поэкспериментируем с моей программой, и поймём, при чём тут вообще песочницы.

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

Хочу рассказать про свой излюбленный алгоритм для поразрядной сортировки LSD (least significant digit — сначала младший разряд) с подсчётом (Radix Sort). Классический алгоритм был несколько переосмыслен автором в сторону некоторых оптимизаций в пользу ускорения и простоты.

В далеком 2009-м на Хабре уже возникал холиварный шуточный пост с вопросом "Умирает ли Delphi?", а неким энтузиастом (Jamie Ingilby) в поддержку были созданы 2 сайта, которые утвердительно отвечали «Нет, язык Delphi жив».

Однако, как всем известно, дыма без огня не бывает, и сейчас, к сожалению, язык испытывает далеко не лучшие времена (в большей степени на это влияет не совсем адекватная ценовая политика Embarcadero), но тем не менее Delphi вполне себе живет, развивается и соответствует текущим трендам разработки ПО.

If I could export one feature of Go into other languages, it would be interfaces. — Russ Cox



Мой предельно простой компилятор Паскаля уже становился предметом двух публикаций на Хабре. Со времени их написания язык обзавёлся всеми недостающими средствами, положенными стандартному Паскалю, и многими плюшками, добавленными в Паскаль компанией Borland в её золотую пору. Компилятор также научился ряду простейших локальных оптимизаций, достаточных хотя бы для того, чтобы глаза не кровоточили при взгляде на листинг дизассемблера.

Тем не менее дебри объектно-ориентированного программирования остались совершенно нетронутыми. Так почему бы компилятору не послужить теперь полигоном для экспериментов в этой области? И почему бы нам не почерпнуть вдохновение из слов Расса Кокса, вынесенных в эпиграф? Попробуем реализовать в Паскале методы и интерфейсы в стиле Go. Затея интересна хотя бы тем, что все популярные в прошлом компиляторы Паскаля (Delphi, Free Pascal) по сути заимствовали объектную модель из C++. Любопытно посмотреть, как на той же почве приживётся совсем иной подход, позаимствованный из Go. Если вы вслед за мной готовы запастись изрядной долей иронии, отбросить вопрос «Зачем?» и воспринять происходящее как игру, добро пожаловать под кат.

Всем привет!

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

В последнее время на многих зарубежных сайтах стала появляться incapsula — система которая повышает защищённость сайта, скорость работы и при этом очень усложняет жизнь разработчикам программного обеспечения. Суть данной системы — комплексная защита с использованием JavaScript, который, к слову, многие DDOS боты уже научились выполнять и даже обходить CloudFlare. Сегодня мы изучим incapsula, напишем деобфускатор JS скрипта и научим своего DDOS бота обходить её!

Предыстория

У меня есть убогий дешевый планшет на Windows 10 с одним гигабайтом оперативной памяти и 16 гигабайтами места, в пределах которого установлен Windows 10. Чтобы Windows 10 мог хоть как-то скачивать и устанавливать обновления — я скрутил размер файла подкачки в ноль и файл pagefile.sys перестал занимать драгоценные гигабайты.

После этого я с удивлением обнаружил, что для просмотра более-менее крупных сайтов на этом планшете невозможно использовать ни Chrome, ни Internet Explorer, ни даже старую Opera 12. Все они пытаются пару раз показать сайт, перезагружают его снова (он, по видимости, не влезает в настоящую оперативную память без файла подкачки) и выдают после второй попытки загрузки сообщение о неудаче.

Почему при размере исходного HTML-кода сайта в несколько сотен килобайт — компьютер с гигабайтом оперативной памяти не может его отрисовать?

Неожиданно тёплый приём, оказанный публикой Хабра моему посту о самодельном компиляторе XD Pascal для MS-DOS, заставил меня задуматься. Не досадно ли, что любительский проект, которому я отдал немало сил, лежит у меня мёртвым грузом с тех самых пор, как из Windows полностью исчезла виртуальная машина DOS? Итогом размышлений стал компилятор XD Pascal для Windows. Возможно, он лишился некоторой доли ностальгического шарма и утратил возможность наивной работы с графикой через прерывания BIOS. Однако переход на Windows вдохнул новую жизнь в проект и открыл дорогу к давней мечте — самокомпиляции.

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

Привет, Хабр!

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

ВНИМАНИЕ! Информация, описанная ниже, написана исключительно в исследовательских целях и не предназначена для использования в корыстных целях!

Начну, пожалуй с предыстории.

А именно, c конца 2013 года. Тогда перед мной, как помню, возникла проблема поиска удобной IDE для быстрой и главное простой реализации прикладных задач. Надо сказать, что на тот момент я перегорел к JAVA и, хоть NetBeans мне нравилась, хотелось скорости работы и простоты разработки (Не забываем, что Java SE 6 была ну ооочень медленной). Короче, захотелось С/C++. Многие мои знакомые тогда использовали VS 2012 и, конечно, рекомендовали её мне с пеной у рта, мол лучшая IDE и бла-бла-бла. Ага, весила она на тот момент (развернутой) 15-20Gb и съедала почти всю оперативку (4Gb под Windows + VS), и ещё при всем при этом глючила безбожно. Но я готов был закрыть на это глаза, основной-то код я всегда пишу в Notepad++. Но "грязь" в IDE я пережить так и не смог (когда ради консольного приложения программа пишет 100500+ строк кода — это меня бесит и по сей день, я же не форму прошу сделать....) В итоге, удалил я VS 2012 и забыл о ней до 2017 года.

Сегодня я бы хотел рассказать о программе, с помощью которой я начинал изучать протокол ModBus и ПЛК. Я ей пользуюсь до сих пор, и лично видел её в использовании у нескольких наладчиков. Если кому-то интересна история её создания или исходники прошу под кат.

(Источник рисунка )

Общеизвестно, что Решето Эратосфена (РЭ) один из древнейших алгоритмов, появившийся задолго до изобретения компьютеров. Поэтому можно подумать, что за века этот алгоритм изучен вдоль и поперек и добавить к нему ничего невозможно. Если посмотреть Википедию – там море ссылок на авторитетные источники, в которых запросто утонуть. Поэтому удивился, когда на днях случайно обнаружил, что вариант, который в Википедии преподносится как оптимальный, можно заметно оптимизировать.

(Управляющие карты)
(Посвящается Международному году Периодической таблицы химических элементов)
(Последние дополнения сделаны 8 апреля 2019. Список дополнений сразу под катом)


(Цветок Менделеева, Источник)

Помнится, мы проходили утку. Это были сразу три урока: география, естествознание и русский. На уроке естествознания утка изучалась как утка какие у нее крылышки, какие лапки, как она плавает и так далее. На уроке географии та же утка изучалась как житель земного шара: нужно было на карте показать, где она живет и где ее нет. На русском Серафима Петровна учила нас писать «у-т-к-а» и читала что-нибудь об утках из Брема. Мимоходом она сообщала нам, что по-немецки утка так-то, а по-французски так-то. Кажется, это называлось тогда «комплексным методом». В общем, все выходило «мимоходом».

Вениамин Каверин, Два капитана

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

Assembler – мой любимый язык, … но жизнь так коротка.

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

Зная себя, я уверен, что игра едва получит своё воплощение, но возможно кого-то из общественности заинтересуют мои наработки на этом тернистом пути. И так приступим.

Мир суровый, но маленький и возможности его изменить есть у каждого. В 1996 году начиная изучать только что появившийся Delphi, я не мог себе представить, какая будет судьба у этого языка, который сильно повлиял на Java и C#, а также какая судьба будет у самой компании Borland, от названия которой у каждого олдскульного кодера идут мурашки по коже.

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

Всем привет!

Сам я криптографией не занимаюсь, но кому то вполне может пригодится мое небольшое исследование. Решил разобраться со встроенными в процессор функциями RDRAND и RDSEED. Компилятор Delphi сказал Undeclared identifier. Хмм. Уже давно существует BMI, BMI2, AVX, AVX2 и даже AVX-512, а дельфийцы остановились на SSE4.2. Не беда. Скомпилируем код сами.

Сначала сделал проверку на поддержку данных функций процессором. Конечно же CPUID. Использовать CPUID можно начиная с первых Pentium процессоров. Надеюсь никто не додумается запустить CPUID на 486 машине, ибо ее там еще не было. Кстати RDRAND и RDSEED до процессоров IvyBridge также не существует.

function CPU_support_RDRAND: Boolean;
asm
  mov rax, $01
  cpuid
  test ecx, 40000000h //тестируем 30-й бит
  setne al
end;

function CPU_support_RDSEED: Boolean;
asm
  mov rcx, 0
  mov rax, $07 //страница №7
  cpuid
  test ebx, 40000h //тестируем 18-й бит
  setne al
end;

Оказалось, что мой Core i7 G6950X Extreme поддерживает данные функции. Поэтому дальше решил скомпилировать байт-код вручную. Для опытных приведу код REX и REX.W префиксов. Возможно вы захотите записать результат в другой регистр:

const
  REX_RDRAND32: Byte = $F0; //(11b:REG, 110b:OPCODE, 000b:EAX) 
  REX_RDSEED32: Byte = $F8; //(11b:REG, 111b:OPCODE, 000b:EAX)
  REX_W_RDRAND64: Byte = $48; //(11b:REG, 110b:OPCODE, 000b:RAX)
  REX_W_RDSEED64: Byte = $48; //(11b:REG, 111b:OPCODE, 000b:RAX)

От переводчика

Есть две причины, по которым я взялся перевести несколько материалов по разработанному двадцать лет назад для не самой популярной ныне среды программирования фреймворку:

1. Несколько лет назад я, познав многие прелести работы с Entity Framework как ORM для платформы .Net, тщетно искал аналоги для среды Lazarus и в общем для freepascal.
Удивительно, но хорошие ORM для нее отсутствуют. Всё, что тогда удалось найти — open-source проект под названием tiOPF, разработанный еще в конце 90-х годов для delphi, позже портированный под freepascal. Однако этот фреймворк коренным образом отличается от привычного вида больших и толстых ORM.

Визуальные способы проектирования объектов (в Entity — model first) и сопоставления объектов с полями таблиц реляционной базы данных (в Entity — database first) в tiOPF отсутствуют. Разработчик сам позиционирует этот факт как один из недостатков проекта, однако в качестве достоинства предлагает полную ориентацию именно на объектную бизнес-модель, стоит лишь один раз похардкодить…