Парни, доброго времени суток! Есть нетривиальный вопрос. Может кто-то сталкивался с подобной проблемой? Патчу из драйвера программу при её запуске. Через PsSetLoadImageNotifyRoutine. Всё работает . Почему я так делаю , да потому что программа весьма жёстко отслеживает свою целостность. Программа стартует и работает. Закрываю программу , запускаю снова и она не стартует. Потому что не проходит проверка целостности. Под отладчиком видно, что патч , сделанный мною из драйвера, остаётся на месте. Байты не оригинальные , а мои ) То есть или система кэширует состояние программы или что-то другое. После ребута компа опять всё нормально работает. Рабочая среда WIN 10-11 на VMWare. Программа накрыта последним SDK Codemeter. Как "это" отключить ?
Закрываю программу , запускаю снова и она не стартует. Потому что не проходит проверка целостности. Под отладчиком видно, что патч , сделанный мною из драйвера, остаётся на месте. Это не блокировка, а программа проверяет свою целостность. И так , как программа пытается запуститься в "патченом" виде, то в ход вступает фича CodeMeter защитного шелла и креш.
Она действительно его кэширует, что не подтягивать каждый раз образ с диска - за это отвечает служба Superfetch. Попробуй его отключить: msconfig -> Службы -> Сними галочку с SysMain -> Ребутнись.
В том всё и дело, что я ранее это "нагуглил" , остановил сервис Sysmain, "вычеркнул" из автостарта. И никаких улучшений. Возможно это вообще какая-то новая фича SDK (защитного конверта) CodeMeter. Ранее такого не было. Второй минус это мощнейший антиаттач , антидебаг. Никакие плагины не работают. Не для x64Dbg , не для IDA. И вишенкой на торте - отличный обфускатор. Приношу извинения, что не дал сразу все расклады.
Вообще, у тебя проблема из-за того, что когда ты патчишь память, у тебя не срабатывает Copy-on-Write. Скорей всего ты патчишь чем-то типа MmMapLockedPagesSpecifyCache/MmMapIoSpaceEx, и дальше пишешь прямо в полученное отображение - поэтому и портится общий кэш. Чтобы такого не происходило, надо патчить именно в юзермодных страничках, не переотображая их в ядро - через ZwProtectVirtualMemory, благо он экспортируется, начиная с десятки. Но здесь есть другой нюанс: насколько помню, в контексте Ps-каллбэка у тебя залочено адресное пространство процесса, поэтому ZwProtect ты там сделать скорей всего не сможешь (не уверен, надо попробовать). Чтобы это обойти, можно придумать что-то или с таймерами, чтобы патчить чуть-чуть позже, когда лок будет снят, или попробовать отправить процессу normal kernel APC, в которой уже сможешь пропатчить. Также можно попробовать сложный путь: сделать минифильтр, который на IRP_MJ_READ при чтении файла приложения будет отклонять FastIO, чтобы всегда идти "длинным" путём через чтение с диска. Также можно попробовать вытолкнуть файл из кэша: посмотреть куда-то в направлении CcUninitializeCacheMap, передав ему PFILE_OBJECT твоего образа (который можно получить через PsReferenceProcessFilePointer, передав ему PEPROCESS). Насчёт выталкивания кэша просто пальцем в небо - не знаю, к чему это приведёт, может оно вообще не связано с тем кэшем, где у тебя сидит процесс.
Интересная стратегия - вы там патчите, мы проверяли тупо(kpp), а теперь загрузим из кэша и что бы обойти нужно пол ядра перелопатить".. Cc* апи это вообще кернел дно и черный ящик. Анстаб у таких метод абсолютный
Нууу, всё-таки не пол ядра. Просто сама по себе задача "пропатчить что-то в процессе из ядра" - не такая простая, как кажется. А насчёт Cc - да, согласен, это больше апи для разработки файловых систем, но можно попробовать - вдруг что-то получится.
HoShiMin Это тривиальная проблема патчей, крэклаб тьюм и все такое. Защита палит патч, но по причине соотв. скилла пытаются повесить поверх патч. В юзер это после долгой возни с отладчиком кое как да и работает. Но вот в ядре такое не катит.. ТС должен найти ридеры(код валидации читающий защищаемый) используя какой либо монитор памяти и с этим далее работать, а не портить память. Обход защиты к примеру вмп именно такой. Может в юзер для начала порешить ?
В папке WinDbg есть утилита "GFlags", флагами в которой можно отследить процесс загрузки образа в память (апи и прочее). Не помешает просмотреть её логи, может найдётся что-нибудь интересное.
Драйвер-фильтр попробовать стоит конечно. --- Сообщение объединено, 11 янв 2025 в 09:47 --- Легко сказать , не глядя на программу... Обфускатор у CodeMeter не на коленке сделан. Как пример - сервис CodeMeter "весил" 6-7 мегабайт , которые превратились в 40 мегабайт. Думаете они добавили нового функционала в таком количестве? --- Сообщение объединено, 11 янв 2025 в 10:13 --- Программа , "накрытая" защитным конвертом CodeMeter проверяет Debug Mode системы и не стартует вообще. Поэтому всякие модные HyperDbg не "катят".
Я конверт не снимаю. Хотя он как раз и не сильно сложный, если не используется WUPI. У меня написан эмулятор этого донгла на основе виртуальной шины. И нет потребности в снятии конверта. --- Сообщение объединено, 11 янв 2025 в 11:31 --- Я использую x64Dbg. И при остановке программы на OEP (EP )сразу вижу, что по определённому адресу мои "патченые байты"
Походу вы не понимаете, о чём речь.. x64Dbg - это юзермодный отладчик, а WinDbg для кернел. Ставите WinDbg на хост, и соединяете его COM-портом с виртуалкой. В результате под отладкой оказывается вся ОС на VMWare, а не ваше приложение с CodeMeter. Софт (в ядре) может обнаружить факт своей отладки по таймерам и флагам в структуре KPROCESS (самое дно, что связано с процессом), а поскольку они будут сброшены, то вариант может дать результаты. Если и это не поможет, то сломав CodeMeter вы сможете заработать лям зелёных президентов. Код (Text): 0: kd> dt _eprocess fffffa800402eb00 Pcb.Header. nt!_EPROCESS +0x000 Pcb : +0x000 Header : +0x000 Type : 0x3 +0x001 TimerControlFlags : 0 <----------------- +0x001 Coalescable : 0y0 +0x001 KeepShifting : 0y0 +0x001 EncodedTolerableDelay : 0y00000 (0) +0x001 Abandoned : 0 '' +0x001 Signalling : 0 '' +0x002 ThreadControlFlags : 0x58 'X' +0x002 CpuThrottled : 0y0 +0x002 CycleProfiling : 0y0 +0x002 CounterProfiling : 0y0 +0x002 Reserved : 0y01011 (0xb) +0x002 Hand : 0x58 'X' +0x002 Size : 0x58 'X' +0x003 TimerMiscFlags : 0 +0x003 Index : 0y000000 (0) +0x003 Inserted : 0y0 +0x003 Expired : 0y0 +0x003 DebugActive : 0 <----------------- +0x003 ActiveDR7 : 0y0 <----------------- +0x003 Instrumented : 0y0 +0x003 UmsScheduled : 0y0 +0x003 UmsPrimary : 0y0 +0x003 DpcActive : 0 '' +0x000 Lock : 0n5767171 +0x004 SignalState : 0n0 +0x008 WaitListHead : _LIST_ENTRY [ 0xfffffa80`0402eb08 - 0xfffffa80`0402eb08 ] 0: kd>
То есть в настройки оси , которая на варе, не надо прописывать Debug Mode? Цитирую себя. Хотя это и нескромно ) "Программа , "накрытая" защитным конвертом CodeMeter проверяет Debug Mode системы и не стартует вообще. Поэтому всякие модные HyperDbg не "катят". "
надо, и я говорю, что ос окажется под отладкой. мимо отладки проходит только софт. и если в x64dbg доходит до точки ep, то утилита gflags сбросит лог прямо под юзером.
Не надо COM-порт, для ядерной отладки есть KDNET. --- Сообщение объединено, 11 янв 2025 в 12:47 --- Можно сделать ещё проще: при старте процесса снимать поставленный ранее патч, а на загрузке нужного модуля ставить снова. Тогда получится, что между запусками в кэше будет висеть образ с патчем, который восстановится на запуске, пройдёт проверку целостности, и тут же пропатчится снова.
