Переходим по адресу 00007ffe0069fee2 и попадаем в раздел с системными вызовами библиотеки ntdll.dll Флаг условного перехода jne не активен, поэтому переход не осуществляется. Меняем jne на jz и прыгаем на первый ret. Выходим и попадаем в ядерную функцию KiUserCallbackDispatcher, в которой происходит обработка вызова режима пользователя Прототип KiUserCallbackDispatcher
// NtCallbackReturn никогда не вернётся, если что-то пошло не так for (;;) RtlRaiseStatus(Status); }
Снова вызывается NtCallbackReturn (срабатывает ранее измененный условный переход и syscall не происходит). И дальше начинается свистопляска с RtlRaiseStatus С mov B10 на call B4A бесконечный цикл (for (;;)) с исключением c000041d. В теории, обратные вызовы режима ядра к пользовательскому режиму жестко завязаны на архитектуре окон. По идеи где-то должен быть user32!_fnINLPCREATESTRUCT -> user32!DispatchClientMessage (и драйвер win32k.sys, который обрабатывает создание окна в режиме ядра), который судя по всем и выдает то сообщение. Но я кроме gdi32full.dll пока ничего не увидел.
В общем антидебаг отменный повешен, с ходу так и не разберёшь.
Это на ntdll.dll До вмок там ещё как до Китая. Очень много ядерных процедур проходит, прежде чем код вернётся в основной поток.
Может я конечно что-то и путаю (всё же не хакер, а просто программист), но продвинутся за syscall можно так: 1. Патчим ZwCallbackReturn по адресу 00007FFE0069FED0 2. Патчим ZwQueryInformationProcess по адресу 00007FFE006A0150 3. Патчим ZwTraceControl по адресу 00007FFE006A3540 4. Патчим ZwQueryDebugFilterState по адресу 00007FFE006A2500 5. Патчим je ntdll.7FFE006D2343 в jne ntdll.7FFE006D2343 по адресу 00007FFE006D2339
После этого я наконец-то увидел загрузку ACOrigins.exe в модуле ntdll.dll
k3rnel-pan1c, А НФС ковырял? Не знаешь по какой причине может быть такая задержка? Ну т.е. есть ли там что то, что могло бы задержать взлом? Или все же ее не ломают по другим причинам?
Вот кстати о чем-то подобном только хотел написать...никто не подумал, что может что-то случилось) причем скорее у стимпанков (если это вообще не один человек), всякое бывает, в больницу попал человек (если группа, то например тот кто особенно хорошо разбирается) или дома проблемы какие, не до взлома так сказать...а CPY как по мне вроде так и не стали ускоренно делать релизы, вот они может сидят разбирают ассассина
Походу ещё и RtlUnhandledExceptionFilter палит отладчик и её тоже нужно обходить. x64dbg создаёт процесс с флагами отладки. RtlUnhandledExceptionFilter, используя функцию NtQueryInformationProcess, определяет выполняется ли процесс по отладчиком, т.е. был ли он создан с флагами DEBUG_ONLY_THIS_PROCESS или DEBUG_PROCESS. Если процесс запущен под отладчиком RtlUnhandledExceptionFilter возвращает EXCEPTION_CONTINUE_SEARCH. [off]Тут нужно посмотреть SetUnhandledExceptionFilter, это пользовательский фильтр исключений (callback функция). Возможно здесь юбики и навесили антидебаг. В таком случае RtlUnhandledExceptionFilter помещает в глобальную переменную новый адрес пользовательской callback функции и возвращает адрес старой.[/off] После, RtlUnhandledExceptionFilter формирует диалоговое окно Application Error из функции NtRaiseHardError. Теоретически его можно избежать: либо вызвав функцию SetErrorMode с флагом SEM_NOGPFAULTERRORBOX до возникновения исключения, либо параметр AeDebug в реестре должен быть равен 1. В общем при отладке внутри RtlUnhandledExceptionFilter у меня сработала printf с ошибкой No Valid Win32 Error Mapping.
yoi386, да хз. Меня удивляет, что даже сами CPY не могут справиться. Ладно панки и кодекс. Кодекс так вообще непонятно, с какой целью зарелизили тени мордора, тем самым дав надежду и показав, что и они не пальцем деланные, что и они могут распотрошить игру на которой есть 'Д'. А потом так вообще объединяются с панками, чтоб взломать этот несчастный симулятор автобуса и южный парк?
Вам здесь уже даже разбирающийся человек наглядно показал,что неплохо доработали защиту в 4.7 версии, отсюда и задержки, а вы всё заговоры массонов ищите
Другое дело, что группы могли бы поломать старые релизы пока что с серьезными обновами, раз застой интеллектуальный, непонятно почему они это не делают,а вместо этого ломают симулятор автобуса с протектом(и не лень же им было )
Ripper174, Они,скорей всего,не геймеры,а программеры,вот и у них «спортивный интерес» защиту преодолеть,а не по рейтингу игр выстраивать приоритет взлома
roadrunner, ну в таком случае остался еще Handball 17 с трешкой,почему бы им его не сломать Да и Anno/Heroes 7 тяжело назвать взломанными,ибо аддоны серьезные вышли.
Те же кодексы релизят обновы на обычные игры только так,так что вряд ли они "не в курсе" что надо бы обновить игры с денувой старые,думаю у них не только спортивный интерес
Вам здесь уже даже разбирающийся человек наглядно показал,что неплохо доработали защиту в 4.7 версии, отсюда и задержки
Эм... где? Ты про посты о Assassin's Creed Origins? Так там про денуву ни слова, до нее он еще не добрался, все эти антиотладки к ней не имеют никакого отношения. Про NFS он же написал что не ковырял ее из-за отсутствия лицензии.
Дата: Воскресенье, 19.11.17, 03:04 | Сообщение # 9193
ЦитатаKidefo ()
Тогда к чему всё это было написано?
Почему то все бегут вперед паровоза) Что нужно чтобы спокойно трассировать vm'ки? Нужно закинуть экзешник в отладчик и (утрировано) сидеть отлавливать триггеры. Но кое-что мешает это сделать - антидебаг. Можно сказать это первый уровень защиты, второй и третий это vmp и denuvo. Пока не будет снят антидебаг, ни о какой речи про vmp и denuvo быть не может. Антидебаг здесь ядерный (так просто не отловить). В обычном смысле слова точкой входа является первая инструкция в программе (например main). Но мало кто догадывается, что перед тем как процессор начнёт выполнять main, в ядре ОС происходит целая процедура подготовительных работ. Начинается она с LdrpInitializeProcess (функция инициализации процесса). Здесь подготавливаются регистры, контекст, а также она вызывает Kernel32ThreadInitThunkFunction из kernel32.dll (функция BaseThreadInitThunk), которая подготавливает основной поток (процесс один, а потоков у него может быть много). В LdrpInitializeProcess происходит ещё целая серия инициализации других функций, но их значимость сейчас неинтересна. Далее процесс подготовки передаётся в функцию _LdrpInitialize. Здесь обрабатываются образы, пулы, wow64 и прочее. Затем процесс возвращает LdrpInitialize для дальнейшего перехода к LdrInitializeThunk. Именно в LdrInitializeThunk все потоки пользовательского режима начинают свое выполнение (можно сказать что это своеобразная точка входа для точки входа). Эта функция вызывает NtContinue и завершается. И вот только теперь начинается main. Вся эта хрупкая конструкция ломается в АСО на этапе передачи информации между ntdll.dll и kernel32.dll (BaseThreadInitThunk), в момент когда в регистр rcx попадает ловушка (подозреваю эта qword ptr [rcx+10]=[000000000038E010 <&Ordinal261>]=<acorigins.Ordinal261>). И всё, код выполняется совершенно по другой цепочке. На LdrInitializeThunk->NtContinue мы не попадаем, зато попадаем на NtCallbackReturn->syscall -> int 2e.
Дата: Воскресенье, 19.11.17, 03:23 | Сообщение # 9194
k3rnel-pan1c, скажи пожалуйста, какая у тебя сейчас цель? Посмотреть как работает денува и попробовать ее сломать? Тогда лучше работать с каким-нибудь Соником, к примеру, где нет такого антидебага, VMP и т.п. Или же ты конкретно хочешь сломать именно ACO? Тогда работа утраивается, ведь к денуве еще приплюсовывается антидебаг с VMP + не забудь об эмуляторе Uplay, универсального-то нет. Или у тебя цель просто засунуть ACO под отладчик, обойдя антидебаг?
Дата: Воскресенье, 19.11.17, 11:32 | Сообщение # 9195
k3rnel-pan1c, насчет "триггеров", их вообще не нужно трогать, если лицензия пропатчана/собрана полностью валидной по методу STEAMPUNKS и CPY. И насчет антидебага, ACO прекрасно дебажится, если поставить петлю кое-где и приаттачиться к процессу (разумеется, нужно произвести тщательную настройку ScyllaHide перед этим). Заметил, что ты много пересказываешь из того самого видео от Bronco и PainteR, многое сказанное тобой уже было показано в 1-й главе К тому же, как Haoose написал сверху, если цель исследовать новую Denuvo, начни с разбора нового Соника, там где нет слоя VMP.
Дата: Воскресенье, 19.11.17, 13:30 | Сообщение # 9196
Цитатаdeadmau5 ()
Заметил, что ты много пересказываешь из того самого видео от Bronco и PainteR, многое сказанное тобой уже было показано в 1-й главе
Что за видео? Про Bronco слышал, про второго нет. Я не пересказывал, а шёл самостоятельно с самого начала, и не знал, что оказывается уже есть какие-то наработки Ну ок, дайте тогда почитать/посмотреть, чтобы мне велосипед не изобретать. А то трачу время, а оказывается это уже всё пройдено.
Дата: Воскресенье, 19.11.17, 23:30 | Сообщение # 9198
Ну со стороны простого наблюдателя, не понимающего большинство сказанного, я предполагаю что человек просто ковыряет защиту потому что ему это интересно. Без конкретных целей. Кстати наблюдать за этим и мне интересно.
Дата: Понедельник, 20.11.17, 01:51 | Сообщение # 9200
ЦитатаReynor ()
Ну со стороны простого наблюдателя, не понимающего большинство сказанного, я предполагаю что человек просто ковыряет защиту потому что ему это интересно. Без конкретных целей. Кстати наблюдать за этим и мне интересно.
[spoiler=Игроки просят убрать DRM защиту Denuvo из игры Assassin's Creed: Origin's] Испанский геймер Хорхе Кастаньеда (Jorge Castañeda) создал петицию на сайте change.org с просьбой убрать DRM-защиту из экшена Assassin's Creed: Origins. По его мнению, системы защиты, использующиеся в новой игре от Ubisoft, оказывают сильное влияние на производительность и делают её неиграбельной для многих пользователей.
Системы защиты Denuvo и VMProtect — это две программы, которые направлены на предотвращение пиратства в Assassin's Creed Origins.
Проблема заключается в том, что они негативно влияют на пользователей, которые платят за игру. Это программное обеспечение заставляет Assassin's Creed: Origins использовать 100% ресурсов наших процессоров. Это оказывает сильное влияние на производительность во многих локациях и делает Assassin's Creed Origins неиграбельной для многих пользователей.
Ubisoft, пожалуйста, подумайте о своих клиентах, которые заплатили за эту игру, и удалите DRM, чтобы мы могли наслаждаться Assassin's Creed Origins с хорошей производительностью. Это негативно влияет на отличную игру. — Хорхе Кастаньеда О негативном влиянии Denuvo и VMProtect на Assassin's Creed Origins стало известно сразу после выхода игры. Тогда хакерская группа Revolt сообщила, что системы защиты дополнительно нагружают процессор на 30-40%. Источник и сама петиция по адресу: https://vgtimes.ru/news....ns.html [/spoiler]
(разумеется, нужно произвести тщательную настройку ScyllaHide перед этим). Заметил, что ты много пересказываешь из того самого видео от Bronco и PainteR, многое сказанное тобой уже было показано в 1-й главе 
