eXeL@B —› Софт, инструменты —› Распаковка AsProtect на примерах |
<< 1 ... 9 . 10 . 11 . 12 . 13 . >> |
Посл.ответ | Сообщение |
|
Создано: 17 января 2007 12:10 · Поправил: Модератор · Личное сообщение · #1 Здравствуйте! Очень прошу, помогите найти или выдайте пжалста из запасов прогу Advanced Archive Password Recovery v.3.00 кто может, очень хочется научиться распаковке, а проги нормальной нет. Далее повтор моего вчерашнего письма(лежит в чужой теме, найти можно в поиске введите: Распаковка ASProtecta - моё сообщение самое свежее) ---------------------------------------------------------------------- ------------------------------------------------------------------ Здравствуйте. Понимаю, что лезу немного не туда, но обсуждения статьи "Распаковка нового ASProtect на примере Advanced Archive Password Recovery v.3.00" автора SergSh на форуме и в поисковике вроде бы не видно(может статья просто древняя), а тут вроде бы тоже у ASR-ра 2-я версия. Суть проблемы: 1 Сам по вашим статьям научился распаковывать ASProtect 1.22-1.23 ,1.23 RC4, 1.24(проги типа Electra, Куриная месть.Первая разборка, скринсейвер и т.д. с затиранием репой краденого начала проги и без). 2 Нужно двигаться дальше и тут с удивлением обнаруживаю, что статей по распаковке версий 1.3-2.0 нет вааще(может я в шары долблюсь, незнаю). Плиз, если можно, то ссылку на подобную статью, а то руководство как починить велосипед есть(1.21-1.22), как починить мопед-есть(1.23 RC4), как починить боинг747 и космический челнок-есть(2.0x-2.12xx и выше). А вот как отремонтировать просто машину нет. 3 Из всех имеющихся статей более всего понятно было у SergSh в "Распаковка нового ASProtect на примере Advanced Archive Password Recovery v.3.00", но тут такой казус. Проискав в инете подопытную прогу версии 3.0 нашел две ссылки, скачал, инсталятор обещал версия 3.0 (как в статье),- в итоге версия 3.01, чем забиты все ссылки на эту прогу в инете и PEID говорит не ASProtect 1.2-1.3 registered(2.0x по словам SergSh),а ASProtect 2.1x SKE. Ну ладно: а)34раз Shift+F9 ставим бряк на ближайший переход внизу, ещё раз Shift+F9, снимаем бряк,ставим на Alt+M на секцию кода(401000), но не снова Shift+F9, как в статье, а trace into(а то EOP будет на две команды ниже и затруться два Push-а). Останавливаемся на EOP 42A910. Ctrl+A и всё видится чинно и благородно. б)Читаем статейку дальше и пробуем запустить его скрипт(в папку его,в Script , в Олю, в виде txt предварительно). И оля повисает пробовал подождать 1,5 часа думал это скрипт так долго на более свежей версии ASp-ра трудится(хрен то там:s14. Запущено как положено без бряков и с OEP после trace into и я в plugin->IsDebuggerPresent ->Hide, с полным игнором исключений. в) Руками по его совету IAT пока не пробовал, всё так пока трудно для понимания и непривычно и завтра на работу а уже 2ночи. Граждане, слезно молю дайте ссылку на настоящий Advanced Archive Password Recovery v.3.00, а то шатл починить не могу пока, дайте хоть чертежи к боингу. А если почти серьезно, то научиться распаковывать ASPr до второй версии включительно руками хочется так, что аж эти руки зудят. P.S. Не пинайте сильно за дурацкие просьбы самого маленького. Это первый выход в свет. Начал реверсить 18.12.06 с нуля. Реверсил даже в новогоднюю ночь. Для меня это очень важно(научиться распаковывать)! |
|
Создано: 18 июня 2007 08:39 · Личное сообщение · #2 |
|
Создано: 18 июня 2007 09:50 · Личное сообщение · #3 PE_Kill фенкс, если я верно понял это на СИ. Но уже легче я где то уже видел в одной из статей как VirtualProtect в асме юзается. Хотя уже практически готов вариант с формированием адресов и размеров областей аспра в стеке и с последующенй работой на сверку от туда. Всё равно нужно знать на будущее. |
|
Создано: 19 июня 2007 10:39 · Личное сообщение · #4 |
|
Создано: 19 июня 2007 21:43 · Личное сообщение · #5 Привет всем. К сожалению на работе крутой аврал. Второй вечер не могу даже прикоснуться к скрипту. Есть время только отвечать на посты и задавать вопросы. У меня нет МСДН, но есть справка к делфи 6, немного подрезана, но достаточно полная перевёл оттуда про VirtualProtect и сразу возникли 2 вопроса. 1)PE_Kill пишешь NewProtect=PAGE_READWRITE ещё скажи как там флаг тот или иной задаётся? Я имею ввиду какую циферку нужно в стек третьей пихать(там ведь 10 разных флагов,-PAGE_READONLY, PAGE_READWRITE, PAGE_WRITECOPY, PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE, PAGE_EXECUTE_WRITECOPY, PAGE_GUARD, PAGE_NOACCESS, PAGE_NOCACHE,). Или всё просто например: пихаем 00000001,-значит PAGE_READONLY, пихаем 00000002,-значит PAGE_READWRITE и т.д. Или там иначе, я конечно проверю своё предположение, как время появится, но вдруг принцип другой перебирать целый DWORD, это не фунт изюма. Подскажи не разу не грамотному или может общий принцип выставки флагов есть(наверно есть элементарное правило, но что то не попадалось на глаза). 2)Не понятен такой момент пишут про четвёртую входную переменную lpflOldProtect (ты писал 3) Points to a variable that the function sets to the previous access protection value of the first page in the specified region of pages. If this parameter is NULL or does not point to a valid variable, the function fails. Я перевёл так(ну конечно при моих познаниях инглиша): Направьте на переменную хранящую функциональные наборы предыдущего значения защиты доступа первой страницы в указанной области страниц. Если этот параметр НУЛЕВОЙ или не указывает на правильную переменную,наступают функциональные сбои. Я как будет время прочитаю досконально скачанную статью по PE-заголовку. Я верно думаю? Это там где то переменная на каждую секцию лежит? |
|
Создано: 19 июня 2007 21:55 · Личное сообщение · #6 Small_S пишет: Я как будет время прочитаю досконально скачанную статью по PE-заголовку. Я верно думаю? Это там где то переменная на каждую секцию лежит? ты должен указать переменную в которую возвратиться пред. атрибуты области памяти Small_S пишет: пихаем 00000001 ну почти так: PAGE_NOACCESS = 1; PAGE_READONLY = 2; PAGE_READWRITE = 4; PAGE_WRITECOPY = 8; PAGE_EXECUTE = $10; PAGE_EXECUTE_READ = $20; PAGE_EXECUTE_READWRITE = $40; PAGE_EXECUTE_WRITECOPY = $80; PAGE_GUARD = $100; ----- [nice coder and reverser] |
|
Создано: 19 июня 2007 22:06 · Поправил: Small_S · Личное сообщение · #7 |
|
Создано: 19 июня 2007 22:07 · Личное сообщение · #8 |
|
Создано: 19 июня 2007 22:19 · Личное сообщение · #9 Hellspawn и ещё ты не в курсе? Когда я начал ковырять не только Аспр 2.хх, но и 1.35, обратил внимание, что очень бедно с OEP-фаиндерами. Так у меня из пяти скриптов по Аспр 1.2х-1.3х всего один от бит хака (кэлл то кэлл) со встроенным скриптом от sanniassin в одном из трёх разных прог нашёл OEP. Тебе известны более менее универсальные для 1.35 или ссылки на тутор где есть основные принципы поиска в версиях без исключений. Я там с разными извращениями доходил вроде до OEP или VOEP, но как то всё смотрелось ненадёжно, да и муторно перекидывать после некоторых признаков то на чтение кода, то на аспр секцию, то обратно. Может кто уже нормальный алгоритм разработал, ну или скрипт чтоб поизучать. |
|
Создано: 25 июня 2007 22:26 · Личное сообщение · #10 Привет всем. Обложили меня работой волки(с ударением на последний слог). Только сегодня немного удалось посидеть с асм вставкой. К этому моменту я пока всё также дорабатываю поиск через стек(не пробовал записи в PE-заголовок). Саму встаку, которая уже ищет правильно и до 00400000 и после проги до системных библ, ещё нужно оптимизировать. Главная недоработка адреса после последних участков выделенной аспр-памяти и до системных библ, там большой кусок недоступной памяти получается, соответственно с исключениями и вставка притормаживает минут на 6. Но уже знаю решение и скоро уберу. В младшей части ECX организую счётчик до 1-ой шестнадцатеричной тысячи(что составляет 1000Х1000=1000000h) и буду его сбрасывать если попался читаемый участок и наращивать, если попался нечитаемый. Как только размер нечитаемой памяти перевалит через 1000000h вставка прекратит сканировать память, экономия во времени составит около 5B260000h/1000000h=5Bh=90раз, т.е. 360с/90р=4сек, что вполне приемлемо(ну в действительности около 10-ти, так как до этого момента ещё есть). Пока вид у вставки страшный, одна только сигнатура почти на 100 байт: #6A006A005253558BEC33D283C508516A006A0033DB3BD1734A6068FF0F000052E8939 1407C83F800751C613E837C24040075053E8954240481C30010000081C200100000EBC F6183FB00750881C200100000EBC13E011C2481C2000001006633D2EBAC81F90000265 B740C87EC5A87E5B90000265BEB9E83C4083E833C2400740583C404EBF483EC10595D5 B5A83EC0C3E833C2400740583EC04EBF483EC08EB6883C4088BEC83C5083E8B4500390 372113E0345FC3903770983EC0858E99500000083C5083E837D0C007402EBDB83EC085 883EC04EB7A0000# но повторюсь ещё доработаю. |
|
Создано: 28 июня 2007 21:34 · Личное сообщение · #11 Привет всем. Наконецто скрипт работает нормально с асм вставкой по корректной очистке ссылок на любые области в секции с таблицей IAT. Он это делает корректно и ниже проги(возможные обращения в собственные этой проги драйвера), и выше проги (в секции аспра), и ещё выше (в системных библиотеках). Потестил только что на 8-ми прогах везде начало-конец правильно, очищено корректно. Конечно теперь нули в секции с IAT не сплошные, но зато остаются целыми например такие места как в иконловере: 006E1444 00000000 .... 006E1448 00000000 .... 006E144C 7C812AC6 Ж*Ѓ| kernel32.GetSystemInfo 006E1450 00000000 .... 006E1454 00000000 .... 006E1458 00C87290 ђrИ.===========================ВОТ ОНО 006E145C 00000000 .... 006E1460 00000000 .... 006E1464 00000000 .... 006E1468 00000000 .... 006E146C 7C80D47E ~ФЂ| kernel32.GetLocaleInfoA или как в актуалспа: 00531B0C 77D7A32A *ЈЧw user32.DdeUninitialize 00531B10 77D7A4EE о¤Чw user32.DdeInitializeA 00531B14 00000000 .... 00531B18 00334070 p@3. hk.RemoveMouseHook--------вот это явно какие то дрова или библы проги 00531B1C 00334040 @@3. hk.SetMouseHook 00531B20 00000000 .... 00531B24 0034448C ЊD4. hprog.ShowProcess 00531B28 003443BC јC4. hprog.HideProcess 00531B2C 00000000 .... 00531B30 00000000 .... Теперь, кстати, дальнейшая работа пойдет над обработкой подобных мест в IAT, так как первый пример ведёт в секцию аспра, а оттуда в собственную аспровую таблицу IAT(я уже находил такое и в иконловере и в актуалспа), где в данном случае вызывается kernel32.GetProcAddress 00C9C270 7C80176B kЂ| kernel32.GetSystemTime 00C9C274 7C812AC6 Ж*Ѓ| kernel32.GetSystemInfo 00C9C278 7C80AC28 (¬Ђ| kernel32.GetProcAddress++++++++++++++++++++++++++Вот оно 00C9C27C 7C80B529 )µЂ| kernel32.GetModuleHandleA 00C9C280 7C80B357 WіЂ| kernel32.GetModuleFileNameA Ну а завтра добавлю во вставку двига PE_kill-а чтобы когда дописывает новую апишку смотрело по адресу где пишет ноль или нет(если не ноль, то смотрим следующий). А то первый пример посреди секции и его точно не затрёт, а вот второй пример это после конца IAT и надо, чтобы он оставлял всякие вызовы типа: 00531B24 0034448C ЊD4. hprog.ShowProcess 00531B28 003443BC јC4. hprog.HideProcess Завтра же постараюсь описать для любопытствующих саму вставку, которую так долго дописывал(правда в основном из за нехватки времени). Пока скрипт в аттаче. p.s. скрипт немного(у меня на пресскоте 3,5ГГц-4 секунды)задумывается, когда чистит секцию и анализирует адреса на валидность,- это нормально. Hellspawn отдельно благодарю за выложенный аналог импректа(это было в другом топике, заметил и скачал) и вообще за помощь. Буду изучать в дальнейшем, может когдато смогу его переделать и доделать. 58b9_28.06.2007_CRACKLAB.rU.tgz - IAT_rec_modern1pSO.osc |
|
Создано: 03 июля 2007 22:12 · Личное сообщение · #12 Привет всем! Наконец то могу выдать нормально рабочую версию скрипта ибо пришлось повозиться по порядку: 1Скрипт теперь не только грамотно чистит, но и не трёт подозрительные вызовы в тело проги или в выделенные участки Аспровой памяти. Хотя я не совсем доволен как удалось сделать, но из тех вариантов, что перепробовал этот пока оптимальный. Хотел сделать как PE_kill, чтобы шёл массив функций из одной библы, затем через ноль следующий массив и т. д., но при этом через ноль или через нули пропускались эти самые подозрительные адреса(см. предыдущий пост). Однако оказалось, что исходный механизм определения и сравнения базы прошлой восстановленной функи (ESI) и нынешней восстановленной функи(EDI), не идеален. Он хорошо действует пока после найденной в уже существующей таблице функе не появится функа из другой библиотеки, но вызова которой ещё нет в IAT(или может это получалось при взаимодействии с моим кодом, хотя врятли). Тогда в редких случаях рядом ставились функи из разных библ и импрект не желал их нормально определять. Я хотел схитрить и нулить младшую часть даблворда адреса фунок и сравнивать две соседние, но оказалось, что системные библы сильно велики и в одной библе может быть не одна 10000, поняв что затея будет не слабее чем с очисткой секции IAT, решил пока пойти по более лёгкому пути, как у Сержа. Заделал во всех трёх вставках запись найденных фунок через ноль и подозрительные вызовы через один или два ноля. Всё в импректе более нет залипаний фунок с разных библ, а подозрительные адреса можно смотреть хоть до, хоть после скрипта, снятия дампа или восстановления в импректе. 2.Ещё одна мелкая неприятность была обнаружена, она состоит в том, что с очисткой мусора импрект начал иногда брать появившиеся двойные нули за начало IAT, таким образом обрезая часть IAT при автоматическом определении. Пока сделал дёшево сердито. В конце скрипта, в мессаге сообщается не только, сколько было восстановлено переходов и какого они типа, но и что нужно вбить в окно RVA(начало IAT) и что нужно вбить в окно Size(конечный размер IAT) для правильного восстановления. Причём после такого вбивания(ну конечно не забываем задать и OEP) и нажатия на гет импорт и шов инвалид можно сразу отрезать то, что там будет. Не нужно ни дизасма, ни плага 1.23, никаких слипаний, ничего похожего на вызовы АПИ. Не определёнными будут только около десятка- двух этих самых подозрительных вызовов. В общем я проверял на 5ти прогах просто сказка. Знаю вставки ещё можно шлифовать и шлифовать, как будет время оптимизирую и наверное сделаю механизм заполнения найденных фунок в пределах старой таблицы с одновременным решением проблемы появившихся двойных нулей. Ну а пока вперёд на последний бастион импорта- забранные в командную Аспр секцию в её Аспр IAT функи, которые пока скрипт не определяет(см. пример из предыдущего поста). Про обещание пояснить что я накодил не забыл, завтра постараюсь, спать пора, завтра на работу. 6fdf_03.07.2007_CRACKLAB.rU.tgz - IAT_rec_modern1pSO.osc |
|
Создано: 04 июля 2007 22:05 · Поправил: Small_S · Личное сообщение · #13 Вот краткие пояснения. Реализация слабовата(особенно хождение по стеку туда сюда), но на тот момент времени не было вааще, сам поражаюсь как накодил урывками по нескольку минут, почти не имея возможности сосредоточиться: PUSH 0 // PUSH 0 //Признак начала искомых адресов в стеке двойной ноль PUSH EDX //пушуем конец последней секции проги PUSH EBX //пушуем начало секции таблицы импорта PUSH EBP //без сохранения EBP видимо тоже не обойтись так как стек крутим по полной MOV EBP,ESP //запоминаем нынешнюю вершину стека XOR EDX,EDX //проверять память будем вначале с нуля, вот и ноль в EDX ADD EBP,8 //у нас уже много чего запихано в стек подныриваем поближе к началу PUSH ECX //сохраняем ECX-это будет очень хитрый регистр старшая часть контролирует текущий адрес //младшая сколько уже было обращений к несуществующим адресам PUSH 0 //а эти нули нужны для правильной работы кода вместо них будет адрес начала секции PUSH 0 // и её размер XOR EBX,EBX // Освобождаем регистр для работы CMP EDX,ECX //и начинаем сравнивать не достиг ли текущий адрес в начале 00400000, а затем границы библ JNB SHORT icolover.00400D6C //если не ниже то пора менять значение ECX или вообще заканчивать сканить PUSHAD //сохраняем все регистры PUSH 0FFF //готовим чтение на 1000 байт от заданной позиции PUSH EDX //это заданная позиция CALL kernel32.IsBadReadPtr //читаем по заданным условиям CMP EAX,0 //а прочитали ли мы? JNZ SHORT icolover.00400D44 //не прочитали и значит нужно будет идти увеличивать счётчик CX и текущий EDX POPAD //а это если прочитали, вначале вынимаем все регистры из стека CMP DWORD PTR DS:[ESP+4],0 //затем сравниваем была ли запись базы этого участка памяти в стеке JNZ SHORT icolover.00400D33 //была и тогда уходим MOV DWORD PTR DS:[ESP+4],EDX //не было и тогда пишем адрес базы в стек ADD EBX,1000 //запись размера области уже была или не была,но просто увеличиваем ADD EDX,1000 //и текущий проверочный адрес тоже увеличиваем XOR CX,CX // поскольку мы прочитали то счётчик чтения недоступных адресов обнулился JMP SHORT icolover.00400D10 //ну и пошли на новый круг проверки POPAD //ну а теперь если не прочитали, вынимаем все регистры из стека CMP EBX,0 //был ли размер области выделенной памяти в EBX?(а не первый ли раз мы не прочитали?) JNZ SHORT icolover.00400D5B //первый и значит нужно пойти и записать размер законченной области ADD EDX,1000 //увеличиваем текущий адрес INC CX //увеличиваем счётчик "неправильных чтений" CMP CX,0FFF //ВАЖНЫЙ МОМЕНТ.ЕСЛИ CX ПРЕВЫСИТ ЭТУ ВЕЛИЧИНУ, ЗНАЧИТ МЫ УЖЕ ГДЕ ТО ОЧЕНЬ ВЫСОКО JNB SHORT icolover.00400D80 //НАД СЕКЦИЯМИ АСПРА И ПОРА ЗАКАНЧИВАТЬ(ФИШКА СОКРАЩАЕТ ВРЕМЯ в десятки раз) JMP SHORT icolover.00400D10 //в противном случае уходим на следующий круг проверки ADD DWORD PTR DS:[ESP],EBX // вот здесь пишем размер текущего участка выделенной памяти ADD EDX,10000 //а эта фишка тоже для экономии времени, правда не столь сильной XOR DX,DX //(если область закончилась то можно прибавить больше и чтоб до ровной 10000) INC CX //и здесь увеличиваем счётчик "неправильных чтений" JMP SHORT icolover.00400D0A //а отсюда переход пушевание двух нулей и начало розыска следующ области CMP ECX,5B260000 //а здесь начинаем задавать новую верхнюю границу адреса проверки JE SHORT icolover.00400D80 //и если уже всё просканировали то заканчиваем с этим XCHG ESP,EBP //Далее быстренько достаём значение конца последней секции проги POP EDX //теперь ведь сканить будем не с ноля а с конца проги до XCHG EBP,ESP // системных библиотек. Это значение передаём в EDX MOV ECX,5B260000 // ну а ECX присваиваем значение нижней границы библ JMP SHORT icolover.00400D10 //погнали снова сканить память ADD ESP,8 //далее идем по стеку до наших сохранённых регистров CMP DWORD PTR DS:[ESP],0 //используя как признак ноль JE SHORT icolover.00400D8F //и уходим по достижению на доставание значений регистров ADD ESP,4 //иначе продолжаем сканить JMP SHORT icolover.00400D83 SUB ESP,10 //подныриваем под значения POP ECX POP EBP POP EBX POP EDX //вытаскиваем их SUB ESP,0C CMP DWORD PTR DS:[ESP],0 //далее снова по стеку назад используя признак нуля JE SHORT icolover.00400DA5 // SUB ESP,4 JMP SHORT icolover.00400D99 // SUB ESP,8 //а вот этот прыжок готовит два нуля для другой АСМ вставки JMP SHORT icolover.00400E04 //на неё по окончанию и прыгаем когда регистры приведены в первоначальный вид. Далее ничего сложного. Другая вставка формирует адреса из секции таблицы IAT(она сканит уже секцию с IAT а не память).Те адреса, что были в границах библ она проверяет на чтение сама, а адреса ниже 00400000 и выше последней секции проги, но ниже нижней границы библ поставляет сюда. В этой вставке происходит сверка присланного адреса, со значениями, что теперь есть у нас в стеке и далее в зависимости от того входит адрес в какую либо из обнаруженных реально существующих секций или нет идёт прыжок в другую вставку на затирание или на оставление в покое этого адреса. |
|
Создано: 22 июля 2007 16:36 · Поправил: Isaev · Личное сообщение · #14 1. "IAT_rec_modern1pSO.osc" какие версии может? Пробывал на iconlover 3.0 (Version: ASProtect 2.xx (may be 2.11) Registered [1]) "Скрипт очистил секцию адресации IAT по адресу 0, он определил начало таблицы как FFF, конец таблицы как 1000. Если вы согласны нажмите "Да". Если хотите задать границы работы скрипта сами нажмите "Нет"!" При задании далее вручную, летит куча ошибок... 2. Каким образом правильно определить конец IAT? В статье SergSh'a этот момент как-то не очень понял... 3. В актуальной версии iconlover (Version: ASProtect 1.35 build 04.25 or 06.26 Release [Extract]) по версии 1.35 почти ничего на форуме нет (или не нашёл)... исключения там не возникают... Как с ним бороться? ----- z+Dw7uLu5+jqLCDq7vLu8PvpIPHs7uMh |
|
Создано: 22 июля 2007 18:23 · Поправил: Small_S · Личное сообщение · #15 Всем привет. Isaev на "IAT_rec_modern1pSO.osc" какие версии может? может многие версии(как и его исходный от PE_kill) 2х, 2.1х, 1.35, но нужно выйти на OEP, а не VOEP и причём правильно(когда IAT развернулась). iconlover 3.0 точно может проверено на многих машинах, правда на XP SP2 только. Посему дружище, бери версию пять VOEP-OEP-фаиндера из этого же топика. а)запускаешь, после непродолжительной работы скрипт выводит сообщение, "Скрипт просканировал память! База, блока виртуальной памяти=хххххххх !" . б)нажимаешь кнопку отмена, так как тебе в данном случае VOEP не надо. в) Ставишь бряк на доступ к секции кода(она по 00401000), жмёшь Shift+F9. Падаешь на OEP. г) Снимаешь этот бряк, так как изначально скрипт требовал отсутствие посторонних бряков и в модефикации это сохранилось. Ну и всё запускаешь IAT_rec_modern1pSO.osc Да ещё пока не забыл обязательно выставь в настройках оли галку игнорирования исключений в кернеле32 иначе активно юзающаяся в ассемблерной вставке kernel32.IsBadReadPtr просто будет после наступления каждого исключения доступа к памяти стопорить Олю и скрипт. И ты наверное успеешь поседеть прежде чем первая вставка отработает, к тому же сотрёшь до локтя палец задавливая Shift+F9. Кстати у тебя скорее всего именно из за этой галки скрипт и не пашет. Если не поможет скинь пожалуста дамп твоего OEP в виде txt, откуда запускаешь скрипт. Но всё должно быть тип топ ибо модефикация скрипта изначально разрабатывалась на основе иконловера, фонтэксперта и пассворд рековера. по версии 1.35 действительно нет пока более менее универсального VOEP-OEP-фаиндера, я ещё доберусь до этого, но пока даже продолжать IAT_rec_modern1pSO.osc некогда. |
|
Создано: 22 июля 2007 18:51 · Поправил: Isaev · Личное сообщение · #16 Small_S пишет: а)запускаешь, после непродолжительной работы скрипт выводит сообщение, что обнаружена область выделенной памяти по адресу такому то и что VOEP находится по адресу такому то. б)нажимаешь кнопку отмена, так как тебе в данном случае VOEP не надо. Ну так в этот момент ты уже на ней Small_S пишет: Кстати у тебя скорее всего именно из за этой галки скрипт и не пашет. Я скрипт второй запускал с VOEP... (я вообще думал, что они VEOP и OEP вместе не существуют... Заблуждаюсь?) с VOEP я разобрался и вручную, а как OEP найти? ----- z+Dw7uLu5+jqLCDq7vLu8PvpIPHs7uMh |
|
Создано: 22 июля 2007 19:59 · Личное сообщение · #17 Ну так в этот момент ты уже на ней нет ты в этот момент на последнем джеемпе(после последнего исключения). Немного я неправильно текст сообщения передал, сорри, оно выглядит так: "Скрипт просканировал память! База, блока виртуальной памяти=001100000 !" (у меня так у тебя другой адрес будет). Сейчас поправлю предыдущий пост. я вообще думал, что они VEOP и OEP вместе не существуют... так то оно да, вместе не существуют. Просто для ясности полагаю называть VOEP- виртуальную(лежащую в выделенном участке памяти)точку входа в программу, а за OEP место первого обращения к секции кода проги. Если ты запустишь скрипт в выделенном участке памяти(VEOP), то он просто не находит, по сигнам обращение того или иного типа и не может правильно выскочить на секцию в которой находится IAT, ну и как следствие не может почистить и т.д. Действуй как написано выше. С последнего джеемпе,отмена, бряк на секцию кода проги на чтение, Shift+F9, снимаешь бряк и запускай скрипт. Вот какая OEP у меня: 004071C0 E8 3B8ED100 CALL 01120000 004071C5 B4 8B MOV AH,8B 004071C7 C0FF 25 SAR BH,25 ; Shift constant out of range 1..31 004071CA 2813 SUB BYTE PTR DS:[EBX],DL 004071CC 6E OUTS DX,BYTE PTR ES:[EDI] ; I/O command 004071CD 008B C0FF2524 ADD BYTE PTR DS:[EBX+2425FFC0],CL 004071D3 136E 00 ADC EBP,DWORD PTR DS:[ESI] 004071D6 8BC0 MOV EAX,EAX 004071D8 - FF25 20136E00 JMP DWORD PTR DS:[6E1320] ; kernel32.TlsSetValue тут замусоренно получается из за того, что первый же шаг на входе и сразу идём в Аспрову защиту импорта -CALL 01120000. Не пугайся, запускай скрипт он этот и многие другие вызовы исправит. например из этого куска: 8BC0 FF2524136E00 8BC0- типичный вызов в делфи апи-функи из IAT. |
|
Создано: 22 июля 2007 22:16 · Личное сообщение · #18 Small_S пишет: База, блока виртуальной памяти=001100000 !" (у меня так у тебя другой адрес будет) у меня 011D0000 а почему он в принципе другой? Скрипт пошёл ! "Скрипт очистил секцию адресации IAT по адресу 6E1000, он определил начало таблицы как 6E1220, конец таблицы как 6E1D04. Но уже после часа работы в цикле: 006E2021 41 INC ECX 006E2022 3BCA CMP ECX,EDX 006E2024 73 13 JNB SHORT icolover.006E2039 006E2026 8039 E8 CMP BYTE PTR DS:[ECX],0E8 006E2029 75 F6 JNZ SHORT icolover.006E2021 я начал подозревать, что что-то не так [там снизу пишуться адреса срабатывания Exceptions. В каких пределах они примерно должны быть?] Small_S пишет: Вот какая OEP у меня: 004071C0 E8 3B8ED100 CALL 01120000 у меня: 004071C0 E8 3B8EDE00 CALL 011F0000 Не скинешь мне свою версию iconlover? Наверно build другой ----- z+Dw7uLu5+jqLCDq7vLu8PvpIPHs7uMh |
|
Создано: 23 июля 2007 04:25 · Личное сообщение · #19 Так, "Скрипт очистил секцию адресации IAT по адресу 6E1000, он определил начало таблицы как 6E1220, конец таблицы как 6E1D04. Значит асм-вставка по очистке и определению IAT отработала. Дальше по идее идёт сам двиг от PE_kill. Симптомы сильно напоминают наличие антивира или фаера. Посмотри что там у тебя стоит, поотключай. Если же стоит Касперский то ваще нужно удалить его драйвер из папки, чтоб при запуске он его не находил и не мог запуститься.В этом топике об этом уже есть полистай назад и внимательно почитай, а ещё лучше сделай как я качни его, чтоб можно и без нета было читать. Попробуй пока это если не поможет, то подумаем дальше. Основной двиг работает 3-4 минуты. Наверно build другой ну ты же тоже на 3.0 пробуешь пока попробуй первое может это не понадобится. Хотя жалко нету, как говорится. |
|
Создано: 23 июля 2007 12:59 · Личное сообщение · #20 Small_S пишет: Симптомы сильно напоминают наличие антивира или фаера. Отрубил всё (AVG, Outpost, DrWeb, Alcohol) изменилась только "База, блока виртуальной памяти" Small_S пишет: ну ты же тоже на 3.0 пробуешь У меня 2 3.0 (2005-Jun-20 & 2005-Jun-25) и оба, похоже, не те Script должен в 6E2021-6E2029 цикле крутиться или это уже глюк? Начинает искать с адреса 7B2000, но там же ничего нет ----- z+Dw7uLu5+jqLCDq7vLu8PvpIPHs7uMh |
|
Создано: 23 июля 2007 14:31 · Поправил: Small_S · Личное сообщение · #21 Script должен в 6E2021-6E2029 цикле крутиться или это уже глюк? однозначный глюк. Предлагаю два решения(ибо подозреваю, что у тебя всё равно дрова с какого то антивира висят в памяти) а) Попробуй запустить исходный скрипт от PE_kill-а для восстановления импорта(его можно отыскать в в его rar-статье по распаковке проги Фонтэксперт). Если исходный скрипт не пойдёт, то скорее висит дровина от антивира. Если пойдёт, то уже я буду упорно морщить лоб, так как это будет касаться перехода с моей вставки (есть там одно подозрительное местечко когда вроде не откуда адресок нужный в стеке по определенному смещению висит и я этот недокументированный глюк системы использую) на двиг. б) Есть у тебя чистая система под виртуалкой? Так вот поставь девственную систему под виртуалом и прогу, а затем погони модернизированный скрипт. Будет медленно, но если после очитки он будет работать как надо, то это будет прямым указанием на висящие дрова. Кстати как и чем отрубал AVG, Outpost, DrWeb??? |
|
Создано: 23 июля 2007 14:45 · Личное сообщение · #22 |
|
Создано: 23 июля 2007 15:00 · Личное сообщение · #23 И всё равно очень настоятельно рекомендую зайти на стр 6 этого топика и найти спец утилиту- антируткит Rootkit Unhooker 3.31.150.420. Там помоему осталась ссылка где скачать. И вообще почитай, я там довольно долго мучился. Каспер не удалялся(точнее его драйвер) даже прогами, которые контролируют авторан. И обязательно проверь под виртуалом модернизированный и просто исходный вдруг ты нашёл баг перехода со вставки, все ж молчат, не испытывают модернизированный скрипт, а мне откуда знать у меня на трёх разных компах пашет и всё тип топ. На всякий случай дай билд твоего XP. |
|
Создано: 23 июля 2007 15:09 · Личное сообщение · #24 |
|
Создано: 23 июля 2007 22:36 · Личное сообщение · #25 Small_S пишет: На всякий случай дай билд твоего XP. Версия ОС 5.1.2600 (WinXP Retail) Короче вырубил всё (Outpost вырубить действительно сложно... Подмял под себя всю систему :s9, В Rootkit Unhooker (на вкладке хуки-Code Hooks Detektor) теперь вообще ничего не находит... На всякий случай выкинул все плаги из Оли Результат никакой... Script PE_Kill'a тоже встаёт на тот-же цикл, но в теле проги (точнее в PE-Header'e 400E01-400E09) Скрипту никаких дополнительный переменных не надо инициализировать? ----- z+Dw7uLu5+jqLCDq7vLu8PvpIPHs7uMh |
|
Создано: 23 июля 2007 23:02 · Личное сообщение · #26 Isaev на Script PE_Kill'a тоже встаёт на тот-же цикл, но в теле проги (точнее в PE-Header'e 400E01-400E09) скинь что там у тебя между 400E01-400E09, код я имею ввиду не ужели точь в точь как ты постил выше? Исходный не должен так себя вести он у тысяч народу работает. Точно не забыл убрать бряк с доступа к секции кода?(ремове брэк мемори эссес). Тебе бы чистую систему установить. Я ваще наученный горьким опытом хожу в нет, смотрю кино, играюсь в одной системе с каспером, а вот в оле работаю в чистейшей девственной системе. Скрипту никаких дополнительный переменных не надо инициализировать? нет там всё готово к работе и есть. |
|
Создано: 23 июля 2007 23:56 · Личное сообщение · #27 Small_S пишет: не ужели точь в точь как ты постил выше? Ага... точь-в-точь... 00400E01 41 INC ECX 00400E02 3BCA CMP ECX,EDX 00400E04 73 13 JNB SHORT icolover.00400E19 00400E06 8039 E8 CMP BYTE PTR DS:[ECX],0E8 00400E09 75 F6 JNZ SHORT icolover.00400E01 Small_S пишет: Точно не забыл убрать бряк с доступа к секции кода? Бл$... Идиота кусок... Ну да, как всегда... Еб& людям мозги "Скрипт закончил работу! Общее число восстановленных переходов = 73! Восстановлено 0 Call и 73 jmp переходов. После снятия дампа плагином OllyDump не забудьте в ImpRECt-е кроме адреса точки входа (в окне OEP) вбить в окно RVA начало IAT=2E1220 и в окно Size - точный размер IAT=BEC(иначе может неверно определиться начало IAT)." Почему 2E1220, если сначала "он определил начало таблицы как 6E1220"? ----- z+Dw7uLu5+jqLCDq7vLu8PvpIPHs7uMh |
|
Создано: 24 июля 2007 04:13 · Личное сообщение · #28 Почему 2E1220, если сначала "он определил начало таблицы как 6E1220"? потому что отнимается база 400000. Всё у тебя правильно и размер, и восстановлено, и адреса. Кстати билды систем у нас с тобой одинаковые тоже. Рад за тебя. Но для данной проги импорт- это только начало. Читай дальше Сержа. Что касается этого скрипта то он ещё кое что оставляет и это кое что буду доделывать чуть позжа. |
|
Создано: 31 июля 2007 04:23 · Поправил: Small_S · Личное сообщение · #29 Привет всем! Вчера вечером вроде доделал в IAT_rec_modern1pSO.osc исправление обращений к функе GetProcAddress, ну и возможно, обращений к любым функам вызываемым через командную область Аспра в выделенной памяти. На иконловере и актуалспа вроде работает, но ещё потестирую и вечером, если нормально выложу очередную модификацию. Имеется вопрос: никто не знает, если одна и таже Апи прописана в таблице IAT по нескольку раз -это имеет какие нибудь негативные последствия для проги? Судя по вчерашним прогонам по актуалспа-нет. Прога пашет и в импректе никаких заморочек при восстановлении. А вот PE_kill в исходном скрипте на стадии восстановления вызовов ищет была в таблице уже данная функа или нет и если не была, то дописывает в конец. Это просто из эстетических побуждений и для экономии места сделано или есть более серьезные причины? |
|
Создано: 31 июля 2007 21:06 · Личное сообщение · #30 Всем привет! Протестировал на 6-ти прогах под разными аспрами. Скрипт рубит, как и было раньше, на версиях 1.35-2-2.1 до 2.19, если стоишь на OEP и нет каких нить прибабахов. Как и писал вчера изменения коснулись автоматического восстановления GetProcAddress. Кроме того проводится ещё большая вторичная зачистка, если к примеру ссылка в секции таблицы IAT ведёт на нули или на непонятную пока мне конструкцию типа FEEEFEEEFEEEFEEE... Причем ODBGScript при поиске командой FIND находит данный участок шиворот навыворот из-за чего пришлось делать и так и так: v1: mov prover,[edx] cmp [edx],0EEFEEEFE------------------так если у нас FEEEFEEE jne v2 mov [ebx],0 v2: cmp [edx],0FEEEFEEE------------------так если EEFEEEFE jne v3 mov [ebx],0 Я конечно не знаю, есть ли ещё функи кроме GetProcAddress, которые не определяются основным движком и спрятаны по такому же механизму, но думаю что наверное бывают, тогда эта доделка будет брать и их. Например в Иконловере GetProcAddress спрятан так: в окне дампа видим 006E144C_ 7C812AC6 Ж*Ѓ| kernel32.GetSystemInfo 006E1450_ 00000000 .... 006E1454_ 00000000 .... 006E1458_ 00C87290 ђrИ.===========================ВОТ ОНО 006E145C_ 00000000 .... а по этому адресу: 00C87290_________________ PUSH EBP 00C87291_________________ MOV EBP,ESP 00C87293_________________ MOV EDX,DWORD PTR SS:[EBP+C] 00C87296_________________ MOV EAX,DWORD PTR SS:[EBP+8] 00C87299_________________ CMP EAX,DWORD PTR DS:[C99458] 00C8729F_________________ JNZ SHORT 00C872AA 00C872A1_________________ MOV EAX,DWORD PTR DS:[EDX*4+C99458] 00C872A8_________________ JMP SHORT 00C872B1 00C872AA _________________ PUSH EDX 00C872AB_________________ PUSH EAX 00C872AC_________________ CALL 00C7577C ; JMP to kernel32.GetProcAddress 00C872B1_________________ POP EBP 00C872B2_________________ RETN 8 после чего на келле 00C75774 _________________ JMP DWORD PTR DS:[C9C27C] ; kernel32.GetModuleHandleA 00C7577A _________________ MOV EAX,EAX 00C7577C _________________ JMP DWORD PTR DS:[C9C278]++++++++++ ; kernel32.GetProcAddress 00C75782 _________________ MOV EAX,EAX 00C75784 _________________ JMP DWORD PTR DS:[C9C274] ; kernel32.GetSystemInfo 00C7578A _________________ MOV EAX,EAX ну а там у аспра своя IAT в окне дампа видим: 00C9C270 7C80176B kЂ| kernel32.GetSystemTime 00C9C274 7C812AC6 Ж*Ѓ| kernel32.GetSystemInfo 00C9C278 7C80AC28 (¬Ђ| kernel32.GetProcAddress++++++++++++++++++++++++++Вот оно 00C9C27C 7C80B529 )µЂ| kernel32.GetModuleHandleA 00C9C280 7C80B357 WіЂ| kernel32.GetModuleFileNameA Вот по приведённому алгоритму и ищется, на этот раз с асмом сильно не стал морочить голову, всё в скрипте идёт, в основном. В аттаче новая модефикация скрипта. f18a_31.07.2007_CRACKLAB.rU.tgz - IAT_rec_modern1.1pSO.osc |
|
Создано: 03 августа 2007 22:14 · Поправил: Small_S · Личное сообщение · #31 Привет всем. Вот и опять я воткнулся и требуется помощь. По порядку. Позавчера решил посмотреть почему модификация скрипта по импорту не и идёт на Аспр 2.3 и обнаружил, что там импорт и украденный, и исходный весь в выделенной памяти(таблица IAT). НУ и решил из скрипта нарастить последнюю секцию на ту самую величину (C000h) и переписать из выделенной памяти в тело проги, так сказать, а там уже заниматься по накатанной. Ну найти три величины в заголовке файла не составило труда(общий размер образа- вначале, размер секции и описание прав доступа там где секция последняя описывается). Ну думаю руками попробую в окне дампа вначале. Перезабил циферки сохранил бекап. Alt+M, а там то ничего не меняется. Так вот и вопрос: Как олю заставить воспринять новые значения размеров последней секции в уже загруженном образе, а не в мёртвом файле лежащем на диске? Я попробовал в винхексе в исходном поменять(получается но это не выход ), во первых аспр такое движение потом палит, а во вторых мне надо из асм-кода или скриптового хода это делать в уже развернутом образе. Наверняка одна или две апишки какие нибудь существуют, которые заставляют перезаписаться адресное пространство с учётом PE-заголовка, висящего образа, просто я пока не нарвался на эту информацию. |
<< 1 ... 9 . 10 . 11 . 12 . 13 . >> |
eXeL@B —› Софт, инструменты —› Распаковка AsProtect на примерах |