Доброго времени суток.

Сначала поясню что происходит:
У меня на руках Патч к новой версии приложения укреплённой .themida, этот Патч заставляет убрать приложение Dongle-проверку-Usb и сравнивать лицензию с файлом в папке(Естественно файл должен быть сгенерирован по алгоритму, это я и ищу). Сам патч, писал не я и мне нужна консультация чтобы понять, как им воспользоваться или вытащить алгоритм, что усложняется защитой ntdl.dll, не работой ScyllaHide, абсолютным отсутствием динамического анализа но обо всём по порядку. Сам патч у меня украли, долгая история

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

Что я пытаюсь делать:я пытаюсь проанализировать приложение статистически и динамически, оригинальное и модифицированное патчем

Вначале,у меня не получалось снять themida чтобы хотя бы взглянуть что экспортирует и импортирует приложение. unlicense с кучей костылев завелся и автоматически восстановил всю IAT и EOP. Такой файл у меня в
Анализ расшифрованного дампа в памяти невозможен ,я пытался вытащить сравниваемый ключ который должен быть создан и проверен с ключом из папки по HWID, но KsDumper(Kernel-Driver), Kernel-Level не работают, user-mode тем более. я не пробовал только remote debugger с VM, но судя по анализам приложение также видит, что его запускают на VM и принципиально отказывается запускаться.

При любой попытке обхода 64dbg с ScyllaHide и изменении rax регистра ожидаемого в выводе IsDebuggerPresent который бы ответил что "Дебага нет" даёт
Titan Hide - тоже не работает при попытке динамического анализа программы.

По ощущениям чем больше options в ScyllaHide 64dbg тем больше вероятность краша.
Все .dll которые подтягивает программа: скрин (1)

Сейчася напрочь застрял: не могу сделать динамический анализ и узнать где подтягивается функция криптографической проверки лицензионного ключа, раз
Два, .dll в которые как я понимаю(Это я хочу узнать) делается injection ТОЖЕ защищены .themida, их функции обфусцированы, трейс вообще непонятный, и даже после

Код:


У меня не получается отследить ни через F8, ни через фрагменты трейс функции в этом же инжекторе .dll который закидывает функцию в уже родную функцию программы. Эта функция или защищена themida или подтягивается динамически из уже пропатченных .dll которые сделали до меня? Ничего не понимаю

В общем, моя задача проанализировать .dll патча который заставляет программу вести себя подобным образом, и найти алгоритм по которому создается ключ лицензии. (Для отчета в компанию о уязвимости)
Почему Winapi override Win Api Monitor может НЕ ловить криптографические функции которые точно есть?

Как я вижу эту ситуацию:
1. Или программа настолько сложна что использует свои внутренние функции криптографии + memcpy не используя API Windows,
2. Или те кто делал патч до меня и украли мои же наработки, просто руководствовались вот каким интересом: пропатчили бинарник (Я не могу сказать что в оригинале, потому что не нашел функции в оригинале после unlicense), а код генерации Поменяли на свой лад, и используют функцию MinHook, как раз этот sub, чтобы сгенерировать ключ, сравнить с ожидаемым и чтобы о алгоритме генерации знали только эти люди. А оригинальный алгоритм затереть.

Поэтому вопросы такие:
1. Есть ли возможно узнать динамически подгружает ли инжектор свою функцию или нет из уже пропатченных библиотек? Если звучит абсурдно, то как обычно снимается защита на .dll по типу unlicense с бинарниками, чтобы почистить обфускации и глянуть саму функцию? (А её трейс как минимум замусорен). Какие инструменты использовать?
2. Есть ли смысл анализировать программу динамически и пытаться убрать сначала ошибку debugger detected in your memory, потом fatal error, чтобы найти алгоритм генерации или ожидаемый ключ (Уже расшифрованный в памяти)?
2.1 Как патч обходит проверку на уровне ЯДРА, ожидаемой контрольной суммы? Драйвер winspool.drv? Файлы ТОЧНО патчили уже после того как сделали инжектор. Тут я просто хочу услышать "матчасть" как обычно, легко, инжектор обходит такие проверки контрольной суммы, даже если у меня ругается на отладку переменной в IsDebuggerPresent? Как я понимаю ntdl.dll или themida имеют паттерны распознавания MinHook. И как они это сделали от ёё глаз для меня загадка.
3. Как мне вытащить название функции по которой сравнивается лицензионный ключ, чтобы скормить его MinHook, как я понимаю? И да, MinHook придётся писать заново или можно декомпилировать .dll, и добавить свои функции? А если .dll тоже защитили чем-то типа VMprotect?

И еще: да, я профан. Долго с этим вожусь. Читаю материалы. Прошло 3-4 дня относительно безперерывной работы. Поэтому пишу на форум чтобы меня направили за что извиняюсь. Будет лучше всего если будет вариант обсудить в лс некоторые детали, потому что ошибок на этом пути очень много было у меня.
За оформление тоже извиняюсь. Подправлю и предоставлю дополнительную информацию по требованию

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