Привет всем! Форум читаю достаточно давно, узнал много нового, но сейчас возникли вопросы, на которые я не смог ответить самостоятельно, поэтому прошу помощи.

Сначала краткая предыстория. Крякингом я занимаюсь меньше полугода, научился за это время ломать сильно тупые защиты, где разработчик понадеялся на упаковщик/протектор. Автоматическим распаковщиком (или на "полуавтомате" - break'n'enter - EP - bpm esp-4 - OEP - dump - ImpRec) снимаем защиту, патчим пару байт - и готово. Но это, понятно, проходит далеко не всегда. Тупая защита + не самый простой пакер = приехали
И где-то месяца 2 назад я начал писать собственный универсальный распаковщик. Принцип действия у него задумывается такой:
- создаём замороженный поток.
- в EP втыкаем хук (jmp eip, чтобы не трассировать стандартным методом через TF, что обычно палится защитой) отпускаем программу до EP, замораживаем (SuspendThread), снимаем хук.
- далее эмулируем работу подопытной программы на виртуальных регистрах, но на её реальной памяти (Read/WriteProcessMemory).
- при этом ловим программу при возникновении исключений на входе в обработчик и на выходе из него; на возврате из системных вызовов (KiFastSystemCallRet); вообще, полностью отслеживаем передачу управления. Для этого предусмотрено втыкание хука в любое нужное место.
- на всём пути выполнения каким-либо образом запоминаем порядок передачи управления и адреса участков памяти, которые были изменены в адресном пространстве подопытной программы.
- когда доходим до OEP (определим, например, на основе статистики по нескольким файлам, покарёженных одним и тем же пакером), дампим всё, что было изменено.
- восстанавливаем импорт (пока с этим вопросом подробно не разбирался)
- делаем ещё какие-нибудь дополнительные приседания
- получаем рабочий дамп, который можно изучать в дизассемблере

Понятно, что, например, для Armadillo дополнительных приседаний будет очень много, но ASProtect вполне мог бы поддаться на такую провокацию.
С него я и решил начать. Запаковал виндовский блокнот с помощью ASProtect2.1, научился проходить на EP и стал "обучать" свой распаковщик ассемблерным инструкциям по одной. Проверка простая: если при встрече с незнакомой инструкцией актуализировать контекст и отпустить программу (ResumeThread), и она не грохнется, то с большой вероятностью все предыдущие инструкции выучены правильно.

<отредактировано Wolfram>
(Перенёс первый вопрос в свой второй пост, чтобы он не повторялся на каждой странице)

Заранее спасибо за ответы. Прошу модераторов не закрывать данную тему, когда они будут получены, потому что распаковщик пишется, и новые вопросы непременно будут возникать.

| Сообщение посчитали полезным:

Gideon Vi
Обучалась вобщем так: Уних в базе были забиты пакеры-проты и когда что то попадалось новое эта прога анализировала действия крякера в отладчеке и добавляла в свою базу новый способ распаковки.
И если напремер прот вел себя не совсем стандартно но есть на него сигнатура и способ взлома она могла додумать как поступить в том или ином случае.
Например как в аспре исключительные ситуации или импорт,прога такое запросто фиксила сама.

Вобщем теми людми кто это писал был проделан адский труд.

Приятно было посмотреть на такого монстра в действии.

| Сообщение посчитали полезным:

в том-то и дело, что не просто адский. тем страннее, что нигде не всплывало.

| Сообщение посчитали полезным:

F_a_u_s_t
Чушь какая-то. Кто же с тобой поделился такой исчерпывающей инфой, я бы ему медаль дал!
Gideon Vi пишет:
нигде не всплывало
Даже если такое чудо и есть (в чём я очень сильно сомневаюсь) оно не всплывёт никогда, по крайней мере для обычных смертных. Ну типа только private version.

| Сообщение посчитали полезным:

MasterSoft, есть такая штука, как тщеславие. Пока что ничего круче темного анпакера не выплывало.

| Сообщение посчитали полезным:

F_a_u_s_t пишет:
Уних в базе были забиты пакеры-проты и когда что то попадалось новое эта прога анализировала действия крякера в отладчеке и добавляла в свою базу новый способ распаковки.
Это типа фантазии на тему любимого китайцами олимашин )Gideon Vi пишет:
Пока что ничего круче темного анпакера не выплывало.
Такая же байка

| Сообщение посчитали полезным:

PE_Kill пишет:
А это как вообще может быть? Эмулируешь команды, а ругается винда??? Как при эмуляции прога может упасть??? Может возникнуть эксепшн в эмуляторе, но прога то при чем, это же не процесс а образ в эмуляторе.
ИМХО понос мыслей.

Нет, это именно процесс, который запускается и тормозится на EP. Может быть, следовало написать "трассировка" вместо "эмуляция" (мне кажется, что здесь и то, и другое), но принцип такой: анпакер работает на виртуальных регистрах (переменные в адресном пространстве анпакера) и на памяти программы (в её адресном пространстве). Через ReadProcessMemory читаем очередную инструкцию, если нужно, читаем некоторую область памяти программы (ReadProcessMemory), изменяем значения переменных, соответствующих регистрам, изменяем некоторую область памяти программы (WriteProcessMemory). При встрече с неописанной пока инструкцией делаем SetThreadContext и ResumeThread. И если перед этим мы что-то не то сделали в адресном пространстве проги, или установили не тот контекст, то она упадёт! Поскольку падает не на первой инструкции, то, думаю, такой метод имеет право на существование.

Archer пишет:
Глядя на концепт-сразу скажу про потенциальные косяки и ограничения:
-патчить код на оеп не всегда хорошо, ТЛС коллбек может пропалить это;
-полная эмуляция кода распаковщика штука адская, учитывая трюки антэмуляции и тд, писать будешь до пенсии;
-если дампить всё, что изменено, дамп будет под 100М, ибо там будет стек, куча, возможно, патч системных либ и фиг знает, что ещё;
-если за основу ОЕП брать статистику по пакеру, это не generic unpacker, а multi unpacker, другими словами, неизвестное не возьмёт;
-не совсем ясно, как ставится хук, если за основу взят DebugApi-это зло;
-некоторые концептуальные вещи могут быть не охвачены, типа многопоточности: иногда расшифровкой кода занимается 1 поток, он запускает поток 2, который и идёт на оеп, а 1 дохнет, как это будет обработано-хз.
Я не ставлю цель, чтобы брал всё и сразу. Про TLS и многопоточность знаю, но не все же пакеры их используют. Обработку всех этих фишек буду прикручивать потом, а пока считаем, что их нет.
Хук в моём анпакере - это 2 байта 0xebfe (jmp eip). Если нужно, чтобы какой-то кусок кода исполнила сама программа, то сразу после него втыкается такой хук, а затем ждём, когда управление дойдёт до него, а дальше, очевидно, не пройдёт. Теперь останавливаем поток и возвращаем оригинальные байты на место. Этот метод я уже проверил, пока работает без косяков.
Если не сложно, расскажи, пожалуйста, про трюки антиэмуляции, которые могут испортить жизнь при _таком_ подходе (кроме многопоточности).

Собственно, к вопросу про mov. SetThreadContext работает, но как-то странно. Устанавливается только eip, остальные регистры остаются без изменений. Кто-нибудь может объяснить, почему так происходит, и что с этим делать?

| Сообщение посчитали полезным:

Трюков антиэмуляции может быть много, начиная с того, что цикл какой-нить с парой инструкций выполняется много раз, на чём эмуль задумается надолго, и заканчивая вызовом разных апишек (а ты их не эмулишь, как я понял) и дальше управление может быть передано (может, апи хитрая, может, код подправлен) в произвольное место, а не сразу после её вызова, тогда контроль потеряешь. Обращения к невалидной памяти тоже хз, как эмулить будешь, надо исключение кидать, а чтоб не потерять управление разглядывать СЕХИ/ВЕХИ/UnhandledExeceptionFilter. Это из основного, что сходу в голову пришло.
С SetThreadContext, имхо, после ЕП не может он работать странно в 1 потоке. Сам забыл выставить регистры в контексте, флаги контекста, проверяешь неправильно или что ещё.

Не совсем понятно, как анпакер может обучаться. В теории оно звучит хорошо, конечно, а в реальности хз. Видео даёшь ему посмотреть, что ли, а он втыкает и учится...

| Сообщение посчитали полезным:

Flashback/TMX пишет:
на каком-то сайте видел тутор для написания дескремблера UPX

Может это мой тутор?
www.azsoft.nm.ru/art/n0.htm

ps. Прога и полностью на прологе... Жесть.

-----
Я медленно снимаю с неё UPX... *FF_User*

| Сообщение посчитали полезным:

F_a_u_s_t пишет:
Просто знаю одни черти писале на прологе софтину-анпакер с AI самое интересное что оно реально работало причем еще и самообучалось.
Skynet?

| Сообщение посчитали полезным:

F_a_u_s_t Прав что есть такой анпакер. Всплывать он и не будет , люди которые его делали занимаются наукой и делом. На вопрос бываете ли вы на форумах по системам защиты, ответ был таков - нет не бываем , мы учим будущие поколения , все самые новые технологии рождаются у нас.

У меня есть повод , ну оч большой доверять им по самое нехочу.

ASMax в шутку называют так сами разработчики , есть 2 варианта реализации. Первый это был не столь интересный , в основном методы математические по ИИ. А вот потом был бум , был создан организм , как его назвать фиг знает , он как бы и техниа и живой , он может думать как человек и в тоже время является кибермашиной. В основу мозга положена находка биологов. Которые нашли жизнь схожую с нашей, но которая перестала развиваться по каким то причинам. Это особый кристаллический состав , точнее это квазикристалический состав. Его мощность мыслительсная состоит просто из невероятной вычислетельной силой и скорости обучения.

А вообще второму виду мало уделяют внимания , имеется ввиду по анпкам, потому что с такой машиной появились другие задачи.

Archer скоро увидишь =) уже вон сколько людей над этим работают

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

| Сообщение посчитали полезным:

Вот уж точно, сон разума рождает чудовишь )

| Сообщение посчитали полезным:

Ребенки, сочинять - это тоже уметь надо. Идея отладки такого рода систем на апаке смешна и нелепа, попытка выебнуться на таких утках глупа и убога.

| Сообщение посчитали полезным:

Я понял, мы все умрём, боты нас поработят. Не то, чтобы я совсем не верил в движение прогресса и революционные открытия, но как-то сомнительно, что они придут ко мне, чтоб анпачить мне упх.
Предвижу тут адский оффтоп, поэтому сразу говорю, давайте с этим понемногу завязывать и ближе к теме держаться.

| Сообщение посчитали полезным:

mak пишет:
был создан организм , как его назвать фиг знает , он как бы и техниа и живой , он может думать как человек и в тоже время является кибермашиной. В основу мозга положена находка биологов. Которые нашли жизнь схожую с нашей, но которая перестала развиваться по каким то причинам. Это особый кристаллический состав , точнее это квазикристалический состав. Его мощность мыслительсная состоит просто из невероятной вычислетельной силой и скорости обучения.

Ссылками на материалы по теме не угостишь?
Можно даже на мед.ресурсы, так даже лучше.

-----
Я медленно снимаю с неё UPX... *FF_User*

| Сообщение посчитали полезным:

to all:
Ну конечно все это чушь,просто решил проверить теорию спекза что флудерры номер 1 как раз старички а не нубики.
Извините меня не удержался.
mak
Я тоже где то читал подобное ну как сказал Gideon Vi Идея отладки такого рода систем на апаке смешна и нелепа... другое дело научные иследования.
Archer
Обещаю больше не ставить таких флудерских экспериментов.

| Сообщение посчитали полезным:

Втему:
Не у кого не завалялся сорец анпакера (любого,[упыха) на делфи.

Ps. и помните я извинился!

| Сообщение посчитали полезным:

F_a_u_s_t
Вот: ap0x.jezgra.net/SDK.rar

| Сообщение посчитали полезным:

Поскипал справедливый гнев толпы, хотя саму провокацию оставил для потомков. Больше так лучше не делать, а то плохо кончится.

| Сообщение посчитали полезным:

AlexZ пишет:
Может это мой тутор?
Да, я про него, но адресс не помнил

pavka пишет:
Это типа фантазии на тему любимого китайцами олимашин
Это недоделанный ОллиСкрипт?

| Сообщение посчитали полезным:

Это снова я со своим распаковщиком.
Проблему с неустанавливающимся контекстом я решил, правда, через , так что не кидайте помидорами. Вписываем на eip такое:
mov eax, ...
mov ecx, ...
..................
push ...
popf
jmp eip
отпускаем прогу, замораживаем на jmp, возвращаем всё на место.
Невероятно, но это работает! Нормальное решение пытался найти, но SetThreadContext не хочет устанавливать ничего, кроме eip, хоть ты тресни.

Рапаковщик уже знает около 200 инструкций. Т.е. берём прогу, запакованную чем-то, он доходит до первой неизвестной инструкции, сообщает об этом и отпускает прогу, и она после этого не грохается.

В ASProtect выученных инструкций уже хватает, чтобы дойти до первого вызова VirtualAlloc и пройти её код до системного вызова sysenter (0x0f34). Обратно в ring3 управление вернётся на KiFastSystemCallRet. У меня на XP SP2 она находится по адресу 0x7c90eb94. Теперь можно отпустить прогу, а потом поймать, или использовать VirtualAllocEx, чтобы эмулировать вызов. Второй вариант мне нравится больше, правда, тогда придётся и другие вызовы эмулировать, но мы же не ищем лёгких путей!

Отсюда вопрос: положение KiFastSystemCallRet зависит только от версии ОС, или от чего-то ещё?
И ещё один вопрос: можно ли без написания ring0 драйвера (я этого пока не умею) прочитать дескрипторы сегментов, зная их селекторы? Может, где-нибудь в нижней половине памяти лежит копия GDT, или ещё как-то? Хочется знать базовые адреса и размеры сегментов.
И может ли ring3 протектор каким-либо образом изменить GDT (вряд ли, конечно, но вдруг), или создать LDT?

Заранее спасибо за ответы. Не бейте сильно, если опять с терминами напутал

| Сообщение посчитали полезным:

Контекст жёсткий, лучше бы поотлаживал и разобрался.
Положение KiFastSystemCallRet хардкодить нельзя, много, от чего зависит, от СП и патчей вполне может. Может и от архитектуры, ибо при инсталле на разные архитектуры немного разные либы ставятся.
С селекторами юзай GetThreadSelectorEntry, если вопрос правильно понял, погугли статью на эту тему, можно добавлять свои записи в табличку.

| Сообщение посчитали полезным:

Спасибо огромное за GetThreadSelectorEntry, это как раз то, что мне нужно.
На тему KiFastSystemCallRet до меня наконец-то дошло. Адрес её загрузки можно посмотреть в таблице экспорта ntdll.dll. Только хочу спросить: всегда ли адрес, полученный таком образом, будет валидным? И может ли протектор сделать так, чтобы в ntdll.dll был один адрес, а на деле - другой?

А на тему жёсткого контекста - полностью согласен, но я убил на эту проблему целый день, да так и не понял, в чём дело. Когда осознАю - сделаю по-нормальному. Просто решил не топтаться на месте слишком долго.
Кстати, по этой же причине пока реализовал эмуляцию системных вызовов через исполнение, с ловлей на KiFastSystemCallRet.
Думаю, что после появления первой версии анпакера, вскоре начнут появляться и следующие, с исправлением этих "заплаток".

| Сообщение посчитали полезным:

Wolfram
Советую начать с написания анпакера для RCryptor (он СОВСЕМ не шифрует таблицу импорта - достаточно сдампить на OEP). Позже для PKLITE32 (тоже импорт целый, но до OEP труднее добраться). Сам вот только что написал rcryptor unpacker)

| Сообщение посчитали полезным:

SVIN95 пишет:
Советую начать с написания анпакера для RCryptor
Ну и нах анпакер RCryptor, PKLITE32??? Если Wolfram уже его тестит на ASProtect???

-----
minimaL_patсh на руборде

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

2 Archer:
Спасибо большое.

2 SVIN95 & SemDJ:
Я его сейчас тестирую на нескольких пакерах сразу, по принципу: реализовал несколько инструкций - потестил на всех по очереди. Если ни на одном не упало - значит, наверное, всё правильно.

И, наконец, 2 all:
Мы добрались до OEP в UPX!!!!!!!!!!!!!!!!!!!
Ура!!!!!!!!!!!!!!!

| Сообщение посчитали полезным:

Archer
Вопрос, близкий к теме. Можно ли Bounds импорт перетащить в обычный импорт безопасно?

| Сообщение посчитали полезным:

Я просто обрезал баунд и совмещал с обычным. Пока косяков не было. По сути это 1 хрен, формат тот же, просто баунд побыстрее обрабатывается (точнее, вообще не обновляется, если таймстамп либы совпал).

| Сообщение посчитали полезным:

С контекстом я разобрался окончательно. Как и предполагалось, не хватало одной строчки:
lpContext->ContextFlags = CONTEXT_ALL;
Собственно, поэтому не все регистры и устанавливались.

Сейчас распаковщик уже доходит до OEP в UPX, ASPack, NSPack и ORiEN. Также стало известно, что PECompact, MEW, ASProtect и многие другие активно юзают математический сопроцессор. Ну, не беда, доку по нему я уже нарыл, буду раскуривать

Вопрос такой:
Системные вызовы я пока эмулирую через исполнение с ловлей на KiFastSystemCallRet, с этим пока, вроде, проблем нет. А при возникновении исключения просто передаю управление на KiUserExceptionDispatcher, а дальше работаю в обычном режиме, не заботясь, что лежит в FS:[0] и пр. Два первых исключения в ASProtect и одно в PECompact таким способом проходятся отлично (дальше начинается FPU). Может ли протектор заставить нас потерять управление при таком подходе?

| Сообщение посчитали полезным:

А я тебе сразу сказал, с контекстом поглядеть на флаги, что наверняка сам чо-нить забыл.

Если используется ринг0 драйвер с обработкой исключений, типа 3 стара, то просто передача на KiUserExceptionDispatcher пойдёт лесом ввиду неправильности. Самоотладка типа 2 процессов в арме аналогично. Возможно, есть ещё косяки. Проще дать выполниться 1 вызывающей исключение инструкции и пусть управление само пойдёт на KiUserExceptionDispatcher. Хотя в описанных выше случаях приложение заработает при этом, но управление ты потеряешь.
З.Ы. На этапе обкатки ещё обнаружишь, где не работает

| Сообщение посчитали полезным: