Как вы уже наверно знаете, Angular уже есть во многих платформах:
Ну и, конечно, здесь не хватало десктопа (не будем пока про Electron).
В WinAPI есть функция CreateRemoteThread, позволяющая запустить новый поток в адресном пространстве другого процесса. Её можно использовать для разнообразных DLL-инъекций как с нехорошими целями (читы в играх, кража паролей, и т. д.), так и для того, чтобы на лету исправить баг в работающей программе, или добавить плагины туда, где они не были предусмотрены.
В целом эта функция обладает сомнительной прикладной полезностью, поэтому не удивительно, что в Linux готового аналога CreateRemoteThread нет. Однако, мне было интересно, как он может быть реализован. Изучение темы вылилось в неплохое приключение.
Я подробно расскажу о том, как с помощью спецификации ELF, некоторого знания архитектуры x86_64 и системных вызовов Linux написать свой маленький кусочек отладчика, способный загрузить и исполнить произвольный код в уже запущенном и работающем процессе.
Для понимания текста потребуются базовые знания о системном программировании под Linux: язык Си, написание и отладка программ на нём, осознание роли машинного кода и памяти в работе компьютера, понятие системных вызовов, знакомство с основными библиотеками, навык чтения документации.
Все началось, казалось бы, с простого вопроса, который сначала ввел меня в ступор — "Зачем нужен make? Почему нельзя обойтись bash скриптами?". И я подумал — Действительно, зачем нужен make? (и самое важное) Какие проблемы он решает?
При разработке под linux возникают задачи создания интерактивных скриптов, выполняемых при включении или завершении работы системы. В system V это делалось легко, но с systemd вносит коррективы. Зато оно умеет свои таймеры.
Когда-то читал статью о выборе файловых систем «чтоб везде-везде работало». В ней в очередной раз увидел жалобы, что Ext4 замечательная файловая система, но на Windows есть только кривые неточные проприетарные драйверы. Но отмотаем ленту ещё на пару лет назад: тогда на Хабре (а в те времена — Гиктаймсе) пролетала новость про LibOS — попытку превратить Linux kernel в обычную библиотеку пользовательского режима. Упор там делался на вынос сетевого стека в user space. Как-то раз я решил поглядеть, а жив ли вообще проект, и в их блоге увидел ссылку на своего рода конкурента — проект Linux Kernel Library (LKL). По сути, это порт ядра, так сказать, на аппаратную архитектуру «библиотека пользовательского режима POSIX / Win32».
Чем интересна LKL? Во-первых тем, что она живёт и здравствует, пусть и не в основной кодовой базе ядра. Во-вторых, это более-менее честная поддержка «архитектуры», автоматически делающая доступной бОльшую часть ядра. Более того, прямо в комплекте идут утилиты-примеры: cptofs/cpfromfs, fs2tar, lklfuse. В этой статье мы протестируем LKL на хостовом Linux, заглянем в файл с образом Ext4 (Btrfs, XFS...) без рута и виртуалок и коротко обсудим, как её можно попробовать на Windows.
Небольшие по размеру фирмы с одной стороны, нуждаются в качественном мониторинге своей инфраструктуры (особенно в свете повсеместной виртуализации ), с другой стороны, для них финансово тяжело закупать новое оборудование. Также часто встречаются проблемы с серверной/аппаратной: зачастую стоит 1-3 tower-сервера рядом с пользовательскими рабочими местами или в небольшой нише/чулане.
Проще использовать уже готовую сборку(дистрибутив), который достаточно залить на microSD-карту и вставить в распространенный одноплатный компьютер (beaglebone, семейства raspberry pi и orange pi, asus tinker board). Кроме того, такое оборудование стоит недорого и может быть установлено в любом месте.
Забавное использование Ragel State Machine Compiler для создания функции разбора строки на int argc, char *argv[].
Все началось с того, что понадобилась функция buildargv, чтобы разбирать строку для последующей передачи в
int main (int argc, char *argv[]) { body }Ну ладно подумал я, не может быть, чтобы нигде нельзя было позаимствовать, сейчас найдем… И не нашёл...
WireMock — утилита, библиотека на java для создания заглушек над веб-сервисами. Он создает HTTP-сервер, к которому мы могли бы подключиться, как к реальному веб-сервису.
Fedora COPR — это бесплатный хостинг для размещения пользовательских репозиториев (аналог AUR в Arch Linux или PPA в Ubuntu). Из особенностей встроенная возможность собирать rpm пакеты указав имя PIP и RubyGems.
В этом посте напишу как собирать rpm из вашего репозитория по коммиту в Fedora COPR.
Еще раз просмотрев функционал утилиты cryptoarmpkcs, обратил внимание на то, что она, в основном работая с криптографическими токенами/смаркартами PKCS#11, не имеет встроенного функционала для их конфирурирования. Речь идет об инициализации токенов, установки PIN-кодов и т.п. И было решено добавить этот функционал. Первым делом для этого пришлось расширить функционал пакета TclPKCS11, библиотека которого написана на языке Си. ::pki::pkcs11::inittoken <handle> <slotId> <SO-pin> <label for token>::pki::pkcs11::inituserpin <handle> <slotId> <SO-pin> <USER-pin>::pki::pkcs11::setpin <handle> <slotId> <so | user> <oldpin> <newpin>
Что видит программист, начиная работать с языком C? Он видит fopen, printf, scanf и ещё много других функций. Видит он и всякие open и mmap — казалось бы, зачем их выделять? Но, в отличие от первой группы, эти две функции при выполнении на ядре Linux являются системными вызовами (на самом деле нет, почти никогда системный вызов нельзя просто вызвать как функцию, и поэтому libc содержит обёртки, перепаковывающие аргументы и иногда, как в случае с тем же open, заменяющие старые системные вызовы более общими новыми). Вообще, в отличие от тысяч библиотечных функций, доступных на типичной GNU/Linux системе, интерфейс ядра имеет довольно ограниченное количество точек входа — порядка нескольких сотен, зато то, что для user space — crash (например, обращение к отсутствующей странице), для ядра — default mode of operation.
В этой статье я расскажу некоторые интересные на мой взгляд факты. В ней не будет futex-ов и прочих скучных (наверное) деталей реализации. Будет преимущественно то, что вызывало у меня реакцию «А что, так можно было?!?».
Делая пере-реализацию QInst на LLVM, я столкнулся с такой проблемой: QEMU в режиме эмуляции одного процесса естественным образом перехватывает все «гостевые» системные вызовы. В итоге плагин инструментации имеет единую точку входа для их предобработки, где можно по номерам SYS_* и значениям аргументов принимать решения. Это довольно удобно. Проблема в том, что все системные вызовы делает, в основном, libc и, переписывая код статически, мы просто до этой части в большинстве случаев не доберёмся. Конечно, можно было бы использовать ptrace, который как раз предназначен и для этого в том числе. Но тогда не уверен, что получилось бы обойтись без отдельного процесса, а семантика QInst предполагала тривиальный «синхронный» перехват — пришлось бы как-то инжектить вызов обработчика, а это сильно сложнее привычного LD_PRELOAD. Можно оборачивать каждый системный вызов — но это, как минимум, неудобно (к тому же, можем что-нибудь пропустить, ведь в этом случае мы перехватываем на самом не системные вызовы, а их конкретные обёртки).
Под катом — решение, не привязанное к LLVM, но заточенное под Linux на x86_64 (но адаптируемое для Linux на других архитектурах).
Примечание: в этой статье не представлено универсального готового решения — оно лишь подходит для достаточно широкого списка случаев. Зато эту статью можно считать обзорно-пятничной: интересная (надеюсь) новая (для большинства?) информация, щепотка брутфорс-программирования и рабочие примеры. И пусть нашу пятницу не омрачает даже тот факт, что сегодня четверг!
Для полноценной работы с проектом на docker'е в WSL необходима установка WSL 2. На момент написания заметки ее использование возможно только в рамках участия в программе предварительной оценки Windows (WSL 2 доступна в сборках 18932 и выше). Так же отдельно стоит упомянуть, что необходима версия Windows 10 Pro для установки и настройки Docker Desktop.
Важно! В WSL 2 пропала острая необходимость в Docker Desktop для Windows 10. Как обходиться без него описано в пункте Про Docker в Ubuntu.