https://forum.antichat.xyz/attachmen...4388229121.png

В штате буквально всех современных ОС имеется служебный персонал теневого фронта - в Windows его назвали службы "Services". Здесь мы рассмотрим интерфейс программирования их на ассемблере fasm, а так-же способы обмена данными с пользовательским приложением. В качестве практического руководства с нуля напишем софт, который позволит расшифровать пароли Wi-Fi на текущей машине (актуально для буков).

1. Общие сведения
2. Диспетчер SCM - Service Control Manager
3. Процесс службы в сессии(0)
4. Программа управления службой в сессии(1)
5. Заключение

1. Общие сведения

Служба Win - это работающее в фоне приложение без привычного интерфейса (окна). Главное отличие службы от обычной программы - контекст выполнения. Их запускает процесс svchost.exe (Service Host) в закрытой сессии(0) от имени специальных/трёх учётных записей: это Local System, Local Service, и Network Service. Они живут своей жизнью независимо от того, вошёл кто-то в систему, или нет. Службы работают в адресном пространстве пользователя, а не как драйвера в пространстве системы, со всеми вытекающими.

1.1. Ключевые характеристики

• Фоновый режим: Нет окон, диалогов, иконок в трее, хотя служба может общаться с юзер-приложением.
• Автозапуск: Можно настроить на запуск при старте ОС, или в ручную.
• Привилегии: Имеют расширенные права доступа к системе и оборудованию.

1.2. Типы запуска "Start Type"

• Auto: Стартует при загрузке системы.
• Demand: Запускается через ~2 минуты после ОС, чтобы юзер быстрее увидел рабочий стол.
• Manual: Запуск только при необходимости (например, подключаем принтер).
• Disabled: Отключена - функционал полностью заморожен.

1.3. Учётные записи "Security Context"

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

1. LocalSystem: Наивысший уровень, с полным доступом ко всей системе. В некоторых случаях опасно, т.ч. есть ещё 2 альтернативы.

2. LocalService: Мин.привилегии на лок.машине. В сеть выходит как анонимный пользователь.

3. NetworkService: Аналогичен (2), но в сети авторизуется от имени "MachineName$", что позволяет работать с сетевыми ресурсами, и ActiveDirectory.

Ранее уже обсуждались сведения по сессиям и учёткам, поэтому повторяться не буду - вот линк:
https://codeby.net/threads/asm-demony-v-windows-1-sessii-stantsii-rabochiye-stoly.79421/

2. ДиспетчерSCM - Service ControlManager

Управлением служб занимается "Service Control Manager" (диспетчер управления). По факту это процесс services.exe, который запускается самым первым при загрузке ОС. SCM выполняет три главные задачи:

1. Поддержка базы-данных в ветке реестра
, где хранятся записи о каждой службе: её имя, тип запуска, путь к файлу, и параметры восстановления при сбое.

2. Запуск и остановка. По команде админа (или типу запуска в реестре) SCM создаёт процесс службы, и управляет её жизненным циклом.

3. Коммуникация. Службы сообщают SCM о своём состоянии: Выполняет инициализацию, Запущена, Останавливается.

Современные версии Win активно используют концепцию совместного размещения служб. К примеру некоторое их подмножество может работать внутри одного процесса svchost.exe. Это сделано для экономии памяти (общие dll не дублируются). Но есть и обратная сторона медали: если упадёт один процесс svchost в котором живёт 10 служб, все они станут недоступны. Получить список служб для каждого из активных процессов можно командой
.

На схеме ниже видно, что любой запрос к службе от приложения проходит через SCM. Если служба находится в состоянии "Running", она обязана функцией
периодически сообщать диспетчеру, мол "в Багдаде всё спокойно" и я просто жду команд. Иначе SCM посчитает, что у неё имеются какие-то проблемы, и принудительно удалит из памяти (хотя может перезагрузить). Это один из основных нюансов при программировании служб Windows.


3. Процесс службы в сессии(0)

Служба это не просто EXE-файл. Чтобы приложение стало службой, оно должно быть написано по строго определённому протоколу:

1. Уметь принимать команды SCM, типа остановка, пауза, продолжение работы.
2. С периодом не более 30-сек (дефолт) сообщать диспетчеру о своём состоянии.

Значит точкой входа в службу является процедура обратного вызова Main(), которая через
сразу должна зарегистрировать основной поток нашей службы. Суть в том, что внутри одной службы может быть контейнер до 64 дочерних служб, как показано на рис.ниже. При этом SCM каждому выделяет свои потоки Thread. Но ничто не мешает собрать весь перечисленный ниже функционал типа сеть, FS, мониторинг и прочие внутри одного основного потока. То-есть это просто такая архитектура, без навязывания прогерам:

У функции
всего 1 параметр - это указатель на таблицу, которая содержит в себе по 2 указателя для описания каждой службы: первый линк на имя, а второй на точку-входа ServiceMain(). Терминальный нуль прихлопывает таблицу. Вот фрагмент, как это реализовано у меня:

C-подобный:


Основная проблема при написании служб - это их отладка. В сети предлагают различные методы типа "юзай WinDbg" и прочие, но все они мутные и лично у меня не работают. Поэтому приходится отлавливать блох в слепую, а результат проверять например в программе "ProcessHacker". Эта крутая тулза выдаст всю необходимую инфу о службе, включая просмотр свойств по Enter. Как видим наша служба исправно запустилась и находится с состоянии Running, ожидая от нас команд.

Обратите внимание с какими правами она запустилась - это LocalSystem, что является псевдонимом SYSTEM, т.е. наивысшие права, которых нет даже у админа системы. Как уже упоминалось ранее, это может представлять уязвимость, однако в частных случаях требуется именно System, например для декрипта паролей функцией
, о чём пойдёт речь далее.

А вообще права задаются в аргументе lpServiceStartName функции
- это указатель на строку вида "NT AUTHORITY\LocalService". Если в этом аргументе нуль, то в дефолте назначается именно System.


4.1. Поиск и чтение паролейWi-Fi

Если кто забыл, вся эта заваруха со службами нужна была для декрипта паролей Wi-Fi на локальной машине. Забегая вперёд скажу, что с основным функционалом придётся повозиться - это работа с файлами, и нудный поиск в них текстовых строк (без этого никак). В общем зайдём из далека..

В Win-XP настройки сети Wi-Fi прописывались в следующей ветке реестра.
Здесь каждый интерфейс представлен уникальным GUID, и все его настройки хранятся в значении "ActiveSettings". HKLM\Software\Microsoft\WZCSVC\Parameters\Interfac es\{GUID}

Но начиная с Vista майки отказались от реестра - теперь все параметры хранятся в файле конфигов XML по пути:
C:\ProgramData\Microsoft\Wlansvc\Profiles\Interfac es\{GUID}\Random-GUID.xml

В каждом профиле беспроводной сети хранится инфа о названии сети Wi-Fi, параметрах безопасности (аутентификация, шифрование), и собственно сам зашифрованный пароль. Вот типичное содержимое одного из таких файлов:

XML:


Дадим определение основным узлам этого xml-файла:

1. Имя сети Wi-Fi прописывается в разделе , которое хранится как в ASCII (здесь COMNET_16), так и в HEX-формате.

2. В узле найдём методы аутентификации (здесь WPA2PSK) и шифрования (почти всегда AES).

3. Инфа о пароле лежит в узле - значение указывает, зашифрован пароль(true), или хранится в открытом виде(false).

4. Сам пасс зарыт в узле и это то, что нам предстоит вытащить из xml, и передать его в нашу службу.

5. В некоторых роутерах есть опция рандома МАС-адреса, тогда можно заглянуть в узел (здесь enable=false, и других я не встречал).

На резонный вопрос "зачем передавать готовый HEX-пасс службе" можно ответить, что он шифруется функцией
из либы Crypt32.dll, при этом ни соль, ни какой-либо доп.ключ не используются, что на первый взгяд делает декрипт простым. Однако защита в том, что само шифрование производится одной из системных служб под учётной записью именно System, так-что даже под админом мы не сможем его расшифровать. Тут у нас всего 2 варианта - или внедрять шелл через удалённый поток в системный процесс Lsass.exe (метод довольно рискованный, т.к. любая ошибка может привести к краху всей системы), или-же просто создать свою службу в контексте System, что собственно мы и выбрали.

Имейте в виду, что крипт/декрипт должен осуществляться на одной машине, т.е. нельзя утащить чужой пароль, и пытаться расшифровать его на своём компьютере. Это механизм защиты DPAPI, который при шифровании под капотом формирует сессионный ключ текущей машины (имя юзера, GUID сеанса, и прочее), после чего сохраняет эту инфу прямо внутри зашифрованных данных. Если в момент расшифровки эти сведения не совпадут, то получим прокол.

Проблемы при работе с xml-файлом:

1. Поиск самого файла по адресу: C:\ProgramData\Microsoft\Wlansvc\Profiles\Interfac es\{GUID}\Random-GUID.xml
Ладно до папки ..\Interface у нас есть постоянный путь, а вложенную нужно вычислять, т.к. ей назначается произвольное имя {GUID}, впрочем как и самому файлу. Значит придётся через
найти имя папки, и вручную добавить его к известной строке ..\Interface (конкатенация). После этого повторить запрос
уже для xml-файла. Только теперь его можно будет прочитать
предварительно выделив память
.

2. Если всё ок, приступаем к поиску нужных узлов внутри xml.
Здесь вычислив общий размер файла
, от начала и до конца ищем символ(<) и через
сравниваем строки, заранее определив её длину. Готовые API использовать нельзя, т.к. в xml-строках нет терминальных нулей. Поскольку придётся искать разные строки для вывода их в окно, я написал универсальную процедуру. На входе она ожидает имя и длину строки для поиска:

C-подобный:


3. Пароль в xml-файле хранится в виде HEX-строки, в то время как функция расшифровки
ожидает бинарные данные в структуре DATA_BLOB. Значит получаем длину HEX-строки
, и переводим строку произвольной длины в число по такой схеме:

C-подобный:


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

5. Заключение

В скрепку положил исходник + готовый файл для тестов (запускать правой клавишей от админа). Семпл сырой и толком не протестированный. Поэтому при желании можете допилить его сами. В принципе подправить нужно будет только один аргумент в функции декрипта службы. Если коротко, то
использует мастер-ключи, которые могут быть привязаны или к конкретной учётной записи (флаг 0), или к конкретному компьютеру (флаг 4). Этот флаг указывается в предпоследнем аргументе функции, поэтому если код вернёт ошибку, нужно попробовать оба варианта в службе:

C-подобный:


Ссылки по теме:

• Описание сервисных функций от майков
Service Functions - Win32 apps

• Про учётную запись System
Учетная запись LocalSystem

• Детали DPAPI
Секреты DPAPI

• Софт для декрипта паролей (внедрение в lsass.exe)
DataProtectionDecryptor - Decrypt DPAPI (Data Protection API) data of Windows