Решил пройтись по нескольким упражнениям, дабы освежить знания и проверить их на практике. Задание 16, UPX, почему бы и нет, из курса IDA удалось понять суть данного упаковщика. http://ricardonarvaja.info/WEB/INTRODUCCION AL REVERSING CON IDA PRO DESDE CERO/EJERCICIOS/ Решил воспользоваться UPX'ом, чтобы распаковать, файл стал нерабочим. Code (Text): upx.exe -d PACKED_PRACTICA_1.exe pause Начал работать вручную: 1.Проверил сектора 2.Нашел тот, в котором большая разница между "пространством на диске" и "виртуальным пространством" 3.Принял за OEP 4.Поставил бряк 5.Сдампил сектора HEADER, UPX0, UPX1, .rsrc, .idata, .rsrc 6.Обработал PE Editor'ом сектор с кодом 7.Вытащил и приютил IAT при помощи Scylla 8.Таблица легла ровно, за исключением FThunk (pic. 1) 9.Просмотрев строение нового кода пришел к выводу, что точка входа _main находится на 1070h, что очень похоже на подобные консольные программы(pic. 2) 10.Обозначил точку 146Eh, как EP (туда переходит управление после распаковки) - получилось правдоподобно, как у похожих программ в ID'е (pic.3) 11.Решил прогнать через отладчик и посмотреть, "где собака зарыта", вылет произошел на следующих позициях - 00D91811h 12.Посмотрел на другие консольные проги, заменил участок "ds:0E73004h" на "___security_init_cookie", потом пошла следующая развилка в коде pic.5 Spoiler: Pic (pic. 1) (pic. 2) (pic. 3) (pic. 4) (pic. 5) Хотел бы узнать, в чем причина таких сбоев. Как решить данную распаковку?
LastNoob, > Как решить данную распаковку? Запустить и оно само всё распакует Эти пакеры писали люди с дефектным мозгом. Разница лишь в том, что вы это хотите сделать вручную, без запуска.
Итак, я немного освежился, разобрал, в чем проблема. Распакованная программа обращается к несуществующим участкам памяти, ориентируется на старую ImageBase, поэтому и вылетает. Решил crackme таким методом - заменил прыжок из OEP на прыжок моего "распаковщика", который вычисляет адрес ImageBase, добавляет к нему смещение на неугодное ветвление, меняет его и прыгает в OEP. Spoiler: Опыт обратной разработки данным методом Новый "распаковщик" Его последствия Считаю, что пример решен, однако, хотелось бы найти иные методы решения такого сдвига. Кто-то решил задачу иначе?
LastNoob, Инде правильно говорит, про "сам себя распакует". Ставьте бряк на моменте чтения распакованного кода, дампите, чините... :lol: Вы не читали "Далекая Радуга" Стругацких? Вы один-в-один Камилл
LastNoob, Всё просто, но вам суть врядле скажут, иначе будет утерян смысл во всём этом. Протекторов бывает два типа - уровня школьников или сильные, не важно наличие вм. В первом случае суть: код работает запутанный, но после отработки он выполняет штаную загрузку. Тоесть первичный этап нужен лишь для затруднения реверса и отладки. Поэтому данный этап можно просто скипнуть. Это поделки школьников, очень старые. Другого типа протекторы сильные - там нет как таковой EP, части модуля декриптуются и выполняются налету. Отладка такого вообще невозможна для ньюби, для этого нужны весьма сложные инструменты, которые налету отладки собираются, те не ваш это уровень. Кстате обсуждали не так давно это на кл. Был задан вопрос по событию депака. Там я ответил execute fetch after write fetch". Это общий критерий на протекторах первого типа и он срабатывает всегда и везде.
LastNoob, вы молодец, у вас все получится. Публике непривычно, по всей видимости, использование IDA для распаковки, а речь, насколько я понял, именно об этом.
напишите хелло ворлд, поставьте в самом начале int 3 запустите из под отладчика и когда он всплывет постройте по образу в памяти exeшник фирштейн ??
пакер акь таковой смысла не имеет для защиты кода от слова СОВСЕМ в основном его задача уменьшить размер экзе на диске иль могут быть варианты для экономии озу, однако такие схемы мб излишне тормознутыми. для реальной защиты от реверса сейчас методов хватает.. 1. дрова (единственный метод уязвимый для реверса). 2. облачные модули/функции. 3. софтина жёстко привязана к железке, то бишь часть алгосов реализованны в виде фпга/SoC/..
Итак, сразу же стоит сказать, в чем проблема распакованного CrackMe - адреса выделяются динамически от заголовка, например, запустил первый раз - адрес HEADER 0x7b0000, естественно, функции адресуются по смещению от него, там точка входа _main = HEADER + 0x1070, OEP так же, только HEADER + 0x146e. В старом дампе лежит старый адрес, программа перезагружается и происходит ошибка обращения к несуществующему участку памяти (к тому, который был при дампе) НО эти старые участки - не таблица импортов, таблица встала удачно (решил так, ибо в отладчике подписаны вызываемые функции) Пробовал вручную при каждом перезапуске менять опкоды, очень рутинно. Можно ли запретить программе выделять под себя память динамически, задать например HEADER = 0x41000 и это не меняется никогда? Не уверен, что в этом проблема, но хорошо, может быть до этого неверно описал суть проблемы... Выше попробовал объяснить понятнее)
UbIvItS, > пакер акь таковой смысла не имеет для защиты кода от слова СОВСЕМ в основном его задача уменьшить размер экзе Какой есчо размер. Любая поделка содержит весь набор защиты, это вам не дос и не контроллер, где размеры памяти ограничены. Любая поделка сейчас - пакер, морфер и вообще всё крипторы, так как есть лишь две задачи. Если вы это не понимаете, то не нужно бред писать, идите матчасть изучайте. Сейчас всё разделено на две группы, ну или вида. Первый крипторы, защита от ав. Второй защита от реверса, это виртуальные машины. Они коррелируют с первым типом. А вы тут какой то штатный бред пишите, очень интересно это читать =) LastNoob, > адреса выделяются динамически Какие адреса, почему выделяются и что значит динамически(может быть в статике..). И есчо выделено жирным текстом как нечто важное.. да тебе виндебаг на шею намотать, а потом и напишешь. Плюсану пост #9, норм совет, а вы пишите бред какой то. Бери открывай отладчик и IA доки. Таким путём придешь к успеху.
Да, уж. Вам даже пример привел. Как динамически, а вот так! В обычныех примеры CrackMe при перезапуске адреса одни и те же, в моем CrackMe базовый адрес смещается. Так понятнее?
в юм режиме любая форма защиты от реверса мало рабочая + она удорожает написание программ + она роняет производительность прог + увеличивается бажность. Ты думаешь, что 128 гигов озу не требуют приёмов экономии памяти? ЗЫ.. антиреверс софтовый и тем паче юмовый всегда был костыльным, тч применять его не следует своих же нервов ради
UbIvItS, Ну у вас не правильные понятия на счёт моего понимания профайла. И на счёт реверса вы не правы. В первом случае сейчас всё упирается в визоры, как добиться реалтайм профайла, десятикратная просадка его хоть и не заметна, но это не решение. Во втором вашем случае на счёт реверса - вы ничего не сможите решить без автоматики, даже любые текущие сборки. А можно сделать так, что реверс будет вообще невозможен в приемлемое время.
LastNoob, > при перезапуске адреса одни и те же, в моем CrackMe базовый адрес смещается. Штатное поведение системного аллокатора, это адресная рандомизация(ASLR). Реализовано как простейшая защита от OP. При выборе резервного адреса ядро вводит рандом фактор в адреса. Это можно отключить.
LastNoob, Я помогу вам по возможности, если будет соответствующий вопрос. Но думаю опции в бут.ини вы сами найдёте. Инфы навалом ведь.
если вся софтина целиком под рукой, то реверс вполне возможен даже в самые кратчайшие сроки == всё упирается лишь в доступные ресурсы. Другой Вопрос, если у софтины хорошая "крыша", коя отслеживает пиратки. В своё время на сд/двд можно было достать любую прожку практически за копейки, а вот пиратка 1С -- еть була целая ХИстория
